INDUSTRY INSIGHT
USB in Embedded
USB Offers Many Choices for Use in Embedded Systems
USB in embedded systems has been largely centered on dealing with the loss of serial and parallel ports on PCs, the loss of parallel interface printers, and with capitalizing on the low cost and convenience of thumb drives for transporting information. However, USB offers many other capabilities that are available to solve other problems in the embedded space.
YINGBO HU AND RALPH MOORE, MICRO DIGITAL
USB is not a peer-to-peer protocol like Ethernet. One USB device, called the USB host, acts as the master. Other USB devices, called USB devices or USB peripherals, act as slaves. The host initiates all bus transfers. Up to 127 USB devices can be connected to one USB host via up to 6 layers of cascaded hubs. For embedded systems, it is very unusual to have more than one hub. In most cases, one USB device connects directly to one USB host with no hub.
A USB host requires a USB host controller and USB host software. The latter is layered from the bottom up as follows: (1) USB host controller driver, (2) USB host stack and (3) USB class driver. The first layer controls the USB host controller—i.e., it reads and writes registers in the controller and it transfers data. The second layer implements the USB protocol and thus controls connected USB devices. The third layer is device-aware and communicates with and controls the actual device (e.g. disk drive, HID human interface device, CDC communication device, etc.) One USB host stack can support multiple class drivers, simultaneously. In an embedded system there usually is only one USB host controller.
A USB device requires a USB device controller and USB device software. The latter is layered from the bottom up as follows: (1) USB device controller driver, (2) USB device stack and (3) USB function driver. The first layer controls the USB device controller—i.e., it reads and writes registers in the controller and it transfers data. The second layer implements the USB protocol and thus communicates with the USB host stack. The third layer communicates with the class driver in the host and provides the actual device control. It makes the embedded unit look like a USB disk drive, HID, serial device, etc. One USB device stack can support more than one function driver simultaneously, through the composite device framework.
A nice feature of USB is that it is plug and play, which means that a USB device will be automatically recognized shortly after being connected to a host. Also, cabling is simple: There is an A receptacle/plug pair for the host end and a B receptacle/plug pair for the device end. All hosts and devices adhere to this standard, except On The Go (OTG) devices, which are designed for but not widely used yet in embedded systems.
Following are examples, which by no means exhaust the possibilities, of how USB can be utilized in the embedded system, for both host and device. Where performance information is given, a “medium performance processor” is assumed to be a 50-80 MHz ARM7 or ColdFire.
Most new PCs and laptops do not provide serial or parallel ports, which have been replaced with USB ports. Hence, connecting a PC to an embedded device via its RS-232 port is no longer possible. As part of their USB host stacks, popular PC operating systems (Windows, Mac OS and Linux) include Communication Class Drivers (CDCs). As shown in Figure 1, if the embedded device has a Serial/CDC Function Driver then it will look like a serial device to the PC. When it is plugged in, it will be recognized by the PC OS as a serial device, and it will be automatically assigned a COM port number. Then, terminal emulators and other serial applications can communicate with the embedded device without any modification. Hence, we are back to where we started, which, in this case, is a good thing. This use of USB is particularly good for control and transferring serial data. Transfer rates of 800 Kbytes/s are feasible at full speed and 2500 Kbytes/s at high speed for medium speed embedded processors.

In Figure 1 we examined the case of one serial channel over a USB connection. However, it is actually possible to run multiple, independent serial channels over one USB connection. This is practical because of the higher speed of USB, as noted in the Figure 1 discussion. Figure 2 shows the block diagram. The CDC ACM class driver in the PC is not the native driver that comes with the PC OS. It is a special driver that may need to be installed. This driver presents multiple virtual COM ports to the PC application and it multiplexes the corresponding serial channels over the USB connection.

Discuss
|
Thank you for this article. I find it interesting as it lists multiple options for USB usage in the embedded systems world. One article about USB usage in the embedded systems world would be an article with respect to the constraints of real-time systems. How can we rely on USB for a real-time application? What are the key parameters to take into account? Tips from the expert? Cheers, Alain |

Kontron
Interphase