A brief history of USB, what it replaced, and what has failed to replace it | Hacker News Reader

A brief history of USB, what it replaced, and what has failed to replace it

arstechnica.com

88 pointsjorgecastillo52 comments

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://write-code.blogspot.ca/2012/08/parallel-port-spi-flas... ) 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.

USB might not have been a great improvement for hardware developers, but as a low-end hardware user it's been a huge improvement. Any piece of hardware I come across can probably physically interface with any computer I own, and I have lots of options on how to hook it up (usually a number of slots on the computer, plus the option of using a hub).

The USB story seems similar to software like systemd and PulseAudio. As a software guy I like the simplicity USB has brought me as a user but I dread the complexity of systemd and PulseAudio.

I would agree if PulseAudio were anywhere near as reliable (to the end user) as USB is. But it isn't.

> E.g. USB keyboards do not support more than 6 simultaneous key presses without needing some special workarounds,

Are USB MIDI piano keyboards[1] implementing one of those workarounds you're speaking of? They can send status of 10 simultaneous keys (10 fingers pressing piano chords.) Or that doesn't count because the multi key detection is done inside the keyboard and embedded into the MIDI data packet? Is that an example of a workaround?

[1]https://www.google.com/search?q=usb+midi+keyboard&tbm=isch

MIDI devices don't use USBHID, so they're not affected by this issue.

So they go lower level ? some kind of `UDP` usb packets ?

Mice and Keyboards use the "Human Interface Device" (HID) USB class.

MIDI devices use their own special class instead of HID: http://www.usb.org/developers/docs/devclass_docs/midi10.pdf

Same as how printers or scanners aren't HID, MIDI is different enough that it needs its own protocol.

Oh I see, I forgot there were other classes.

>USB keyboards do not support more than 6 simultaneous key presses without needing some special workarounds

This isn't totally true. If you want your USB keyboard to work as a boot keyboard (i.e. one that the BIOS understands) then the first 8 bytes of keyboard reports must follow the example (which does have this restriction). After boot though, there will be a Change Protocol request sent from the driver that signals you can use a non-Boot report (which doesn't have this limit).

Alternatively, you can always pack more keys into another report. The BIOS ignores everything beyond the first 8-bytes.

Theoretically, you are right.

However, gamer keyboards that care about compatibility opt to appear is several independent keyboards, each one responsible for at most 6 keys. I would be surprised if they chose this despite a "much simpler route" such as the one you describe.

Ducky Shine for instance has a "turn on N-key rollover" button which you press once you're booted to Windows.

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

Imagine two people playing a game.

Classic hot seat action games where 2 players share the same terminal such as Star control 2 hypermelee.

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

Edit: huh, quite a few gamers here :)

Doing stenography is one example - at any time you could be pressing up to 2 keys with every digit on your hands. If you were creating your own steno device, it'd be easier to make it HID compatible, since every system of importance supports it and would avoid the need to write new drivers. The Plover software (http://plover.stenoknight.com/) can be used to provide steno for regular HID devices - works with any N-key roll-over keyboard.

Emacs user? :-)

Hot plugging a ps/2 mouse or keyboard used to be impossible (or at least, extremely unreliable). Hell, in older computers it could even physically damage your computer!

I for one am glad that it has been replaced. Those 'good old days' weren't as good as you seem to remember them.

The PS/2 connectors could glitch out, but generally it was okay to hot-plug those.

SCSI on the other hand was so temperamental that if you pulled a connection even accidentally you could blow the entire chain of devices.

Latencies are also much lower and more predicatable than USB because these are dedicated interfaces

This can't be stressed enough. The article is all raving about speed, but completely ignoring latency. Which is at least one of the reasons why USB hasn't completely replaced the other most common ports. USB only replaced ports for basic consumer devices without much special requirements in the timing department (and don't get me wrong, it did that in a fabulous way, the 'u' in the name was a good choice)

The most common usb-serial converter from FTDI does not have a completely predictable latency (mainly due to the software stack if I'm not mistaken) which can make it a pain to use with serial device which can only continuously stream data: small buffer size = no go.

Likewise, up until now, we still have some software using the parallel port because it's a readily avaiable GPIO with predictable sub-mSec latency, on Windows. USB doesn't even come close to replacing that, so we're switching to dedicated DAQ hardware.

My graduate thesis project operated from the parallel ports of multiple 8088 DOS boxes.

There's a hack that might help that CNC application: At least one of the common USB<>serial interfaces will spit out a serial data stream at an utterly constant rate. I've used this to control stepping motors. You'd need something at the other end to interpret the serial data, some kind of MCU.

In general, I'd advise implementing USB using the simplest canned solution possible, i.e., and leave "rolling your own" low level implementation for applications that can't be done in any other way. Like you say, the complexity is onerous.

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.

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.

>"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.

It might be a myth that Firewire failed to beat USB as you say but it doesn't seem too far off to say that USB succeeded in beating Firewire. I don't think the article was too far out of bounds in portraying it as a competition.

There was a brief window where consumer PCs came with firewire ports. There were a lot of fanboy arguments about how firewire was technically superior / faster for hard drives. There were even hard drives that came with both ports - I still have one somewhere. There was a genuine format war in the consumer hard drive space - and USB won it.

In a few years will you be arguing that Thunderbolt never really competed with USB because it was never meant as a consumer standard?

Not just fanboy arguments. You could boot off them just like a SCSI device. This was not possible with USB drives at the time (and is still a messy affair). The performance was very different too.

Firewire/i.Link/IEEE 1394 was also the dominant standard for video streaming. Nobody even tried using USB for that AFAIK.

Light Peak/Thunderbolt replaced both of these uses for 1394, so I think it's fair to say it is a true replacement for it.

Bootable USB may be messy to prepare, but on the user end it largely Just Works.

As with many hardware-vs-software things (e.g. RAID controllers), Firewire performance was originally much better but USB caught up as processors got faster.

A standard for USB video streaming eventually emerged (at least, I have that option in my kernel), but it's fair to say it was much less popular than 1394. Mostly camcorders (at least consumer ones) became digital themselves, storing data on a filesystem and presenting themselves as a mass storage device.

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].

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)...

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.

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

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.

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.

The fact that the parallel port was the only high speed bidirectional port also lead to attempts to daisy chain things that usually didn't work past a device or two. So you may have an external drive or a scanner and your printer and if you were lucky you could leave it all plugged together and it would work.

I also remember being short of COM ports between modems, drawing tablets, special game controllers that didn't use the joystick port, etc. Installing a serial card for additional ports was one of my first upgrades.

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

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.

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.

Except for the "reasonable rate" bit, which (IMHO) also includes "reasonable latency." Real UARTs can be used for, e.g., pulse-per-second inputs from GPS or atomic clocks to discipline an NTP server. That doesn't work for a USB->serial thingy (because the latency is literally three orders of magnitude worse).

It's pretty amazing what we managed to attach to the humble parallel port. My first CD burner was a big parallel port device.

Oh the memories of buffer underruns.

"DON'T touch the computer it's burning a CD!"

Don't even walk on the floor near it or you'll shake it and ruin the burn.

It's kind of boggling to read project blogs from people messing with Arduinos and Raspberry Pis and, after all the unpacking and setup and breadboarding and programming, they can finally light up an LED as their hello world.

When we had basic PCs and parallel port you could literally take a resistor + LED, twist them together, stick it into the parallel port itself and with a line or two of MS-DOS shell script make it light up.

and if you replaced the LED for a speaker, and created a resistor ladder, you could squirt data out the parallel port and get sound.

The NO$GB emulator used this, for example. And even though it was horrible it was authentically horrible.

Those were actually sold commercially, too - as the "Covox Speech Thing". This meant that home-made parallel port resistor ladder DAC was supported in many games.

Well, it is for good reason that multi-user operating systems don't permit arbitrary processes to do port IO. That said, if all you want to do is poke the LEDs on an arm board, dd to /dev/mem as root will probably do the trick.

Is that really the case? You've always been able to simultaneously charge and sync your iDevice with your Mac.

As far as I know you can get only up to 500 mA if you specifically request it. Ports that support more (e.g. on dedicated chargers) have their data lines shorted and thus you cannot transmit anything.

So you can charge your device, it just takes ages. And might even discharge slowly if you still have the screen on.

They're talking about plugging a keyboard to your phone (or tablet) while charging it.

That's what the spec says, but that's not what most manufacturers are doing. With many motherboards you also get a driver that overrides the hardware limitations and provides up to 2.1Amp to a USB device, regardless of whatever you are communicating with it or not. And only a very very very small number of devices actually requires the data lines to be shortened together - PS Vita will not charge from a charger which does not have these to lines shortened together. Even the dedicated Apple USB charges don't have the data lines shortened together and pretty much everything charges from them(apart from PS Vita), so very few companies keep to the standard here.

Notice the dearth of SoundDock-like devices for Android? That's what I'm referring to. Devices where the android phone/tablet device is (a) being charged, but also (b) hosting a speaker (or wired gamepads or whatever).

Reply on news.ycombinator.com