It took 25 years for this USB demo/explanation

[Howardlong]

This is the best on-the-wire USB protocol demo & explanation I've ever seen, but then there aren't many entrants.

Why did it take 25 years for this level of demonstration and explanation to see the light of day?

[ataradov]

The reason for lack of explanations is that to fully explain (and include FS and HS modes) you would need a very long video. This is a good introduction, but not even a remotely complete explanation. And in practice, specific bit encoding on the bus rarely matters. In practice you deal with controllers and higher level transfers that consists of multiple packets on the bus.

And once you understand how to read it, USB spec is not that bad. It is better than a lot of documentation I have seen.

[Howardlong]

I never claimed it was either a complete explanation, or a replacement for the USB spec. I am saying it's a worthy addition to bring to light how USB works on the wire and at a basic packet level, something that has always been sadly lacking.

It brings home how it really works in practice.

A 600 page spec is very dry and does not relate well to understanding actual implementation as a system. Instead it depends upon layer upon layer of abstraction.

This demo is, on the hand, very relatable.

Riddle me this, if USB was so simple to pick up, why did it take five years to have serial adapters & drivers that didn't crash the computer?

While I don't do it that often, I do on occasion use USB triggering & decode on scopes to sniff out pinch points to optimise firmware USB stacks: it's one of the very few reasons I still keep an MDO4104C available at the bench! That's something that's less than convenient to do with hardware or software protocol analysers that demand time consuming retrospective rather than interactive analysis for discovering systemic timing latencies.

[ataradov]

Riddle me this, if USB was so simple to pick up, why did it take five years to have serial adapters & drivers that didn't crash the computer?

I never had an issue with serial adapters crashing the system. But even if it happens, I don't understand how poor coding and testing is relevant here.

It is still possible to crash both Windows and Linux with misbehaving devices though. I personally did it many times while doing firmware development. But again, it is just programmers only coding for the well behaving scenario and not taking into account misbehaving devices. Not USB's fault.

You can make an argument that USB spec is so complex that it is hard to correctly implement it. This may be true, but understanding how the bits work does nothing for understanding how to write correct handling code. You still need to read 600 page spec.

And I'm not against trying to explain things in a simple ways. I'm just answering the question of why this did not exist before or why there is no other articles of the same nature. There is no real demand, since it is irrelevant for most practical cases. Article "how to make USB work on STM32" has more value to majority of people.

[coppice]

Riddle me this, if USB was so simple to pick up, why did it take five years to have serial adapters & drivers that didn't crash the computer?

The development of USB was VERY messed up, mostly on the software side. It took MS so long to get working drivers in their OSes that the first generation of USB peripherals was scrapped and replaced by one or two more generations before any of them actually started to sell. The protocol and hardware is actually pretty straightforward, and didn't cause much trouble. Sure, there were, as always, some buggy chips. Probably the inability to sell early on made the vendors reluctant to invest in cleaning up the bugs, but what else would you expect.

[nfmax]

Riddle me this, if USB was so simple to pick up, why did it take five years to have serial adapters & drivers that didn't crash the computer?

The development of USB was VERY messed up, mostly on the software side. It took MS so long to get working drivers in their OSes that the first generation of USB peripherals was scrapped and replaced by one or two more generations before any of them actually started to sell. The protocol and hardware is actually pretty straightforward, and didn't cause much trouble. Sure, there were, as always, some buggy chips. Probably the inability to sell early on made the vendors reluctant to invest in cleaning up the bugs, but what else would you expect.

It was known as the "useless serial bus" for several years

[Howardlong]

Riddle me this, if USB was so simple to pick up, why did it take five years to have serial adapters & drivers that didn't crash the computer?

I never had an issue with serial adapters crashing the system. But even if it happens, I don't understand how poor coding and testing is relevant here.

I'm not sure if those are rose tinted glasses, but I had very different experiences, usually resorting to BlackBox PCI serial cards, or PCMCIA cards for laptops if I wanted reliability. Back in those days, I worked on and developed autonomous and remotely managed satellite groundstation solutions: dishes, radomes, rotators etc. used across the world at latitudes of -90 to +78 degrees. It simply wasn't possible to rely on USB solutions for these due to their unreliability. It was pot luck which COM port would be assigned to which adapter at boot time, an untenable solution for remote systems.

It's relevant because, in my view, it demonstrates that USB was over-engineered for the time. Some might say it was ahead of its time. At that time the only practical way to engineer a USB solution was to create a custom ASIC, so it was an expensive proposition. That's unlike today where not only are there many solutions, the firmware stacks are mostly fairly stable. Almost no-one builds their own USB stack nowadays, they either buy IP or use a vendor library, and that's for a very good reason: USB is just so darned complicated.

Bluetooth had a similar problem, but it was rather worse, because it confused customers, as not all Bluetooth devices were compatible with all Bluetooth hosts, and the terminology like "pairing" was not standardised between OEMs.

FWIW I have similar views about USB-C, where there remains much consumer confusion even down to very basic things like identical looking cables that aren't functionally equivalent for the plethora of potentially concurrent demands on the single physical interface (USB HS or FS, Thunderbolt, Power Delivery, Diplayport etc), not to mention the physical and electrical fragility of connectors, multiplexers and power delivery silicon.

[coppice]

I'm not sure if those are rose tinted glasses, but I had very different experiences, usually resorting to BlackBox PCI serial cards, or PCMCIA cards for laptops if I wanted reliability. Back in those days, I worked on and developed autonomous and remotely managed satellite groundstation solutions: dishes, radomes, rotators etc. used across the world at latitudes of -90 to +78 degrees. It simply wasn't possible to rely on USB solutions for these due to their unreliability. It was pot luck which COM port would be assigned to which adapter at boot time, an untenable solution for remote systems.

Most USB connectors are completely unsuitable for those types of applications. The contacts corrode and become quite flaky. That's completely separate issue from the reliability of USB as a system. That's penny pinching on contact material. The erratic port assignment with Windows can be a PITA. Most of the things I've done with numerous USB serial ports has been with Linux, and the only issues I've had have been those flaky contact ones.

[thm_w]

If you want to play around with decoding, get a cheap logic analyzer and fire up sigrok. Use the built in USB decoders:
https://sigrok.org/blog/new-protocol-decoder-usb-request
https://sigrok.org/wiki/Protocol_decoders

Just be wary of the device speed of course.

[Howardlong]

Another more in-depth vid, this time diving into USB HID reports. I think he's making a short series.

[Howardlong]

I'm not sure if those are rose tinted glasses, but I had very different experiences, usually resorting to BlackBox PCI serial cards, or PCMCIA cards for laptops if I wanted reliability. Back in those days, I worked on and developed autonomous and remotely managed satellite groundstation solutions: dishes, radomes, rotators etc. used across the world at latitudes of -90 to +78 degrees. It simply wasn't possible to rely on USB solutions for these due to their unreliability. It was pot luck which COM port would be assigned to which adapter at boot time, an untenable solution for remote systems.

Most USB connectors are completely unsuitable for those types of applications. The contacts corrode and become quite flaky. That's completely separate issue from the reliability of USB as a system. That's penny pinching on contact material. The erratic port assignment with Windows can be a PITA. Most of the things I've done with numerous USB serial ports has been with Linux, and the only issues I've had have been those flaky contact ones.

All USB connections would have been in an HVAC controlled environment housed at the base of the radomes together with the rest of the gear like radios, HPAs, PCs, axis controllers etc in 19" racks. The RF and control cables run up inside the radome: the only electronics not in HVAC is the receive LNAs and LNBs mounted directly at the feedpoint. Control signals are terminated with captive Amphenol multipole connectors. There's never any USB going to the antenna for a multitude of reasons, including cable length limitation, and not least RFI. It's much simpler than that at that point ;-)

We did test running 10Base2 some years ago to improve flexibility and reduce the number of control cables, but RFI was a show stopper.

The problem in this case wasn't anything to do with the reliability of USB connectors, it was to do with configuration and software reliability.