Chapter 11. USB
No thing happens in vain, but everything for a reason and by necessity.
—Leucippus, On Mind
In Chapter 9, we looked at RS-232C, that old standard of communication that’s not so standard after all. RS-232C has lots of problems and lots of limitations. Getting any two RS-232C devices to talk is not as simple as it could or should be. You need the right cable with the right sort of connectors, and then you need to manually co-ordinate the communication parameters such as data rate, parity, and handshaking. At best it is a nuisance, at worst a headache. For hardware manufacturers, it presents a dilemma. Your goal in developing your product should be to make that product as easy to use as possible. You don’t want users stumbling around with incorrect cables, manually configuring settings, and failing to seamlessly integrate your product with the rest of their system. This doesn’t make for a happy user.
Universal Serial Bus (USB) is the solution. It allows peripherals and computers to interconnect in a standard way with a standard protocol and opens up the possibility of “plug and play” for peripherals. USB is rapidly dominating the desktop computer market, making RS-232C an endangered species. Apple Macintoshes no longer have RS-232C/RS-422 ports, and soon all PCs will go the same way. Therefore, an understanding of USB (and how to build a USB port) is critical if you wish to interface your embedded computer to the desktop machines of the near future. USB supports the connection of printers, modems, mice, keyboards, joysticks, scanners, cameras, and much more.
USB opens a wealth of possibilities, but developing with it is more complex than with RS-232C. USB has the advantage (for the user) that devices interact with the host computer’s OS. No manual setup is required. However, it does add an extra layer of complexity to your software, since your embedded code must interact with the host in the appropriate way. USB can even provide power to peripherals through the same cable as data. No external power supply (or power cable) is required. So for the user, a USB peripheral is simplicity itself.
In this chapter, you’ll get an overview of USB and then go on to see how you can incorporate a USB interface into your embedded system. The protocols and specifications for USB are long and complex, and well beyond the scope of this book. Fortunately, to design USB-based hardware, the task is much simpler. We’ll simply take an overview and then look at a physical USB implementation. For a full look at the standard, a list of vendors, and more documentation than you can shake a cable at, visit http://www.usb.org.
Introduction to USB
There are two specifications for USB: USB 1.1 and USB 2.0. USB 2.0 is fully compatible with USB 1.1. USB supports data rates of 12 Mbps and 1.5 Mbps (for slower peripherals) for USB 1.1, and data rates of 480 Mbps for USB 2.0. Data transfers can be either isochronous[*] or asynchronous.
USB is a high-speed bus that allows up to 127 devices to be connected (Figure 11-1). No longer is having only one or two ports on your computer a limitation. Further, one standard for cables and connectors eliminates the confusion that existed with RS-232C. Devices are able to self-identify to a host computer, and they can be hot-swapped, meaning that the systems do not need to be powered down before connection or disconnection.
The basic structure of a USB network is a tiered star. A USB system consists of one or more USB devices (peripherals), one or more hubs , and a host (controlling computer). The host computer is sometimes known as the host controller . Only one host may exist in a USB network. The host controller incorporates a root hub , which provides the initial attachment points to the host. The hubs form nodes to which devices or other hubs connect, and they are (largely) invisible to USB communication. In other words, traffic between a device and a host is not affected by the presence of hubs.
Hubs are used to expand a USB network. For example, a given host computer may have five USB ports. By connecting hubs, each with additional ports, to the host, the physical connectivity of the system is increased (Figure 11-2). Many USB devices, such as keyboards, incorporate inbuilt hubs allowing them to provide additional expansion as well as their primary function.
The host will regularly poll hubs for their status. When a new device is plugged into a hub, the hub advises the host of its change in state. The host issues a command to enable and reset that port. The device attached to that port responds, and the host retrieves information about the device. Based on that information, the host operating system determines what software driver to use for that device. The device is then assigned a unique address, and its internal configuration is requested by the host. When a device is unplugged, the hub advises the host of the change in state when polled, and the host removes the device from its list of available resources. The detection and identification of USB devices by a host is known as bus enumeration .
USB “knows” about and supports different classes of devices. Each class represents the functionality that the device can provide to the host. Some sample classes (and sample devices) are listed in Table 11-1. A single, physical USB peripheral can encompass several classes.
|
Class |
Purpose |
|
Audio |
Audio and music devices, sound systems |
|
Chip/smart card interface devices (CCID) |
Smart card devices |
|
Common class (CCS) |
Generic devices |
|
Communications device |
Modems, telephones, and network interfaces |
|
HID |
Human Interface Devices (HIDs) such as mice and keyboards |
|
Hub |
USB hub |
|
IrDA |
Infrared devices |
|
Mass storage |
Hard disks, CD-ROMs, DVD-ROMs |
|
Monitor |
Computer monitors and display devices |
|
Physical interface devices |
Joysticks and other devices (such as motion platforms) that provide physical feedback |
|
POS terminals |
Point of Sale (POS) devices such as cash registers and EFTPOS devices |
|
Power |
Devices with power control or monitoring (battery backup and recharging, for example) |
|
Printer class |
Printers |
|
Imaging class |
Scanners and cameras |
USB Packets
There are four types of transfers that can take place over USB. A control transfer is used to configure the bus and devices on the bus, and to return status information. A bulk transfer moves data asynchronously over USB. An isochronous transfer is used for moving time-critical data, such as audio data destined for an output device. Unlike a bulk transfer, which can be bidirectional, an isochronous transfer is uni-directional and does not include a cyclic-redundancy-check (CRC) field. An interrupt transfer is used to retrieve data at regular intervals, ranging from 1 to 255 milliseconds.
Data is transferred between USB devices using packets, and a transfer can comprise one or more packets. A packet consists of a SYNC (synchronization) byte, a PID (Packet ID), content (data, address, etc.), and a CRC.
The SYNC byte phase locks the receiver’s clock. This is equivalent to the start bit of an RS-232C frame. The PID indicates the function of the packet, such as whether it is a data packet or a setup packet. The upper four bits of the packet ID are the inverse of the lower four bits, for additional error checking. For example, the packet ID for a data packet is 0x3C. In binary, this is %0011 1100.
USB packets can be one of four types: token, data, handshaking, or preamble.
Tokens are 24-bit packets that determine the type of transfer that is to take place over the bus. There are four types of token packet (Figure 11-3). A token packet consists of a SYNC byte, a packet ID (indicating packet type), the address of the device being accessed by the host, the end-point address, and a 5-bit CRC field. The end-point address is the internal destination of the data within the device.
There are two types of data packet, known as DATA0 and DATA1 (Figure 11-4). The transmission of data packets alternates between the two types. A single data packet can transfer between 0 and 1,023 bytes, and the data packet’s CRC is 16 bits due to the larger packet size.
There are three types of handshaking packets (Figure 11-5). A successful data reception is acknowledged with an Ack packet. The receiver notifies the host of a failed transmission by sending a Nak (No Acknowledge) packet. A Stall is used to pause a transfer.
A descriptor is a data packet used to inform the host of the capabilities of the device. It contains an identifier for the device’s manufacturer, a product identifier, class type, and the device’s internal configuration, such as its power needs and end points. Each manufacturer has a unique ID, and each product in turn will also have a unique ID. Software on the host computer uses information obtained from a descriptor to determine what services a device can perform and how the host can interact with that device.
Full details of the USB protocols may be found in the USB technical documentation available from the USB web site (http://www.usb.org).
Physical Interface
USB uses a shielded, four-wire cable to interconnect devices on the network (Table 11-2). Data transmission is accomplished over a differential twisted pair (much like RS-422/485) labeled D+ and D-. The other two wires are V BUS, which carries power to USB devices, and GND. Devices that use USB power are known as bus-powered devices , while those with their own external power supply are known as self-powered devices . To avoid confusion, the wires within a USB cable are color-coded.
|
Connector pin |
Signal |
Purpose |
Wire color |
|
1 |
VBUS |
USB device power (+5V) |
Red |
|
3 |
D+ |
Differential data line |
Green |
|
2 |
D- |
Differential data line |
White |
|
4 |
GND |
Power and signal ground |
Black |
Some USB chips refer to D+ and D- as DP and DM, respectively.
The connection from a device back to a host is known as an upstream connection. Similarly, connections from the host out to devices are known as downstream connections. Different connectors are used for upstream and downstream ports, with the specific intention of preventing loopback. The only way to connect a USB network is a tiered star. USB uses two types of plugs (jacks) and two types of receptacles (sockets) for cables and equipment. The first type is Series A, shown in Figure 11-6. Series A connectors are for upstream connections. In other words, a series A receptacle is found on a host or hub, and a series A plug is at the end of the cable that attaches to the host or hub.
Series B connectors are shown in Figure 11-7. A series B receptacle is found on a USB device, and a series B plug is at the end of the cable coming downstream from a host or hub.
Figure 11-8 shows how this works in practice. This ensures that USB devices, hosts/hubs, and USB cables are always connected in the right way. It should not be possible to have a cable plugged in the wrong way or to directly connect two USB peripherals.
Since a hub will be connected to USB devices downstream and to a USB host or hub upstream, it will have both types of receptacle (Figure 11-9).
Chips that implement a USB interface require very few external components for the USB port. The schematic for an upstream port is shown in Figure 11-10.
In this example, the embedded system is powered from the USB port. If the embedded computer has its own power source, then no connection is made between VCC and pin 1 (V BUS) of the USB connector. The pull-up resistor connected to DP is required only on upstream ports. If you are implementing downstream ports on a hub, the pull-up is not required. However, downstream ports require pull-down resistors on both DP and DM (Figure 11-11).
In both figures, DP and DM have series resistors (RT) that terminate the USB connection. The total resistance of the termination should be 45 Ω. However, the pins of the USB controller will have an inherent impedance that will need to be taken into account. If the pin impedance is 21 Ω (say), then the series resistors should be 24 Ω. The catch here is that not all chip manufacturers are thorough enough to specify the pin impedance in their technical data. In such cases, you can either hound the manufacturer for the data, or take a punt. Ballpark values for the series resistors should be between 20 Ω and 30 Ω.
Many microcontrollers, such as the Microchip PIC16C745 and PIC16C765, include USB modules as part of their suite of I/O. Implementing USB with such processors is easy. You simply need to add the physical interface to the DP and DM pins of the processor. However, if the chip you have chosen to use as the primary embedded processor does not include USB, you have to provide USB functionality with an external device.
Implementing a USB Interface
One possible solution to implementing USB in your embedded system is to use a USB-to-SPI bridge, such as the Atmel AT76C711. This chip is an AVR processor with a USB subsystem, designed to act as a slave USB controller to a host processor. It has 2K of data RAM, 2K of dual-port RAM for packet processing, 16K of program RAM (organized as 8K × 16 words), an inbuilt DMA controller, an upstream USB port (with one control and five data end points), a separate IrDA-compatible UART, and SPI. The processor may be run at up to 24 MHz and operates off a 3.3 V supply. At reset, the AT76C711 automatically loads its software from an external AT45DBxxx data flash (Chapter 7) to the program RAM. Since the AT76C711’s program space is small, one of the smaller AT45DBxxx data flashes will be sufficient. Alternatively, a host processor may load the AT76C711’s code directly into its program RAM while it is held in reset.
The AT76C711 may act as a standalone processor, performing USB bridging functions to RS-232C, RS-422/RS-485, IrDA, or other protocols. Alternatively, it may be incorporated as a slave processor in a larger embedded system. The host processor may communicate with the AT76C711 either via SPI or by a standard serial interface through one of the AT76C711’s UARTs. The AT76C711 also has general-purpose I/O lines and a UART module that supports RZ encoding for IrDA.
If the processor you are using has a bus interface, then you can add USB using a chip such as the USS-820D by Agere Systems (http://www.agere.com). It supports transfers of up to 12 Mbps and is specifically designed for use in USB devices, unlike a lot of USB chips that are intended for use in hubs. It can support up to eight endpoints, each with receive and transmit buffers of up 1,120 bytes.
The schematic of an upstream USB interface, using the USS-820D, is shown in Figure 11-12. This chip is available in two footprints; the MQFP is shown in this circuit. For both footprints, the signals are the same. The only difference is the pin numbering.
The USS-820D has several power-supply inputs (V DDA, V DDT, V DD0, V DD1), all of which operate from a 3.3 V supply (VDD in the schematic). Each power pin is decoupled to ground using a 100 nF capacitor. The 5 V power (V BUS) available from the USB connector cannot be used to drive the USS-820D directly. However, a MAX604 voltage regulator circuit (Chapter 5) will convert V BUS to the required 3.3 V supply. The USS-820D also has numerous ground pins (V SST, V SSX, V SS0, V SS1, V SS2), all of which are connected to ground. Even though this chip uses a 3.3 V supply, its digital (non-USB) inputs are compatible with 5 V logic, and so it may be interfaced directly to a processor operating on a 5 V supply.
XTAL1 and XTAL2 are the connections for a 12 MHz crystal, providing timing for the USB controller.
The connections to a microprocessor are straightforward. This design, for example, could be included in the AT90S8515-based computer design in Chapter 15 as it is. The USS-820D’s data pins, D0 through D7, connect directly to the processor’s data bus. Similarly, the low-order address pins, A0 through A4, connect to the corresponding signals from the processor. These address bits are used to select internal registers within the USS-820D. The processor’s read (
) and write (
) signals connect directly to USS-820D’s read (
) and write (
) pins. (Agere places an “N” after pin names that are active low.) The USS-820D is selected when 
is asserted low. Therefore, this pin is driven from an address decoder output (which I’ve labelled USB-SELECT in the schematic).
The USS-820D is reset when its RESET pin is sent high (not low like most other devices). So, for normal operation this pin should be held low. To allow the USS-820D to be reset under software control, this pin could be driven by a processor digital output line.
The USS-820D has a number of outputs that may be used to notify a host processor of the current USB status. DSA (Data Set Available), USBR (USB Reset detected), 
(Suspend), and SOFN (Start Of Frame) may either be read as digital inputs by the host microcontroller, or, for processors that have several interrupt inputs, these signals may be used to generate an interrupt. If the host processor has only a limited interrupt capability, all of these events will trigger the USS-820D interrupt pin (IRQN). This pin can therefore serve as the sole interrupt input to the processor. A word of caution, however: this pin can be configured under software control to be either active high or active low. Getting this wrong can put your embedded system in a permanent state of interrupt. The default state for this pin is active low, which suits most processors. For processors that have active-high interrupts, such as Intel processors, the firmware should configure USS-820D for the correct interrupt polarity before enabling the processor’s interrupt-handling capability.
The 
pin is an input that signals a Remote Wake-Up condition. In other words, this embedded system has been asleep (in suspend mode) and has awoken. This pin notifies the USS-820D of the change in state so that it can alert other USB systems. is simply driven by a processor digital output line.
The USB differential data signals are pins DPLS (Data Plus, D+) and DMNS (Data Minus, D-). These are connected to the USB connector through series-termination resistors. Agere Systems suggests a nominal value of 24 Ω. For an upstream connection, DPLS (D+) requires a pull-up resistor of 1.5 kΩ. Normally, this resistor is connected to +5 V. However, the USS-820D provides a special pin (DPPU ) specifically for this purpose. Thus, under software control, the USS-820D can simulate a USB-device disconnect. It will appear to an upstream hub that the system containing the USS-820D has been physically disconnected, even though it is still attached. This can be useful during development and testing. It also allows the USB device to decide whether or not a host knows it is connected. DPPU may be decoupled to ground using a 10 nF capacitor.
Chips such as the USS-820D make adding USB functionality to your embedded hardware simple and easy. Through USB, you can develop peripherals based on embedded processors for desktop computer systems. Alternatively, you can use USB to connect existing peripherals to your embedded computer to further increase its functionality.