How does USB device discovery work? [video](youtube.com)
youtube.com
How does USB device discovery work? [video]
https://www.youtube.com/watch?v=N0O5Uwc3C0o
29 comments
Ben Eater (Author of this Video) is fantastic. Learned so much on electronics and computers through this series https://www.youtube.com/watch?v=HyznrdDSSGM&list=PLowKtXNTBy...
Piggy-backing this comment to add some context for the OP video: This "USB device discovery" video is actually the latest in a series of videos where Ben Eater is building a simple 8-bit computer on breadboards. He hooked up a PS/2 keyboard as an input device, and then got sucked into a tangent of investigating and explaining keyboard protocols.
- He investigates the PS/2 keyboard protocol: https://www.youtube.com/watch?v=7aXbh9VUB3U
- Somebody on Patreon asked about USB keyboards having higher latency than PS/2, so he made a video about the basic USB protocol: https://www.youtube.com/watch?v=wdgULBpRoXk
- He made the OP video about USB keyboards being limited to holding six keys at once.
- He investigates the PS/2 keyboard protocol: https://www.youtube.com/watch?v=7aXbh9VUB3U
- Somebody on Patreon asked about USB keyboards having higher latency than PS/2, so he made a video about the basic USB protocol: https://www.youtube.com/watch?v=wdgULBpRoXk
- He made the OP video about USB keyboards being limited to holding six keys at once.
> on breadboards.
Whatever happened to wire wrap?
* https://en.wikipedia.org/wiki/Wire_wrap
I can understand BBs for quick prototyping and tinkering, but once you've settled on the design, I'd think WW would be less fragile to deal with.
Whatever happened to wire wrap?
* https://en.wikipedia.org/wiki/Wire_wrap
I can understand BBs for quick prototyping and tinkering, but once you've settled on the design, I'd think WW would be less fragile to deal with.
I've recently been playing with CY7C68013A. Very approachable small USB (high speed!) microcontroller. With tiny amount of code, you can do quite a bit! It doesn't have flash and code is only loaded to SRAM over USB when you connect the controller to the host, so that's pretty flexible.
So far I've been practicing on my saleae logic analyzer clone, which is based on this controller too, but there are cheap dev boards orderable from aliexpress, that have this chip which are not limited to input only.
Muuuch simpler than STM32, and much faster interface. While some STM32 chips have high speed USB, most cheap boards don't include the high-speed PHY, so it's useless.
Can't wait for the dev boards to arrive.
So far I've been practicing on my saleae logic analyzer clone, which is based on this controller too, but there are cheap dev boards orderable from aliexpress, that have this chip which are not limited to input only.
Muuuch simpler than STM32, and much faster interface. While some STM32 chips have high speed USB, most cheap boards don't include the high-speed PHY, so it's useless.
Can't wait for the dev boards to arrive.
Glasgow [0, 1] uses one of these too.
[0] https://www.crowdsupply.com/1bitsquared/glasgow [1] https://github.com/GlasgowEmbedded/glasgow
[0] https://www.crowdsupply.com/1bitsquared/glasgow [1] https://github.com/GlasgowEmbedded/glasgow
That's some fancy oscilloscope, but you can also get that info via usbmon, for example, directly to wireshark.
This video is a follow-up to a mini-series that started with examining the PS/2 keyboard protocol. The oscilloscope is there because the audience is already familiar with it, not because it's the best tool for this particular job.
Yes, I'm not criticizing the author, but it's good to know that you don't need fancy tools and you can get to see the enumeration too on your own devices, practically in similar amount of detail.
It's a DSO first and foremost which just happens to be equipped with a certain $809 option[1] supporting a very specific application.
If you cared about digital decode only, and had confidence in both the SI of your interface and tooling, sure. Great when things "just work"...entirely unhelpful when they don't at the lower layers of hardware domain.
[1] https://www.keysight.com/us/en/product/D4000USBA/usb-2-0-tri...
If you cared about digital decode only, and had confidence in both the SI of your interface and tooling, sure. Great when things "just work"...entirely unhelpful when they don't at the lower layers of hardware domain.
[1] https://www.keysight.com/us/en/product/D4000USBA/usb-2-0-tri...
Yes, but if you ask question "How does USB device discovery work?" (enumeration, I guess) you don't need any fancy equipment to answer that.
It's nice and instructive to "see" the signals using a DSO, but not necessary.
It's nice and instructive to "see" the signals using a DSO, but not necessary.
Is there a text version of the explanation?
In a sense... everything he covers is also covered in the USB spec. I can also personally recommend the book USB Complete by Jan Axelson.
Is there a transcript / blog post version of this 30 minute video? I don't think so.
Is there a transcript / blog post version of this 30 minute video? I don't think so.
[deleted]
Kind of disappointing that his probably very expensive digital oscilloscope can't record the entire protocol. I mean, what is the price of ram these days?
And note that (since it's a digital signal) you don't have to sample evenly; you can also record the timepoints of the edges.
And note that (since it's a digital signal) you don't have to sample evenly; you can also record the timepoints of the edges.
You're not wrong that the price of ram isn't that much these days. However, this is not simply a case of adding more ram and be done with it. There is a significant amount of extra engineering to be done.
It would in the grand scheme of things be rather easy to "just add ram" but that's not how the product lines work for oscilloscopes. It's a bit like asking "Why does Intel price their high-end chips so high? It's not like the silicon is that much more expensive or yields that differ so much that they're 500% more expensive? And the consumer chips don't even support all the features that their Xeon's do!"
And you're right, it's a digital signal, and in the normal world you would just use a logical analyzer and do it like you said. But this is for educational purposes and seeing the same tool and the actual edges is a great and clear example. That's not to say that oscilloscopes aren't useful for debugging digital signals. After all, seeing the exact glitch might help in some cases.
So yeah, basically it's a combination of product differentiation and not the entirely right tool for the job.
It would in the grand scheme of things be rather easy to "just add ram" but that's not how the product lines work for oscilloscopes. It's a bit like asking "Why does Intel price their high-end chips so high? It's not like the silicon is that much more expensive or yields that differ so much that they're 500% more expensive? And the consumer chips don't even support all the features that their Xeon's do!"
And you're right, it's a digital signal, and in the normal world you would just use a logical analyzer and do it like you said. But this is for educational purposes and seeing the same tool and the actual edges is a great and clear example. That's not to say that oscilloscopes aren't useful for debugging digital signals. After all, seeing the exact glitch might help in some cases.
So yeah, basically it's a combination of product differentiation and not the entirely right tool for the job.
I have designed and commercially released an open source (USB) oscilloscope.
There is absolutely no reason you can't just add more RAM (and a memory controller), or even add user upgradeable memory. If the big players don't do it, a newcomer will and they'll fall further behind the curve.
There is absolutely no reason you can't just add more RAM (and a memory controller), or even add user upgradeable memory. If the big players don't do it, a newcomer will and they'll fall further behind the curve.
Could you provide more information, please? Thanks.
I'm not quite sure what you mean.
There is no technical barrier that prevents an oscilloscope manufacturer from adding a DRAM controller to their designs, either via an IC or as an IP core in their main FPGA.
The cost would be relatively low, too, and long traces are extremely useful especially for beginners.
Market forces will work to make this a reality.
There is no technical barrier that prevents an oscilloscope manufacturer from adding a DRAM controller to their designs, either via an IC or as an IP core in their main FPGA.
The cost would be relatively low, too, and long traces are extremely useful especially for beginners.
Market forces will work to make this a reality.
He probably wants a link to your scope.
Oh yeah, that was dumb of me.
https://espotek.com/labrador
Doesn't have an on-board DRAM controller, but I did look into the feasibility of it early on. In the end, I decided it was easier to just use the memory of the attached PC. Can record 10s of continuous data without dropping a single sample.
https://espotek.com/labrador
Doesn't have an on-board DRAM controller, but I did look into the feasibility of it early on. In the end, I decided it was easier to just use the memory of the attached PC. Can record 10s of continuous data without dropping a single sample.
Thanks!
>I mean, what is the price of ram these days?
It's probably more of a bandwidth issue than a memory issue. USB 2.0 runs at 480 Mbit/s, so if the oscilloscope can decode that, it would have to be able to output/store at least that much in terms of bandwidth. A USB keyboard would never hit that type of bandwidth, but presumably a buyer of such expensive oscilloscope would expect the feature to work every time, rather than only in best case scenarios.
>And note that (since it's a digital signal) you don't have to sample evenly; you can also record the timepoints of the edges.
Depending on the signal characteristics this can actually be worse. eg. if it switches very rapidly you'd probably be better off storing the reading as PCM or something, because the timestamps (which are presumably nanosecond level) would take more space to record than the raw sample reading (a few bits at most).
It's probably more of a bandwidth issue than a memory issue. USB 2.0 runs at 480 Mbit/s, so if the oscilloscope can decode that, it would have to be able to output/store at least that much in terms of bandwidth. A USB keyboard would never hit that type of bandwidth, but presumably a buyer of such expensive oscilloscope would expect the feature to work every time, rather than only in best case scenarios.
>And note that (since it's a digital signal) you don't have to sample evenly; you can also record the timepoints of the edges.
Depending on the signal characteristics this can actually be worse. eg. if it switches very rapidly you'd probably be better off storing the reading as PCM or something, because the timestamps (which are presumably nanosecond level) would take more space to record than the raw sample reading (a few bits at most).
> It's probably more of a bandwidth issue than a memory issue.
Yeah, but you can use multiple banks and write in a round-robin fashion.
> Depending on the signal characteristics this can actually be worse.
Of course, that was only an example. You should probably do something like runlength encoding.
In any case, the USB protocol is much slower than modern hardware can handle, so certainly doable.
Yeah, but you can use multiple banks and write in a round-robin fashion.
> Depending on the signal characteristics this can actually be worse.
Of course, that was only an example. You should probably do something like runlength encoding.
In any case, the USB protocol is much slower than modern hardware can handle, so certainly doable.
Consumer grade DDR4 modules have a bandwidth of 25.6 GB/s. Even at 10 samples per bit you're laughing.
AFAIK Keysight MegaZoom uses ASICs with on-chip sample memory, so that's why it's relatively limited. You can get oscilloscopes with more conventional architecture with FPGA connected to boatloads of external DRAM, but it comes with other tradeoffs. (usually much lower wfm/s)
As you have seen, he could record the entire protocol with segmented memory. There is also a type of instruments called "logic analyzer" or mixed oscilloscope, where you just watch a digital signal, one or zero. The analog scope signal does say so much more than just one or zero. Of course he didn't needed really the analog signal, but it looks nice.
Because it is not the right tool for the job.
A cheap logic analyzer, like DSLogic, would probably work much better for the specific use case.
A cheap logic analyzer, like DSLogic, would probably work much better for the specific use case.