
A brief history of USB, what it replaced, and what has failed to replace it - jorgecastillo
http://arstechnica.com/gadgets/2014/08/a-brief-history-of-usb-what-it-replaced-and-what-has-failed-to-replace-it/
======
userbinator
As someone who has programmed for USB and many of the other "legacy" ports, I
think what it replaced was much simpler to work with; in comparison, USB is a
huge mass of complexity at every level, from the signaling protocols to the
driver interfaces.

There's no denying that some of the things that came with USB, like mass
storage and video cameras, are really useful, but I don't think the same is
true of trying to replace PS/2, serial, and parallel ports. E.g. USB keyboards
do not support more than 6 simultaneous key presses without needing some
special workarounds, while it is not a problem for PS/2 interface. Serial
ports are still widely used, especially for working with embedded hardware - a
UART makes for an extremely simple terminal interface. Parallel ports are easy
to interface to, and essentially provide GPIO capability - you can use one to
flash microcontrollers and EEPROMs, e.g. to recover from bad BIOS flashes and
other similarly bricked devices (
[http://www.fccps.cz/download/adv/frr/spi/msi_spi.html](http://www.fccps.cz/download/adv/frr/spi/msi_spi.html)
[http://write-code.blogspot.ca/2012/08/parallel-port-spi-
flas...](http://write-code.blogspot.ca/2012/08/parallel-port-spi-flash-
programmer-and-unbrick-wm8650.html) ) And from my experience trying to install
and troubleshoot a USB printer (the problem was driver-related), I'd rather
stay with one connected to a parallel port.

Latencies are also much lower and more predicatable than USB because these are
dedicated interfaces; there's a community of hobbyists using parallel ports to
control CNC machines, and USB<>parallel adapters will not work for that.

My motherboard still has PS/2, parallel, and serial - and 8 USB ports. A
little-known fact is that most if not all of the integrated I/O chips
("SuperIO") used on motherboards still have all the legacy port controllers,
but the manufacturers don't bother connecting the pins to anything.

~~~
Qzmp
Why would someone press 7 or more keys at the same time?

~~~
M4v3R
Playing 2-player games on the same keyboard, now less common but it was once
very popular.

Edit: huh, quite a few gamers here :)

------
MBCook
It's sad to see Ars repeating the old "Firewire failed to beat USB" myth.

Firewire was _never_ designed to handle modems, mice, keyboards, gamepads, or
other low bandwidth things; and it never made the move to try.

On the other hand, USB 1.0 was never suited for high bandwidth devices like
hard drives, video cameras, and flatbed scanners. If you remember using USB
1.0 hard drives, you remember how amazingly slow they were.

They were designed for different purposes. Firewire never went 'down', it
stayed with high bandwidth devices; but USB moved 'up' with USB 2 to better
service the high bandwidth devices people were trying to use (like hard
drives).

Firewire 400 was usually faster than USB 2, but cost and ubiquity (and Sony's
crazy 4-pin connector) meant it was never big with consumers. But in the end
Firewire could only hold onto parts of the professional market for high
bandwidth devices.

Thunderbolt is the challenger (really replacement) to FireWire. When USB 4
comes out in two or three years are we going to see articles about how USB
defeated Thunderbolt because Thunderbolt keyboards never became popular?

Yeah. The Firewire vs. USB thing is almost always used to add an 'opponent'
where there often wasn't one. After all, all articles are required to have an
'opponent'. Sure you could talk about how the old ports hung on amazingly long
in the PC space, but it's more fun to throw unnecessary punches at FireWire.

But honestly, no one ever sold a Firewire mouse. I would _love_ to see a link
to one. I know there were a few Firewire thumbdrives that were supposed to be
amazingly fast, but it's not exactly apples and oranges.

~~~
burnte
While I agree that Firewire never went after the low end, it is that very fact
why it, in the end, failed. We had a plethora of ports in the olden days, slow
ones like serial, parallel, and PS/2, for modems, printers, and input devices,
and we even had SCSI ports for external storage, and ethernet jacks for
networking. Those days were terrible. We converged into a few physical ports
than can do all of that for a reason, and that reason was because we wanted
something inferior. The reason was because one port is better for humans.
Computers are here to make our lives easier, not the reverse. Firewire was
good for external storage and moving large amounts of data (like audio/video)
fast, and when USB became as good, while also handling everything else, then
Firewire became obsolete, as it was yet another port to take up space and
cable to hang on to and lose. USB has greater utility than Firewire due to its
flexibility of being a very nearly universal port.

USB wasn't necessary invented as a competitor to Firewire, but it's not a myth
that it became one, and it won in the end.

~~~
MCRed
>"USB wasn't necessary invented as a competitor to Firewire, but it's not a
myth that it became one, and it won in the end."

That is a contradiction. In the end, what defeated Firewire (by supplanting
its ports) was Thunderbolt, not USB. Machines with Firewire had USB as well,
because they served different purposes and were not in competition.

I have some machines with both Firewire and Thunderbolt, and later machines
with Thunderbolt. (They all have USB, but nobody is connecting 4k displays via
USB.)

Edit: Ah, I see this is a lost cause. This is falling into the "everything PC
is good and everything Apple is bad" HN narrative. No point in attempting to
point out history either, it appears.

------
kabdib
USB has some pretty nifty ideas buried under a descriptor and software
specification that was clearly designed by hardware guys colluding with some
firmware types. Those things are not simple. It's a crappy way to describe a
device to an OS.

The core USB descriptors are . . . okay, if you put yourself in the position
of a firmware guy with like zero bytes left in code space. The howling gotchas
start when you get into the higher level stuff, like multimedia. It takes an
unholy amount of firmware and driver-side code to make a UVC device.

Why can't standards be _simple_?

Some of the standards are examples of craven bad design, too. For instance,
there's a standard conversation that I have regarding DFU, Device Firmware
Update:

Engineer: "What do you think about DFU?"

Me: "It's a pile of crap. It's 900 feet of rope on a 1,000 foot cliff, and
you'll be fixing bugs in firmware update stuff for a long time."

Engineer: "I've been told to use it. It's a standard. How bad could it be?"

Me: "See you in month."

(a month goes by)

Engineer: "Holy shit, you were right. But I've been TOLD to use it, because
it's a standard and would save a bunch of time. All we're doing now is fixing
firmware update bugs, re-enumeration bugs in the host OS, and I've got a pile
of bricked units that I have to go through every morning."

Me: (heavy sigh; this stuff just isn't that hard, okay?)

Variations on this conversation include "Oh, the chip vendor has a DFU
implementation already, it's in ROM" [do not walk, RUN away from that
chip...], and "Don't worry, we just tell the user to not unplug the device
during the update" [bangs head against desk].

The USB 3.0 host controller spec was actually rather nice (even if all the
chips I saw had different and sometimes quite spectacular bugs].

~~~
userbinator
I wonder how many common USB devices out there use DFU - I remember reading
something about how it would be a standard for Android smartphones/tablets,
but that doesn't seem to be the case, with each manufacturer using its own
proprietary protocol. Ironically enough, the update code in the ROM of my
phone's SoC emulates a USB _serial port_ (CDC)...

~~~
makomk
A fair few devices use DFU - for example, the Atmel-provided USB bootloader
for many of their chips is DFU, and a number of ST Microelectronics chips have
a DFU bootloader in ROM - and they're all subtly incompatible with each other.
So for example, right now I've got one DFU utility installed that only
supports Atmel AVR chips and another one that supports STM32F2/3/4 devices and
a few other pieces of hardware. Even then, there are many devices out there
which aren't compatible with either and require special proprietary tools.

~~~
mikepurvis
Ah yes, I'm having fun times with the ST ROM bootloader and dFuSe/dfu-util.
What a mess.

------
Pxtl
I seriously don't miss midi/game ports and serial and parallel ports. That
said, the inability to draw power through a port that is currently hosting
peripherals is a huge flaw that's really hindered smartphone docking stations.

~~~
to3m
One nice thing about the PC's parallel port was that it was bidirectional,
relatively straightforward to program, could be programmed at a reasonable
rate, and supplies/accepts a standard TTL +0V/+5V. This allows interfacing
with a reasonable range of devices using a cable that's relatively simple to
make up. Doing the same thing over USB is possible, but you need a
microcontroller, which means more programming (i.e., more things to go wrong).

But this isn't a common problem. I don't rue the passing of all the nonsense
that USB replaced.

~~~
tlarkworthy
still, that occasional use case is catered for with a USB breakout board, or a
USB to serial. So it's not like we have really lost anything

~~~
MBCook
It doesn't always work.

I've seen serial devices that are so picky with timing that they'll work with
real serial ports but most USB->Serial adapters cause programming to fail.

~~~
joezydeco
And let's not forget the 80% of USB->Serial adapters that are using
counterfeit FTDI chips and barely work at all, if you can get an O/S to
recognize it.

