Beyond Logic

When I looked for resources about USB, this website is recommended frequently: https://www.beyondlogic.org/usbnutshell/usb1.shtml

"USB in a Nutshell" [1] was really useful to me. As far as tooling goes I'd take a look at the "usb-tools" project [2] on Github. The GreatFET One hardware [3] is good and works with the Facedancer software hosted by the usb-tools project. I enjoyed working on USBQ and learned a lot by doing it but the kernel loadable module it depends on wasn't written by me and probably needs some love. The usb-tools project and the related hardware has advanced quickly. Were I to do the same project over again (hacking Zwift for fun) I'd probably start there. There is so much to USB... even some surprising things! [4] [1]: https://www.beyondlogic.org/usbnutshell/usb1.shtml [2]: https://github.com/usb-tools [3]: https://www.greatscottgadgets.com/greatfet/one/ [4]: https://link.springer.com/chapter/10.1007%2F978-3-030-28752-8_6

I recently wrote a user space driver for my Clevo laptop's backlit keyboard. I'm currently trying to convert it into a Linux kernel driver. I'll describe my approach. First of all, I had to realize that the keyboard was in fact controlled via USB. It seems obvious but other Clevo laptops did it via ACPI: https://github.com/tuxedocomputers/tuxedo-keyboard/blob/master/src/tux… https://bitbucket.org/tuxedocomputers/clevo-xsm-wmi/src/master/module/… I assumed my laptop worked the same way and wasted a lot of time dumping my laptop's ACPI tables and trying to figure them out. I even installed some Windows tools to decompile the WMI buffers. Didn't find anything. I was about to give up when someone on IRC set me on the right path and I was able to make progress. Even though I saw my keyboard on lsusb output, I never thought to look for a USB protocol. Learned this one the hard way. Before I started, I emailed Clevo and asked for technical documentation on the keyboard. Their marketing department replied: "Ubuntu was not supported". I emailed Tuxedo Computers (mentioned above) and they were much more helpful: their developers shared a fan control application they wrote with me! It was great but the keyboard drivers were missing. So I decided to reverse engineer it. While not as complex as the VGA-to-USB device, the process of reverse engineering the keyboard was similar: 1. Boot Windows 10 with the proprietary driver 2. Start Wireshark 3.…

And that is why it is such a great tool for learning. Lets start here: > I/O: * SS10 -- Fast SCSI: 80 Mbit/sec theoretical max > * Rpi -- USB2 480 Mbit/sec. Now there are certainly > complaints about poor USB performance, but it's not > so bad that the SS10 would beat it The SBus[1] is slower than High Speed USB[2], and yet the amount of code it takes to get 1 megabyte of data from a USB peripheral into the memory of a CPU is greater. USB is polled, the Host Controller has to continually check to see if there is something out there, SBus is not allowing it to initiate transfers from the peripheral. Further things like key presses compete with network packets for attention from the root HUB. While transactions on the Sbus(es) can happen in parallel. Then there is the SDIO interface for the RPi's flash disk, which also competes with USB for I/O cycles on the ARM AHB bus. So at the end of the day some things are really faster (like graphics) and some things slower (like I/O), and the whole package feels remarkably similar. Can't argue on the price though, you still can't get a working SS10 for $35 as far as I can find. [1] SBus specification -- http://bitsavers.informatik.uni-stuttgart.de/pdf/sun/sparc/800-5922-10… [2] My go to USB spec site -- http://www.beyondlogic.org/usbnutshell/usb1.shtml [3] Summarized SS10 information -- http://www.obsolyte.com/sun_ss10/ [4] Gateway to the simplified SDIO specs --…

Links I found interesting: http://www.beyondlogic.org/usbnutshell/usb2.shtml http://electronicdesign.com/boards/480-mbitss-signal-integrity-becomes… (neither explicitly discusses FPGA USB 2.0 implementations)

It could probably be done with isochronous mode (http://www.beyondlogic.org/usbnutshell/usb4.shtml#Isochronous), but realistically it's easiest to just delegate all the real-time stuff to a $1 microcontroller on the other end of the USB link.

On a related note: back in a previous, embedded incarnation, I was once tasked with writing a USB driver. Not the kind that might first come to mind - this was for the /device/, for which documentation is rather less easily found. With the aid of this resource (no, no spam), I was able to make our gadget come up as a fully compliant composite HID/microphone device. http://www.beyondlogic.org/usbnutshell/usb1.shtml

USB is a complex protocol, encoded using just two wires (the other two are power - +5V and GND). There are no pins you can steer high or low. See http://www.beyondlogic.org/usbnutshell/usb1.shtml for more info.

Homework? I had this assignment while studying Operating Systems Design during college. I can tell you I failed miserable. We used documentation from: http://www.beyondlogic.org/serial/serial.htm. You can find some examples there, but not for the Linux kernel.

Ive written bare-metal USB code on an MCU before, and I found it to be quite a shock compared to simple digital protocols like SPI or I2C. The physical and data link layers aren't much more complicated than, say, CAN, but beyond that you immediately run into a brick wall of descriptors, endpoints, and driver configuration. USB was designed from the ground up to be a plug-and-play ecosystem for PCs, and it really shows. Using the vendor-provided software as much as possible is definitely the way to go if you can. Some half-remembered hints: You want bulk transfers for high throughput (don't even look at isochronous). USB is a master/slave protocol so if you're not getting peak throughput it's usually due to something on the host (PC) side. If the license (LGPL) is compatible with your needs, libusb is pretty easy to use. If you're not using the vendor driver, a hardware USB protocol analyzer is really helpful. USB in a NutShell[1] is a decent web reference for understanding the protocol. [1] https://www.beyondlogic.org/usbnutshell/usb1.shtml

:x86: Apart from the drawing boards at Intel when the 80286 was designed, can anyone find any evidence or have first-hand experience that rings 1 and 2 were ever used in any specific commercial purpose? (I haven't heard or seen of it.) 286 protected mode was generally a flop (outside of OS/2), while 386 protected mode was significantly better. The LDTR (-> LDT) and hardware task switching (reloading TR) aren't typically used. GDTR (-> GDT), TR (->TSS) and IDTR (->IDT) setup are essential. The TSS includes where to find the 6-7 stacks, and for a permissions mask for port I/O. Double fault handler (in the IDT -> INT 8) is typically what leads to a colorful screen of death. When the double fault handler fails (or the IDT or was overwritten), a triple fault happens and the CPU halts or the virtual machine does it own impression of a colorful screen of death without (usually) actually killing the host machine. An invalid opcode handler permits handling CPU-unknown opcodes in the OS such as using emulation or other hardware. Note that generally most PCs prior to UEFI/EFI booted in real mode with 1 core running, so writing a parallel and concurrent OS typically involves setting up protected mode structures, switching to protected mode, and then talking to the APIC for every other…