How does USB device discovery work? [video]
youtube.com
youtube.com
- 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.
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.
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.
[0] https://www.crowdsupply.com/1bitsquared/glasgow [1] https://github.com/GlasgowEmbedded/glasgow
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...
It's nice and instructive to "see" the signals using a DSO, but not necessary.
Is there a transcript / blog post version of this 30 minute video? I don't think so.
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.
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).
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.
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.
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 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.
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.
A cheap logic analyzer, like DSLogic, would probably work much better for the specific use case.