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.htmlhttp://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.
>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.
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.
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.
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.
> 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?
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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).
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.