Read an Excerpt

USB Embedded Hosts

The Developer's Guide

Lakeview Research LLC

USB Essentials

This chapter is a quick tour of the minimum you need to know about USB hardware and protocols when developing USB embedded host systems.

How Data Travels on the Bus

USB is a universal serial bus developed to handle communications between personal computers (PCs) and peripherals that have varying needs. Every USB communication is between a USB host and a USB device. The host can be a PC or an embedded system with USB host capability. The USB host manages traffic on the bus. Devices respond to communications from the host.

The USB Implementers Forum (USB-IF at usb.org) is the trade group that publishes the Universal Serial Bus Specification and other documents that are the ultimate reference to the interface. The USB-IF also sponsors conferences and provides tools, compliance tests, and other resources for developers.

A companion to the USB specifications is my book USB Complete, a developer's guide to the interface and designing and programming USB peripherals.

Bus Speeds

At this writing, most USB devices use the USB 2.0 interface, which has a 2-wire data bus and supports three signaling rates: high speed at 480 Mbps, full speed at 12 Mbps, and low speed at 1.5 Mbps. Data travels on the data wires (D+ and D-) in one direction at a time. USB 3.0 added SuperSpeed, which uses a 4-wire bus and has a signaling rate of 5 Gbps. With SuperSpeed, each direction has its own pair of wires, and data can travel in both directions at the same time.

In addition to the signaling rate, factors that affect throughput on the bus are the type of transfer, the capabilities and performance of the host and device hardware, the efficiency of the program code in the host and device, and how busy the bus is.

All USB cables have power (VBUS) and ground wires that provide a nominal +5V supply to the downstream device.

Devices

Every USB device has one or more endpoints, which are buffers that store received data or data ready to transmit. Each endpoint address has an assigned number, direction, transfer type, and maximum number of data bytes the endpoint can send or receive in a transaction.

A hub is a special type of device with one port that connects to the host or another upstream hub and one or more downstream ports that can connect to devices, which may include other hubs. Hubs, including the root hub in the host, provide power to their downstream devices. Some devices provide their own power to supplement the bus power.

Transfers

A USB transfer consists of one or more transactions that can carry data to or from an endpoint. Table 1–1 shows the phases that make up a USB 2.0 transaction.

In the token phase, the host initiates a transaction by sending a token packet that specifies the device, endpoint number, and direction of the data phase. An IN token packet requests a data packet from the endpoint. A SETUP or OUT token packet precedes a data packet from the host.

In the data phase, the host or device sends data depending on the direction specified in the token phase. In addition to data, each data packet contains error-checking bits and a packet ID (PID) with a data-sequencing value that helps the receiver of the data detect missing packets.

In the handshake phase, the receiver of data in the data phase reports the success or failure of the transaction. Some transactions have fixed scheduling that doesn't allow retrying after an error, and these transactions don't have a handshake phase.

On a SuperSpeed bus, transactions perform similar functions, but the protocol differs due to the 4-wire bus and the need to support SuperSpeed's added capabilities for power saving and other features.

Transfer Types

USB supports four transfer types: control, bulk, interrupt, and isochronous. As Table 1–2 shows, each type has capabilities suited for a particular set of needs.

Control transfers send requests and receive responses where the timing isn't critical. The host reserves a portion of the bus bandwidth for control transfers, but an individual transfer has to share the bus with other devices and has no guaranteed timing. On device attachment or bootup with a device attached, the host uses control transfers to request data structures called descriptors from the device. The descriptors provide information about the device's capabilities and help the host decide what driver to assign to the device. The process of retrieving descriptors and assigning a driver is called enumeration. A device-class specification can also define class-specific control requests.

Each control transfer has two or three stages: Setup, Data (optional), and Status. In the Setup stage, the host sends a request to the device. The Data stage, if present, carries data from the host or device, depending on the request. The Status stage carries information about the success of the transfer.

In the Setup stage, the host provides information in these fields:

bmRequestType is a bit field that specifies the direction of data flow, the request type, and the recipient.

Bit 7 names the direction of data flow for data in the Data stage. Host to device (OUT) or no Data stage is zero; device to host (IN) is 1.

Bits 6..5 specify whether the request is one of USB's standard requests (00), a request defined for a specific USB class (01), or a request defined by a vendor-specific driver for use with a particular product or products (10).

Bits 4.. 0 specify whether the request is directed to the device (00000) or to an interface (00001), endpoint (00010), or other element (00011) in the device. bRequest is the request number defined by the host's driver.

wValue is defined by the request. For example, in the HID-class Get_Report request, wValue contains the report type and report ID.

wIndex is defined by the request. A typical use is to pass an index or offset such as an interface or endpoint number.

wLength is the number of bytes the host will transfer in the Data stage or the maximum number of bytes the device should return in the Data stage. If zero, the transfer has no Data stage.

The other transfer types don't have defined stages. Instead, higher-level software defines how to use the data being transferred.

Bulk transfers are the fastest on an otherwise idle bus but have no guaranteed timing. Printers, drives, and network communications use bulk transfers.

Interrupt transfers have guaranteed maximum latency, or time between transaction attempts. For example, with a maximum latency of 10 ms, the host can schedule a transaction every 10 ms or more frequently. Interrupt transactions are suited for devices that need to send or receive data without delay. Mice and keyboards use interrupt transfers to send data about key presses and mouse movements.

Isochronous transfers have guaranteed timing but no error correcting. Streaming audio and video, which needs precise timing and can tolerate occasional errors, uses isochronous transfers.

Endpoint zero supports control transfers. The other transfer types can use any other available endpoint address on the device hardware. Low-speed devices can use only control and interrupt transfers. Full-speed, high-speed, and SuperSpeed devices can use all four transfer types.

How the Host Communicates with Devices

To communicate with an attached device, a USB host must use class or vendor-defined protocols supported by the device. The data may also use industry protocols to implement higher-level functions. For example, to read and write to drives, the USB host uses bulk transfers to send SCSI commands to the device. To play audio, a USB host can use isochronous transfers to send an MP3 file to USB speakers. A host platform that has built-in support for the needed protocols can give a big head start to a project.

Device Classes

The USB-IF publishes class specifications for common device functions (Table 1–3). Each class has a code that devices can declare in a descriptor. Devices with vendor-specific drivers use the class code FFh, and the host identifies the specific device by the Vendor ID and Product ID in the device descriptor. Hosts may also use the Vendor ID and Product ID to identify specific devices in a standard class. For example, the host may want to identify a HID-class device that performs a particular vendor-defined function.

In conventional PCs, the operating system (OS) provides drivers for accessing devices in popular classes. In embedded-host platforms, the built-in support may be limited to a couple of popular device types such as flash drives and keyboards. Or a platform may provide partial support, such as the ability to send data to USB printers, but leave it to the developer to support printer languages or specific printer features.

A device that doesn't belong to a defined class can use a custom driver tailored to the device's function or a driver that can exchange generic data with the device. Some embedded-host platforms support popular devices with vendor-defined functions. An example is the FT232x USB UART chips from Future Technology Devices International (FTDI). The chips have support in FTDI's Vinculum II USB host module and in distributions of Linux for embedded systems.

Learning about Attached Devices

A host learns about a device by examining the descriptors retrieved during enumeration. Listing 1-1 shows descriptors for a device that uses a vendor-specific driver.

Every device has a device descriptor that specifies the device's Vendor ID, Product ID, device release number, maximum packet size for endpoint zero, and number of configurations. The device descriptor can also specify a class, subclass, and protocol. A function specified in the device descriptor applies to the entire device and thus limits the device to a single function. Table 1–4 shows fields that a host can examine in the device descriptor to learn a device's function.

The idVendor and idProduct fields contain the Vendor ID and Product ID that identify the specific device. The bcdDevice field can further identify the device by release number.

A configuration descriptor specifies the amount of bus current the device needs with bMaxPower equal to half the requested bus current in mA. In Listing 1-1, bMax-Power = 32h, so the requested current is 32h x 2, which equals 64h or 100 mA.

Each configuration descriptor has one or more subordinate interface descriptors. If bDeviceClass in the device descriptor equals 00h or EFh, the device defines its function or functions in one or more interface descriptors. Devices declare most functions in interface descriptors. Table 1–5 shows fields in the interface descriptor that can identify an interface's class.

A device that specifies its function(s) in interface descriptors can have multiple functions. For example, a device can function as both a printer and a mass-storage device with each function having an interface descriptor. In Listing 1-1's example descriptor, bInterfaceClass assigns a vendor-specific function to the interface.

A class or vendor function can use subclass and protocol codes to further define a device's function and protocols. An example is devices in the application-specific class (FEh), which use the subclass field to specify the function.

Some classes, such as audio, use multiple interfaces to implement a single function. For these devices, an interface association descriptor (IAD) can indicate which interfaces belong to a function.

An interface may have zero or more subordinate endpoint descriptors. An endpoint descriptor specifies the endpoint's number and direction, transfer type, maximum packet size, and polling interval, if any. The wMaxPacketSize field specifies the maximum number of data bytes the endpoint can transfer in a transaction. To transfer more than the maximum packet size in a single transfer, the host uses multiple transactions.

Listing 1-1's descriptors have an interrupt and bulk endpoint for each direction. Endpoint zero, required for all devices, never has an endpoint descriptor, always supports control transfers, and is bidirectional. In the device descriptor, bMaxPacketSize0 specifies endpoint zero's maximum packet size.

The USB 2.0 specification and other documents from the USB-IF define additional descriptor types. A string descriptor can store text such as a manufacturer's name, product name, or serial number. A class specification can define a class-specific descriptor. For example, HID-class devices have a class-specific HID descriptor and at least one class-specific report descriptor.

You can view a device's descriptors by attaching the device to a host and viewing the traffic with a hardware protocol analyzer or a software analyzer that captures enumeration traffic. Chapter 4 shows how to use the Linux l susb command to view descriptors of attached devices.

USB Hosts for Embedded Systems

Developers have many choices for hardware and programming for USB embedded host systems. This chapter will help you choose a platform that has the USB host capabilities your project needs.

Embedded Hosts are Different

Because embedded systems typically support a limited number of peripheral types, most USB hosts in embedded systems don't need the full capabilities of a conventional USB host. At the same time, some USB hosts in embedded systems need capabilities that conventional hosts don't have, such as the option to turn off bus power when the bus is idle.

Dedicated Functions

A conventional PC's function and attached peripherals vary with the applications that users install and run. A PC in a science lab might connect to a variety of lab instruments, while a home PC might need to support the latest game controller. USB hosts in conventional PCs must support the wide variety of devices that users might attach. To do so, the host supports multiple bus speeds and external hubs. Each host port can provide 500 mA (900 mA for SuperSpeed) to an attached device. The operating system (OS) provides drivers for popular USB device classes, and users can load drivers for additional devices as needed.

In contrast, embedded systems have defined functions. The firmware programmed into the system determines the system's function and the number and types of supported USB devices. These devices in turn determine what speeds the host must support, whether the host needs to support external hubs, and how much current the host port(s) must provide. Adding support for new devices typically requires a firmware update.

Some embedded systems provide both USB host and USB device functions. These systems may have a dedicated port for each function or a single dual-role port that can serve as both a host and device port, swapping roles as needed.

The Targeted Peripheral List

To reduce user confusion and frustration, a USB embedded host system can provide a Targeted Peripheral List that names devices that are known to work with the system. For example, a vendor might list manufacturers and model numbers of tested printers. Other printer models may also work, but the list enables users to rely on known good peripherals.

The USB-IF's On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification defines requirements for USB host systems that provide a Targeted Peripheral List. The specification calls these systems Targeted Hosts.

Two types of Targeted Hosts are Embedded Host and On-The-Go (OTG) systems (Figure 2–1).

An Embedded Host system has one or more host ports and may also have a device port. An OTG system has a single port that can function as both a host and device port. Some requirements are relaxed for Targeted Host systems, and OTG systems have added responsibilities for managing the dual-role port.

On attachment of an unsupported peripheral, including a hub on a system that doesn't support hubs, a Targeted Host system shouldn't fail silently but should provide a message or other indicator to inform the user that the host doesn't support the device.

This chapter focuses on Embedded Hosts and the host capabilities of OTG systems. Chapter 11 has more about using the unique capabilities of OTG ports.

Requirements

The ports in an Embedded Host system function much like ports in conventional PCs but without the need to support the bus speeds and bus currents that the targeted peripherals don't use. Table 2–1 compares the requirements for Embedded Host ports and conventional host ports.

An Embedded Host system can support just about any combination of speeds needed for the targeted peripherals. If all of the targeted peripherals use low speed or all use full speed, the system needs to support only one speed. A system that supports high speed must also support full speed. All host ports should support the same speeds and devices. The On-The-Go and Embedded Host supplement applies to the USB 2.0 specification and thus offers no specific guidance for USB embedded hosts on SuperSpeed systems.

Switching Off Bus Power

To lengthen battery life, embedded systems that use battery power typically conserve power when possible. Unlike conventional USB hosts, Embedded Host systems have the option to turn off VBUS to save power when the bus is idle.

When VBUS is off, the host needs a way to detect device attachment, and already attached devices need a way to signal that they want to communicate on the bus. Two protocols, the Attach Detection Protocol and the Session Request Protocol, meet these needs.

---

Excerpted from USB Embedded Hosts by Jan Axelson. Copyright © 2011 Janet L. Axelson. Excerpted by permission of Lakeview Research LLC.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---