USB Made Simple (2008) | Hacker News Reader

USB Made Simple (2008)

usbmadesimple.co.uk

122 pointsuserbinator44 comments

Now do Bluetooth!

I have spent a lot of time in the USB mines over the years and recently stumbled onto a problem involving Bluetooth. "How hard could it be?" I thought to myself foolishly.

What a tire fire.

I wonder if GPT et al. would help with this kind of thing, or if it's too esoteric.

Bluetooth is huge and designed by committee. I don't know what GPT could help with; it's not that there aren't any good guides, it's that good guides are impossible. The protocol and stack are not designed to be understandable by a single human mind.

...unless it's the mind of Fabrice Bellard.

If you thought BT was huge, the cellular mobile specs (ETSI GSM etc.) are more than an order of magnitude bigger and more complex.

There is a document for the 3GPP specs that contains a list of the abbreviations used in the rest of the spec...

Its an 80 page document.

The ETSI documents I saw all tried really really hard to “don’t repeat yourself”, and, as far as I can tell, succeeded at that.

So, I guess this is a document that has two columns, the abbreviation and a reference to the document that defines it, without mentioning the long form?

I have worked on 3GPP implementations and honestly, not as bad as Bluetooth.

LLMs generate content that's statistically plausible, not factually accurate. We don't need more content about USB that might be mostly right.

I thought the USB specs were already LLM written? How else did we get USB Type C 3.2 Gen 4x4 AWD Superspeed 4.0 kbps?

this comment actually makes me mad because of how close to reality it feels. :-P

If you think about it, USB cables and ports are themselves nondetermistic, probabilistic models of connectivity :D

The best way I found when I dove into it ~8 years ago was to read through the code of one of the open source embedded Host stacks. That only gives you a peripheral understanding of the baseband layer though, which is like 10 more cans of worms.

I spent a few years in that area, and was never able to answer the question of why the whole protocol couldn't just be a dumb pipe (plus advertising/identification).

You can also get the worst of both worlds by trying to implement the Bluetooth HCI USB transport protocol!

The energy budget is too low to allow for an additional layer of abstraction plus all the conversion that's needed.

For example, Apple just barely managed to make streaming spatial audio work on the airpods pro, and even then it has a noticeably shorter battery life then competitors, ~5 hours in ideal conditions.

You're right, I didn't explain very well. What I meant is that I think the abstraction of profiles is bad - just let the application deal with the ACL packets. Then, depending on what you care about, you can optimize your device better for throughput, latency, or energy use.

Higher level protocols (profiles) can be handled by libraries, rather than baked into the spec.

Because profiles are the reason why Bluetooth is a thing and other wireless protocols aren't?

The lack of profiles and demand for proprietary crappy iot apps is a problem, not a solution for the standard.

Bluetooth is a thing because the big players backed it in the late 90s. It's hard to say what it would look like now if profiles were at a different abstraction level in the spec. I see WiFi as a counterexample - the protocol doesn't make assumptions about your application and it seems to be successful enough.

Agreed that lack of profiles and proprietary nonsense is a problem, but at least in my experience, it is much worse to deal with bugs baked into various implementations. In the past, getting maximum throughput (or minimum latency) between different devices required all kinds of nasty hacks. An escape hatch to the L2CAP connection would have been a lifesaver, or even better, if profiles were implemented outside the HCI layer. An OS update shouldn't be necessary to fix a bug in the heart rate profile.

> Higher level protocols (profiles) can be handled by libraries, rather than baked into the spec.

But there needs to be a spec of a protocol in order to enable interop? The question whether it is baked into the protocol stack or distributed separately as a library doesn’t seem that much of a distinction. What is important is certification, because otherwise connecting different manufacturers would never work smoothly.

You're right, and if you're implementing a profile for a widget chances are you can stumble your way through the spec and get something that mostly works.

The problem is that the cross product of hardware on the sending and receiving sides leaves sufficient gaps that you will be banging your head against the wall trying to figure out why a profile isn't working and it's because Vendor's part doesn't implement the spec properly.

I sometimes wonder what a world where every radio is a software-defined radio and we can all just update our full Bluetooth implementation alongside our OS. Instead it's the worst case of "actually another CPU with closed source blob firmware" and so we're absolutely left stranded.

I think what is being advocated here is moving profiles outside the implementation, into libraries we can port around, or e.g. the kernel somewhere, and I think that is indeed a step in the right direction.

How would you implement such a mechanism without introducing a lot of overhead?

Where's the overhead? Depending on your system the whole thing could be zero copy down to the DMA buffer. It's just a read/write protocol with a separate channel for commands.

I'm not an expert on implementing Bluetooth in real life products, but something tells me it will be a bit more complex then that.

At the HCI level the Bluetooth protocol is sane enough, it's straightforward to provide a zero-copy interface to the L2CAP layer if you're writing your own host stack.

A product I worked on in the past used a serial connection over Bluetooth to Android/iOS apps. In order to communicate to an Apple device, the layers roughly looked like:

Radio -> L2CAP -> RFCOMM -> iAP2

The RFCOMM/iAP2 part were redundant. It's understandable that Apple wanted to certify devices, but implementing that as a thin layer over L2CAP and making the profiles on top optional would have made the system much simpler. There may have been historical reliability concerns on the Bluetooth side that justifies what they ended up with, I'm not sure.

Absolutely, certification is necessary for manufacturer interop. But I do think separating profiles from the stack would have saved a lot of headache, especially in the early days. Each implementation had tons of bugs, and it was often impossible to do anything about it unless you were an OS/module vendor, or were otherwise in a position to deploy your own HCI firmware.

This cuts both ways: a vendor willing to fix things can if it is just about updating a library, but then a vendor that doesn't give a crap and who will never roll out fixes leaves a user stranded. But if the fix is part of the OS, every user will benefit from it, regardless of his device manufacturer.

I think in practise we have a mix anyway - manufacturers already license BT stacks from a few vendors, and don't develop them themselves.

> You can also get the worst of both worlds by trying to implement the Bluetooth HCI USB transport protocol!

Are you me??? Truly this was entirely horrors that I will never unsee.

The best book on BLE is "Bluetooth Low Energy Developers Handbook" by Robin Heydon

It is responsible for what has become of my career these past 6 years or so.

I don't know if you were looking at more than BLE. If you are, I don't know of a good resource.

I love a good book to build a solid foundation for understanding, and understand that you can't rewrite the fundamentals every release, but does it matter that this book was published in 2012? I expect it doesn't cover all the highly relevant IoT features added in 4.2 and 5.0 and on...

The book doesn't cover things added after it was published, correct

Of course, I don't expect it to!

But in the past 6 years of your career, I expect you've studied those things a lot more than I have. Do you think that the book is still a good starting point for someone looking to progress beyond dumping confusing vendor binaries in off-the-shelf Bluetooth modules that seem to be energy hogs, to miniaturize and integrate custom firmware and onboard antennas on my PCBs?

yes, I highly recommend Heydon's book, even in 2023. The tech stack including l2cap, connection establishment, advertising, connection parameters, security, GAP, GATT, are all still relevant.

It's a good recommendation, but I'd prefer the whole thing were less complicated so, like USB, I could figure it out in a few days, finish my work and move on with my life.

I certainly appreciate one being able to make a career out of these things, but I'd rather not.

I would love to see a writeup that made bluetooth usable in a couple days. I suspect the aspects that make Bluetooth useful also make it too complicated.

Much higher-level, but I keep coming back to it (especially the direct links to the various USB specifications, although slightly outdated): https://fabiensanglard.net/usbcheat/

That table could really be called "USB Made Complex"! IMHO things went really crazy starting with 3.x, when they should've really started adopting a more consistent naming scheme like e.g. what Ethernet always had.

OTOH we are talking about the thing where once 'High speed' was a good 10-40x faster than 'Full speed', some confusion is to be expected.

To make things worse, D and E are potentially confusing suffixes for connectors, so instead of having good, meaningful classifications for connectors, we are having to research whether our USBC cables actually have the right connector on the other end.

It seems to have some error, for exemple USB-PD allow up to 20V for 100W (and up to 48V for 240W) https://en.wikipedia.org/wiki/USB_hardware#USB_Power_Deliver...

Also, the last row of that table doesn't work mathematically: if max voltage is 5V and max current is 5A then max power must be 25W (or less than that if you're not allowed max voltage at the same time as max current) but it is listed as 100W .

Fun to see this on here. I’ve recently been writing a usb_device [0] implementation for the CH32X035 [1] microcontroller and it was very helpful when trying to work out why enumeration wasn’t working.

[0] - https://github.com/rust-embedded-community/usb-device

[1] - https://www.wch-ic.com/products/CH32X035.html

Cool! Just in case you haven't come across this, we've got a (rather quiet lately) chat that might be useful.

https://matrix.to/#/#usb-rs:matrix.org

> Please note that this specification replaces the earlier 1.0 and 1.1 Specifications, which should no longer be used. The Revision 2.0 specification covers all three data speeds, and maintains backwards compatibility. USB 2.0 does NOT mean High Speed.

Interesting how this sounds sensible on paper but also turns out to be a poor decision in hindsight that keeps confusing people to this day.

This looks fantastic! USB can seem intimidating at the beginning but one start getting the vocabulary and concepts it can actually be understood.

I fully recommend the book USB Complete. It might not look like a approachable book but it is very readable!

I once had to explore some code that talked to a usb device and I was quite surprised of how readable it actually was!

https://github.com/OpenNuvoton/NUC970_NuWriter_CMD/blob/mast...

A few years ago I was toying around with a couple of low level hardware projects, this website such an invaluable resource that helped me wrap my head around the complexity.

I wish every topic had such a great beginner-friendly resource, truly amazing job!

Need one for MMD cards now, particularly how they are compatible with SD card readers (I want to build an MMD to samba stack and I cant afford an SD card alliance Dev licence for $1000)

here's a book written mostly the perspective of an os/driver implementer:

https://www.fysnet.net/the_universal_serial_bus.htm

it's also part of a series on building an os.

Reply on news.ycombinator.com