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
Page 1 of 1
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.
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 (such as modem, bar code reader, printer, etc.) connected to the UARTs as though they were connected directly to serial ports on the PC, which we know does not actually have serial ports, anymore. The high throughput of USB makes multiple channels feasible. For example, with a medium performance processor and full speed USB, a total bandwidth of 200 Kbytes/s is achievable. This would support 15 115.2 Kbaud channels, with capacity left over.
Another method to connect 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 side of Figure 3. Adding a mass storage function driver to the embedded device enables it to look like a USB disk drive to the PC. Also shown, as an example, is 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, as shown in Figure 3, to access the flash disk itself. This file system must, of course, be Windows-compatible. It is important to note 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 useful for uploading acquired data files or downloading new versions of code files.
The Remote Network Driver Interface Specification (RNDIS) permits emulating Ethernet over USB. It is not part of the USB specification, but a lot of popular PC operating systems support it. As shown in Figure 4, adding an RNDIS function driver to an embedded device allows interfacing its USB device stack to its TCP/IP stack that, in turn, connects to its Web server. When the embedded device is plugged into a PC, its browser will automatically 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. For example, a handheld or car GPS device may need to have its map information updated periodically. This can be done by plugging the device into the PC or laptop and using the Web browser to upload the new map database.
It is actually possible for one USB device to simultaneously look like multiple USB devices to a USB host. This is made possible by the USB Composite Device Framework, as shown in Figure 5. The USB host (PC in this example) will recognize each USB device within the embedded device and load its corresponding class driver. In Figure 5 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. Many possible combinations are not supported by PC OSs. This particular one would support an application in the PC so a user could transfer files. It could also support another application to allow an operator to control or configure the embedded device.
For example, you may need to frequently download some video or audio files to a portable media player. Treating it as a mass storage device is the best way because you can just drag those files to the removable disk. No special software is needed. But occasionally you may also need to update the firmware to support a new media type. Users should never be allowed to directly view, delete or copy the firmware, so using a serial port channel to update firmware is a better choice. Both mass storage and serial function drivers are needed for this case.
Figure 6 shows how an embedded device can access a USB thumb drive or “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 drive data 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.
For example, an oil field drilling machine may need to save some log information to an external thumb drive because that machine may have limited memory for data storage. So every few days or each month, that log information is retrieved in the field using a thumb drive. Using a thumb drive is the easiest, cheapest and most reliable way to do that. The process copies the log data to the thumb drive and then the machine can clear its own memory. The thumb drive is then plugged into a PC and the data copied to a spreadsheet or database.
Figure 7 shows how an external hub can be used to connect an embedded control unit to multiple sensors and actuators. In this diagram, it is assumed that the sensors are serial devices. They are handled by a serial class driver. The actuators are assumed to be custom devices requiring custom class drivers. A well-structured USB host stack permits easily adding custom class drivers. Standard USB peripherals, such as printers and bar-code readers, could also be added. They would be supported by standard class drivers. For example, a keyboard or joystick would be supported by an HID class driver. A gaming machine is a good example of a unit incorporating custom sensors and actuators and standard USB peripherals.
For another example, a flight simulation device could use serial sensors to collect the pilot’s commands, such as up/down, turn right/left and output calculated data to an actuator to generate the movement of the device and simulate the experience of real flight.
USB is one of the most successful interconnects in computer history. Originally released in 1995 for PCs, it is now being expanded into use by embedded systems. In doing so developers are finding new and creative uses for the basic connectivity that can enhance utility and reduce costs in a wide array of embedded applications.
Costa Mesa, CA.