Connecting to embedded design
Universal Serial Bus (USB) is a connectivity specification that provides ease-of-use, expandability and good performance for the end-user. It is one of the most successful interconnects in computer history. Originally released in 1995 for PCs, it now is expanding into use by embedded systems and is replacing older interfaces such as serial and parallel interfaces as the preferred communication link. This article has been written as a tutorial on some of the many ways in which USB can be employed in embedded systems.
USB is not a peer-to-peer protocol like Ethernet. One USB device (the ‘USB host’) acts as the master, while others (‘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 six 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 is usually 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, or another defined type. One USB device stack can support more than one function driver simultaneously, through the composite device framework.
An attractive 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 yet widely used in embedded systems.
What follows are descriptions of six examples of how USB can be utilized in an embedded system. Where performance information is given, a “medium performance processor” is assumed to be a 50-80 MHz ARM7 or ColdFire.
1. PC to device via USB serial
Most new PCs and laptops do not provide serial or parallel ports; they 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 OSs 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. This use of USB is particularly good for control and transferring serial data. Transfer rates of 800 KB/sec are feasible at full speed and 2,500 KB/sec at high speed for medium speed embedded processors.
2. PC to device via USB disk
Another way of connecting a PC or laptop to an embedded device is for the embedded device to emulate a USB disk drive. Popular PC operating systems have built-in USB mass storage class drivers that interface their file systems to the USB host stack, as shown on the left of Figure 2. Adding a mass storage function driver to the embedded device enables it to look like a USB disk drive to the PC. The figure also shows how a resident flash memory can be accessed as a flash disk via the USB function driver connected to its flash driver.
Any other type of storage media could be connected, instead, via its own driver. When the embedded device is plugged into a PC, it is recognized as a disk drive and automatically assigned a drive letter. Thereafter, files can be dragged and dropped to and from the embedded device as though it were a disk drive. In this example, a PC application could read and write the files on the flash disk. Note that the embedded application uses a local file system to access the flash disk itself. This file system must, of course, be OS-compatible. An important concept to understand is that within the PC, the PC’s file system is used and the embedded device merely looks like another disk drive to it. This use of USB would be particularly good for uploading acquired data files or downloading new versions of code files.
3. Web server access via USB RNDIS
RNDIS (Remote Network Driver Interface Specification) permits emulating Ethernet over USB. It is not part of the USB specification, but some popular PC OSs, such as Windows and Linux, support it. As shown in Figure 3, adding an RNDIS function driver to an embedded device allows for the interfacing of its USB device stack to its TCP/IP stack, which in turn, connects to its Web server. When the embedded device is plugged into a PC, its browser can connect to the Web server in the embedded device. Hence, it is possible to use a browser to access an embedded device’s Web server, even when there is no Ethernet connection or it is difficult to access. This can be convenient for field troubleshooting or configuration using a laptop. The same information accessed via the network to which the embedded device is connected can be accessed via USB.
4. USB multi-port serial device with UART and other connections
In Example 1 we examined the implementation 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 compared with other similar technologies. Figure 4 shows the block diagram. The CDC ACM class driver in the PC may not be the native driver that comes with the PC OS. A special driver 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. In the embedded device, the USB CDC function driver de-multiplexes the serial channels. Note that, in this example, one channel goes to an application task, which might return certain internal information, and the other two serial channels connect to actual UARTs. The application in the PC can communicate with physical devices, (e.g., modem, barcode reader, printer, etc.) connected to the UARTs as though they were connected directly to serial ports on the PC. For example, with a medium performance processor and full speed USB, a total bandwidth of 200KB/sec is achievable. This would support fifteen 115.2Kbaud channels, with capacity left over.
5. USB composite devices
It is actually possible for one USB device to look like multiple USB devices to a USB host simultaneously. This is made possible by the USB Composite Device Framework, as shown in Figure 5. The USB host (a PC in this example) will recognize each USB device within the embedded device and load its corresponding class driver. The device looks like a USB disk and a serial port. Note that both function drivers are present. This example is a fairly common case that is supported by PC OSs. This particular one would support an application in the PC transferring files, and another application allowing an operator to control or configure the embedded device.
6. USB thumb drive support
Figure 6 shows how an embedded device can access a USB thumb drive (aka USB memory stick). A mass storage class driver fits between the USB host stack and the local file system in the embedded device. It creates the usual read/write logical address API expected of media drivers. Naturally the file system must be OS-compatible in order to exchange thumb drives with a PC. Thumb drives are commonly used to transfer data from embedded devices to PCs or to update firmware or configuration settings and tables in embedded devices.
Yingbo Hu is R&D embedded software engineer at Micro Digital, and Ralph Moore is the company’s president.
