USB System Architecture

•Interrupt transfer — an interrupt transfer is used for devices that are typically thought of as interrupt-driven devices in legacy PC implementations. USB devices that are interrupt driven must be polled periodically to see if the device has data to transfer. For example, in legacy PC systems a hardware interrupt is generated each time a key is pressed on the keyboard to notify the processor that it must execute a software interrupt routine to service the keyboard, whereas a USB keyboard is polled periodically to determine if keyboard data (e.g., resulting from a key being pressed) is ready to be transferred. The polling rate, of course, is critical; it must be frequent enough to ensure that data is not lost but not so frequent that bus bandwidth is needlessly reduced.

•Bulk transfer — a bulk transfer is used for transferring large blocks of data that have no periodic or transfer rate requirement. An example of a bulk transfer is a print job being transferred to a USB printer. While transfer speed is important for performance, a print job delivered slowly does not result in lost or corrupted data.

•Isochronous transfer — an isochronous transfer requires a constant delivery rate. Devices that use isochronous transfers must ensure that rate matching between the sender and receiver can be accomplished. For example, a USB microphone and speaker would use isochronous transfers to ensure that no frequency distortion results from transferring data across the USB.

•Control transfers — control transfers are used to transfer specific requests to USB devices and are most commonly used during device configuration. A special transfer sequence is used to pass requests (commands) to a device, sometimes followed by a data transfer, and always ending with completion status.

A given device may have a collection of endpoints, each of which may support a different transfer type. For example, when a file manager program accesses a USB-based CD-ROM, the data endpoint is defined as a bulk transfer endpoint, whereas accesses performed by a CD audio program would require isochronous transfers be performed from a data endpoint.

Client Initiates Transfer

During the configuration process, the USB driver reads the device descriptors to determine the type of endpoints that a given device requires for its function. The USB driver determines if sufficient bus bandwidth is available to accommodate all endpoint transfer requirements. If the bandwidth is available, the USB driver establishes a communications pipe with the bus bandwidth reservation associated with the pipe. The driver also apprises the appropriate USB device driver that the communications pipe exists for its use.

118

Chapter 6: LS/FS Transfer Types & Scheduling

Communications Pipes

Figure 6-1 on page 120 illustrates the concept of the communications pipes that have been established for the client driver to communicate with its function. The communications pipes remain inactive until the client requests a transfer via one of the pipes. Note also that the USB device driver knows only about communications pipes and the endpoints that it must communicate with, and is not aware of the nature of the low-level USB transfer mechanisms.

The USB specification classifies a communications pipe as either a stream or a message pipe:

•Streaming pipes — The characteristic of a streaming pipe is that USB imposes no particular format relative to the actual data being transferred. Isochronous, Interrupt, and bulk endpoints fall into this category. Data delivered to or from these endpoints may have specific structures or formats, but these would be class or vendor-specific.

•Message pipes — A message pipe has a specific structure defined by USB. Communication with a control endpoint requires a specific structure and sequence, and the data patterns sent to the endpoint define requests or commands that are issued to a device. These requests specify that the device must take some action.

Note that in Figure 6-1 on page 120 the pipe at the top of the illustration is targeting endpoint zero (the default control endpoint) that every device must implement. This communications pipe is bidirectional to allow messages to be passed in both directions. The other transfer pipes are always unidirectional. This means that a device such as a read/write mass storage device must implement two endpoints for bi-directional data transfer: one for reads and one for writes.

119

USB System Architecture

Figure 6-1: Communications Pipes Between Client Software’s Memory Buffer and Device

Endpoints

Communication Initiated by I/O Request Packets

Refer to Figure 6-2 on page 121. A USB device driver calls the USB driver to start a transfer. The client transfer request is referred to as an I/O Request Packet, or IRP. The IRP results in a transfer being performed over the USB. The USB driver allocates the amount of bus bandwidth that is given to this transfer during each frame. The transfer request may take numerous frames to complete.

The host controller driver schedules all IRPs that are presented to it by the USB driver. The host controller then performs the individual transfers that have been scheduled, by performing multiple transactions (reads from or writes to the target USB device) during each frame until the transfer completes.

120