We’ve been recently looking into USB 2.0 – the ubiquitous point-to-point communications standard. USB 2 is completely different from USB 3, the blue-connector next-generation USB standard. For instance, USB 2 is a full-duplex pseudo-differential bus, and it’s not AC-coupled. This makes USB2 notoriously difficult to galvanically isolate, as opposed to USB 3. On the other hand, USB 2 is a lot easier to incorporate into your projects. And perhaps the best way to do so is to implement a USB hub.
USB 2 hubs are, by now, omnipresent. it doesn’t cost much to add to your board, and you truly have tons of options. The standard option is 4-port hubs – one uplink port to your host, four downlink ports to your devices. If you only have two or three devices, you might be tempted to look for a hub IC with a lower amount of ports, but it’s not worth bothering – just use a 4-port chip, and stock up on them. multi port ethernet adapter
What about 7-port chips? You will see those every now and then – but take a close look at the datasheet. Some of them will be two 4-port chips inside a single package, with four of the ports bottlenecked compared to the three other ports – watch out! Desktop 7-port hubs are basically guaranteed to use two 4-port ICs, too, so, again, watch out for bottlenecks. lsusb -t will help you determine the hub’s structure in case you don’t want to crack its case open, thankfully.
Recommendations? I use SL2.1 chips – they’re available in an SO16 package, very unproblematic, to-the-point pinout and easily hand-solderable. CH334 is a close contender, but watch out because there are different variants of this chip that differ by both package and pinout, so if you’re buying a chip with a certain letter, you will want to stick to it. Not just that, be careful – different variants run out at different rates, so if you lock yourself into a CH334 variant, consider stocking up on it.
There’s no shortage of Western-origin chips, either – Texas Instruments is a leader here no doubt. If you ever fear running out of hub ICs in your stock while assembling something, you can prepare for this in advance by leaving zero-ohm footprints under the hub’s package. USB 2 doesn’t care for stubs much, and such a hack is very easy to do with SL2.1 in particular. Got two extra ports left over? Put them on a PC-case style dual USB2 9-pin header – there’s never a shortage of fun accessories compatible with it!
Powering USB2 hub ICs is easy – they tend to include a 5 V to 3.3 V linear regulator inside, so you can power them from a 5 V source directly. On the other hand, if you don’t have any 5 V to spare, the overwhelming majority of hub ICs can be powered from 3.3 V directly – usually, that requires shorting the hub’s 5 V input to 3.3 V, but not necessarily. If the datasheet is unclear on 3.3 V-only operation, leave in some 0R jumpers. And, of course, make sure to add 100 nF or similar capacitors – one per hub IC’s power pin. Remember the disclaimer about built-in RC oscillators in MCUs being imprecise? Same goes for hubs – if your hub boasts an internal RC oscillator, don’t trust it, make sure you have a crystal footprint you can populate if you get stability issues.
Putting some USB port pins to the outside world? You will want to protect them from harm – or, rather, you will want to protect your expensive CPU from harm.
Bringing USB somewhere far, or even just using it as your link to the external world? You should really use ESD diodes – or at least plan them in and give yourself the option to populate them later. There’s no shortage of USB2-capable ESD diodes, after all, and ESD problems are closer than you might expect.
For instance, I’ve recently built a pocket device consisting of a battery-powered Pi Zero and a USB soundcard connected to wired headphones, with a pretty standard kind of long cable. I wear a lot of synthetic clothes, in particular, hoodies and jackets, and I kept having the Pi reboot every time I took my jacket off or put it on, through static electricity induced into the headphone wires through the cable insulation, going into the USB port on the Pi Zero.
So, I went and put ESD diodes on the USB 2 pins, using the footprint I previously added to my board “just in case” but didn’t populate, and this failure mode has instantly disappeared for good. Remember, footprints are free, and bodges cost time. Want a recommendation? The four-channel diodes are pretty good for USB 2; look for the SRV-05 footprint in KiCad, in the SOT-23-6 package. It’s a generic enough footprint that there’s no shortage of ESD diode packs in the same footprint, they’re low-capacity enough that you can even use it for purposes like captouch pad protection, and they will also work for applications like Ethernet or externally available GPIOs.
Do you need ESD diodes? Yes, just add the footprint. Same goes for over-current control switches, by the way – I’ve already talked about the SY6820, but it bears repeating. Your entire system doesn’t have to reboot when you short-circuit a USB port on the board, and a cheap current-limited switch IC will let you ensure that’s the case, while also letting you switch the port power on and off, as a nice bonus.
This was just a few tips on and around USB 2 hubs and connectors, but I hope it helps you out with your projects.
Inre: 4 port hubs Last month I dug through a box of parts and it had maybe 5 or more USB (1.1?) hubs in it… Plus another 3 elsewhere.
When looking for a USB 2 hub there is one more thing to look out for: Multi Transaction-Translator vs. Single Transaction Translator.
This matters when you have multiple low-speed or full-speed (12 MBit/s) devices connected to your hub. Even if the hub itself it capable of high-speed (480 MBit/s) it won’t be able to use this speed to combine the traffic of multiple slower devices if it just has a Single Transaction Translator. It needs the Multi Transaction-Translator for this.
My cheap go-to hub IC is the Genesys GL852G.
The SL2.1a is a single-transaction (“STT”) hub, so it severely restricts the downstream bandwidth if you’ve got FS/LS devices. The CH334s (at least recent ones) are MTT hubs.
This article feels like it’s missing a lead-in paragraph or two.
It does! I might have fat-fingered something. Hold on a sec.
And perhaps the best way to do so is to implement a USB hub.
I’m still looking for the bottom line. You want USB2 – implement a hub – then what? In what sort of a project would I need this?
what’s the difference between the SY6820 and a polyfuse, if i don’t need an off switch?
“with four of the ports bottlenecked compared to the three other ports”
Does cascading USB hubs really cause a bottleneck? AFAIK they are mostly transparent, with very slight round trip delay added per packet.
I don’t think it causes a bandwidth bottleneck because the ‘sharing’ basically happens upstream (the OS sees 7 USB devices, and it shuffles transactions between them equally), but it does generate a tree-depth difference between the two, which can be a problem since the USB spec tree depth is pretty shallow.
To clarify on this: you might think that cascaded hubs would have bandwidth problems like, say, if you cascaded Ethernet switches: if you’ve got ports A, B, C, D and port D has another switch with DA, DB, DC, DD, and they’re all running the same, then the throughput from outside the switch to DA/DB/DC/DD ends up being (1/16th) the outbound bandwidth on average if they’re all fully loaded: the switch has no way of knowing there’s another switch behind it.
But USB doesn’t work that way – it’s strictly request/response, and the hubs aren’t switches: they just broadcast everything they get from the host, and transmit everything they get from all of the devices. There’s no collision avoidance in the hub – the protocol guarantees that.
Which means cascaded hubs don’t cause bottlenecks: if you’ve got those same A/B/C and DA/DB/DC/DD devices, the host just spreads the USB transactions equally between all 7. Data doesn’t ‘queue up’ on that one cascaded port, because it has no place to be stored anyway (but as I mention above, cascaded hubs are a problem because the USB tree depth maxes out at 7 tiers, allowing a maximum of 5 hubs between the root and the device, since the root and device each take a tier).
I can’t seem to find this SY6820 load switch. Is it a typo or am I missing something?
For instance, USB 2 is a full-duplex pseudo-differential bus I’m almost 100% certain that even USB 2.0 High Speed is half-duplex.
Are you sure about the SY6820 reference?
Yeah, I can’t also find anything about it, but I am interested. I am also interested in a blog post about how to implement a USB-C PD Sink and 5V source (in the same USB), if you happen to have any good advice
what’s the difference between the SY6820 and a polyfuse, if i don’t need an off switch?
Personally I have had good luck with the Cypress/Infineon HX2VL hub IC (part number CY7C65632, because what is logic). Plonked it down on a design with 2 external ports and 2 internal ports and it worked first try. Here’s my design if anyone needs a reference! https://github.com/mbed-ce/mbed-ce-ci-shield-v2/blob/master/Design%20Files/Rev2/docs/mbed-ce-ci-shield-v2-schematic.pdf KiCAD symbol and footprint are available in that repository as well!
Please advise who the source is for this SY8620 current limiting switch device. I can’t readily find it; a search turns up Motorola compatible PIAs from the late 70s, ha ha.
Silergy have different part numbers in different parts of the world, and there may be a typo. Look for SY6280AAC.
I was planning to add a usb hub to my dev kit, 1 port will connect to onboard debugger, another to uart bridge to main MCU, and another port to native USB on MCU.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)
This site uses Akismet to reduce spam. Learn how your comment data is processed.
hub 4 port usb 30 By using our website and services, you expressly agree to the placement of our performance, functionality and advertising cookies. Learn more