Making USB devices – end to end guide to your first gadget
popovicu.com
popovicu.com
Can anyone recommend any good USB controller ICs? I normally just use a microcontroller with USB built in.
https://compliance.usb.org/index.asp?UpdateFile=Electrical#:....
------------
I like the pMOS constant-slew rate trick myself.
A number of voltage-regulators have soft-start ramp-up already built in. But if your project doesn't have one, you can build it out of pMOS pretty easily. With just a resistor + capacitor on the pMOS (serving as negative feedback, to slow down the start), you can arbitrarily slow-down inrush current to whatever values you wish.
https://www.ti.com/lit/an/slva156/slva156.pdf?ts=17176224951...
Constant-slew rate voltage control vs a capacitive load effectively creates current-controlled startup functionality. So its "good enough" for most people's purposes (assuming capacitive loads are what's causing you to be worried).
So its a bit of an A-problem vs B-problem here. I'm giving you a slew-rate controlled soft start circuit when you asked for current control. But... its probably what you want?
> but I'm guessing there must be better integrated solutions (e.g. with temperature protection, etc.)
I believe the "proper" solutions are called a "load switch", of which there are a huge variety of integrated chips and MOSFETs with load-switch (constant slew rate + temperature control) solutions available.
EDIT: Something like this: https://www.nxp.com/products/power-management/smart-switches...
Things get rather complicated as you edge into "proper" solutions. I'm just a hobbyist though, so I don't have much experience with these "proper" designs.
EDIT2: Maybe that NXP Load switch is a bit "too full featured" for most projects. This TI one I found seems to be more mainstream and simple. TPS22950CQDDCRQ1 (https://www.ti.com/product/TPS22950-Q1)
And a note on the differential routing and impedance: For USB 2.0, it's not a big deal. Keep the traces of similar length, and reasonably direct. Probably next to each other. You probably don't need to worry about fine-tuning the length and trace widths, impedance control, RF best practices etc. Just connect the nets.
Will you need to respin a board because you needed to use a 20 mil trace instead of 24 mil? Probably not. All things considered, laying out a USB 2.0 differential pair is pretty low stakes. But you should still try and do it right - it's good practice.
But if you are worried about soldering more fiddly stuff like those ARM processors: It doesn't have to be that big, STM32 is nice if you need the power, but for smaller stuff smaller controllers can be preferrable.
E.g. one may also consider using VUSB, which is a library that bit-bangs USB on small Atmel microcontrollers: https://www.obdev.at/products/vusb/index.html Example board schematic we've used to teach students Linux kernel module programming: https://gitlab.cs.fau.de/i4/passt/passtboard-v2 with firmware http://www.poempelfox.de/ds1820tousb/ and https://gitlab.cs.fau.de/i4/passt/ds1820tousb
Also very easy, if you are inclined towards Arduino style programming there are tons of boards you can just use as USB devices with the included libraries in very few lines of code, for example https://www.az-delivery.de/en/products/digispark-board
If soldering's a worry, you can get quite reasonably priced dev boards with the microcontroller USB port already fitted and working - such as the NUCLEO-F429ZI https://www.st.com/en/evaluation-tools/nucleo-f429zi.html
Very similar to the NUCLEO-F103RB board the post author used, but as well as the USB connector at the top of the board for the built in programmer/debugger, it also has one at the bottom of the board, wired straight to the microcontroller.
You can also download the board's schematics, if you want to copy their choice of ESD protection and suchlike.
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.
Most hardware support for isochronous transfers requires DMA on the MCU side, so it tends to be a pain unless your vendor has a library that handles it for you.
You can in general send up to 19 bulk transfers in a single frame (even on a single endpoint), but again, vendor libraries differ wildly in their support for this.
Data larger than one packet can be sent as a multi-packet "transfer". This is where bulk transfers get their throughput -- at full speed, the largest bulk packet is only 64 bytes, but you can send 19 bulk packets per 1-millisecond frame, which gives 1216 bytes/millisecond, more than the 1023 bytes/millisecond possible with isochronous.
You might be able to force the hardware to send nonstandard packets, but then it's not really USB any more.
For super quick easy custom controllers, also consider pulling the control board from discarded USB keyboards. Use conductive glue instead of solder to attach wires to the contacts, and a helping of hot glue to keep them secured. I've made cheap but very robust 1-button game controllers with an arcade button that sends a space bar click. You get all the debounce etc, no code.
You just need to implement an USB billboard device (optional to make it work, but required by the spec IIRC) and signal the correct alternate function. Then DisplayPort signalling will be present on the USB-C plug. Then just connect the right AUX wires to the DisplayPort connector.
I don't know that there are any fully-baked solutions for it though, but it's definitely doable in-FPGA with some effort.
It hasn't only just been fun, it's also proven to be a big help with an Android app I've been working on :)
You'll need something like a shell script on the Raspberry to initialize the composite kernel module and you'll find the boildplate in the kernel docs.
pikvm is an interesting project.
It will hook to a PC, and the USB connection can not only pretend to be a keyboard and mouse, but it can be a USB drive that you can boot the system with. Pretty interesting for installs.
You must pay a one-time fee of $6,000 in exchange Vendor ID [0].
So yes, you are technically right, but it really doesn't matter all that much in practice. USB is by far one of the most accessible major hardware standards out there.
(Of course if your USB device needs Windows drivers, you'll still have to deal with things like code signing...)
[1] https://community.st.com/t5/stm32-mcus-embedded-software/dea...
For a lot of products the VID/PID combo isn't that important on a protocol level, and there's technically no reason why two completely unrelated products couldn't be using the same pair. In practice you're mainly going to use them for software to target a specific device, for example the Linux HID driver uses it to work around hardware/firmware bugs. But HID devices are self-describing, and that's the main mechanism used by the driver to figure out what has been attached and how to behave.
If modern OSes can do the same to distinguish hardware with the extra field, sharing the same value for backwards compatibility with legacy machines really isn't going to be a big deal. It's not like MAC or IPv4 addresses where a clash will essentially kill all communication.
Since very few companies have 65,535 products, almost all Product IDs in any given Vendor ID namespace are unused.
That is the maximum number of organizations on Earth that can be issued a USB Vendor ID until the spec is modified. They'll likely introduce a special Vendor ID that indicates to clients they should look elsewhere for the real (and longer) one.
While the rules were more lax many years ago, and some vendors are grandfathered in and can therefore share their Product ID allocation, these behaviors are explicitly prohibited by the USB-IF for newly issued Vendor IDs.
If you plan to deploy more than a few devices you'll need a Vendor ID and people should know that there is a relatively large tax in front of that need.
Hard disagree on $6,000 not mattering. We build a small number of devices for severely disabled people and sell a few hundred a year. The USB IF was unwilling to budge at all on their prices and this was a large cost that we did not anticipate, and by the way, is technically shameful.
How much does a fucking number cost?
Well, it depends on how scarce you decide to make it, and of course, what the market will bear.
For the DirtyJTAG project we use one of those:
[0] https://community.nxp.com/t5/Kinetis-Microcontrollers/NXP-US...
I will think twice now before saying “why couldn’t they just use USB for this?”
I dunno, I think either you're doing a small run and you can just bake in a Teensy or whatever, or you're doing a big run and $6k is a drop in the bucket.
Many, many products start life on a shoestring and small batch production runs.
There are other products that intentionally serve small markets, like people with disabilities.
For these organizations, $6,000 is not a trivial amount of money.
What are they gonna do when they run out?
The wiring of the ports on a new design is straightforward; you are using the same pins if it's USB 2.0 (As the article says), plus two extra connections that go to a resistors. If you can find ports that use the same footprint, feasible, but probably not worth it. Desoldering a port is a pain because you have to get all the pins to melting temperature concurrently, and you'd have to figure out how to wire those CC pins.