Take the 2-minute tour ×

Is USB a reasonable choice for a local bus?

what are pros and cons?

what reliability concerns are there?

Bus spec device count ~4; peripheral devices are permanently connected to same PCB as host (soldered or via headers).

Some device are puny, e.g. serial port or temperature sensor, some are complex, e.g. an LTE modem or ethernet or wifi. Peripherals are such that are available as standalone USB devices or same chips are used in such devices. Linux is supposed to have all the drivers already.

Ideally I'd use only one bus (with hubs if necessary) for simplicity and eventually modifications without some components and with other low-speed components.

System spec ARM, Linux, DC powered, roughly equivalent to an Android tablet.

share|improve this question
Beware that while USB can move a lot of data quickly, it has shockingly high latency, so if you have or ever expect to need low latency peripherals or interactions, make sure that it isn't your only path to hanging something off your processor. –  Chris Stratton May 12 '14 at 17:57
Reliability concern: USB is a horribly complicated pile of crap. The four wire bus itself is simple, but then there is the software. –  Kaz May 13 '14 at 14:32
@Kaz, I share your concern on anecdotal level, if you have technical details and numbers to back up your claim, how about converting your comment into a full-fledged answer? –  user17857 May 13 '14 at 15:42

4 Answers 4

What you are looking at is a problem I like to call bus hierarchy.

You have high speed devices that need a fast low-latency path to the CPU (like the LTE modem) and slow devices like the temperature sensor. Connecting a full fledged LTE modem over I2C will seriously bottleneck the system. And connecting a temperature sensor on USB is a serious overkill. You need to prioritize.

What devices are to be accessed most often? Which ones need to respond quickly? And which don't need that much bandwidth?

Feel free to edit your question.


USB may not be such an overkill after all. Only in the latest versions of it (2.0, 3.0) it has gotten the notion of being targeted to fast peripherals only. Before that, it was simply a Universal Serial Bus.

This doesn't change anything on the fact that it's implementation cost is very often too high.

share|improve this answer
Those are the words I was trying to come up with. –  Matt Young May 12 '14 at 12:50
Edited. for example raspberrypi integrates ethernet over usb, extensibility wrt. different versions of the product and ideally only one bus is the general idea. Question is if the idea is sensible. –  user17857 May 12 '14 at 13:03
If a temp sensor on usb is overkill, then what does that make a usb keyboard? A crime against humanity? Low data low power devices like kayboards, mice, and temp sensors are why USB 1.1 low speed was invented. –  Passerby May 12 '14 at 17:19
@Passerby There is a significant difference between a keyboard and a temperature sensor, in that a keyboard is a consumer product that needs "plug-and-play" but the temperature sensor is a hardwired device. It's worth the extra pain to make a keyboard user-friendly; I don't think USB makes sense for a temperature sensor. –  Joe Hass May 12 '14 at 19:28
@Passerby I think you have provided your own evidence. If you look at the laptops you used as an example you will find that the temperature sensors are connected to an I2C bus rather than USB. –  Joe Hass May 12 '14 at 21:55

Unless the device already has a USB interface, such as a keyboard or mouse, this is going to entail a lot of work and extra hardware. For example, connecting to a temperature sensor that only has an I2C interface. You are not going to be able to add a USB interface to the sensor, so you will have to add a small microcontroller, such as a PIC18 that has both a USB device and I2C interface. The PIC then talks USB back to your host and I2C to the temperature sensor. But why not just connect the temperature sensor directly to your host microcontroller?

share|improve this answer
The questions assumes availability of USB-interfaced peripherals. It is about integration and practical concerns. –  user17857 May 13 '14 at 15:58
@qarma That assumption wasn't stated in the original question (before the edit). –  tcrosley May 13 '14 at 16:07



  • good for 50Mhz
  • can communicate with multiple slaves
  • simple protocol
  • Full duplex Cons
  • Not a standard interface



  • many slow chips uses I2C
  • broadcast protocol where multiple slaves can reside on the bus


  • slow speed
  • more complicated than spi



  • standard interface
  • probably driver ready and tested


  • very complicated to debug
  • with hub, the peripherals will share bandwidth

Other interfaces include SDIO, UART etc

Again as already mentioned, you will have to define the bus hierarchy with your bandwidth requirements. Probably the LTE modem would require a direct memory interface or a PCI interface.

Also there are phy translators like FTD232 (http://www.ftdichip.com/FTProducts.htm) which can do USB-Spi, usb-uart etc and is widely used

share|improve this answer

Based on your needs, yes, usb is ideal. Keep in mind, the U does stand for universal. You can have usb nics, wifi, mouse/keyboard/touchpad/touchscreen, sound cards, webcams, hell, even usb displays. It's not the most effecient, but for two nics, a temperature sensore, and a serial device, its designed for it. So much that the majority of computing device manufacturers rely on it heavily.** Not just cheapo sbcs or tablets, but even heavy hitters like Apple and Dell use it for touchpads and keyboards and webcams and wifi and bluetooth and ir ports in all their laptops.**

USB is ubiquitos, easy to implement, and has a very low board cost in terms of routing and parts.

While you can get 4 port arm devices, most have one or two root ports (buses), then connected to a hub ic. Your biggest bottle neck will be mixing High speed devices with Full or Low speed devices on a single hub. Cheap hub ICs have a Single Transaction Translator, that can bring a single low or medium speed downstream device to a high speed uplink. Better ones will have a MTT, Multiple Transaction Translators, so multiple low speed devices can be bridged at high speed speed. Or simply ensure that the low speed are on one hub while high speed on another.

But since you have arm as the intended SOC, you will have access to proper buses for sound or i2c or spi (for the temp sensor or serial) or video or even a built in ethernet driver minus the magnetics. Higher end ARM chips comparable to cheap Android tablets or routers are fully loaded.

share|improve this answer
I must disagree - in no way I think the USB is easy to implement. –  Dzarda May 12 '14 at 19:24
@dzarda you can bit bang usb with a 30 cent microcontroller. You can add usb to a product with six resistors and 2 caps at most. You couldn't find a Linux ARM SOC without usb if you tried. USB is easy to implement when the soc has it builtin and linux kernel writers have support established within weeks. Google ddwrt ub if you doubt me. –  Passerby May 12 '14 at 20:07
+1. Also, don't forget the developer friction with Linux device drivers. For widely available peripherals with existing USB support (think network, WiFi, removable storage) then leveraging already existing device drivers will be a huge advantage over possibly having to write your own driver to gain low level access to a SOC peripheral that may not already be supported by your Linux kernel. That win might be big enough to make the 8-pin PIC implementing low-speed USB for a temperature sensor worth it. –  RBerteig May 12 '14 at 23:02
+1 for technical STT/MTT explanation. –  user17857 May 13 '14 at 8:57

Your Answer

