Chapter 22: Overview of USB Host Software

configuration cannot be used until the pipes are initialized by the device driver using the pipes. During initialization, the device driver must set the policy for the pipe. Setting the policy means defining how the pipe is to be used by the device driver. For example, the service interval must be established, as well as the maximum data transfer used by the client, etc. Once the policy for a pipe is set, it is ready to be used.

•Function Configuration — The device driver for a given USB device may have additional configuration to complete that the USB software is completely unaware of. This configuration is typically related to a particular device class or might be part of a vendor-specific device and driver.

Once a configuration has been established, the USBD permits modification of the configuration by adjusting settings associated with a given interface, or by selecting an entirely different configuration.

Allocating USB Resources

Host software must be able to determine if a device just attached to the USB can operate based on the available USB resources. Host software tracks two USB resources:

•Power

•Bus Bandwidth

It is the responsibility of software to ensure that the device has the necessary resources prior to configuring it for operation.

Verifying Power

Some devices may require more USB bus power than is available at a given port. This can occur when a high powered device is attached to a bus powered hub port. By reading a hub’s standard descriptors, configuration software can determine the amount of power that is available at a given USB port (minimum current allowed is 100ma). Software can also determine the amount of current required by a device that is attached to a port by reading its descriptors. Note that descriptors can be read because a device cannot draw more than the 100ma of current (the guaranteed amount of current available).

If the device requires more current than the port can supply, then software must not configure the device and should report power shortage to the user.

427

USB System Architecture

Tracking and Allocating Bus Bandwidth

The USBD must determine if the USB can support a given pipe before it is set up for communicating with a device’s endpoint. Each endpoint descriptor contains the bus bandwidth needed to support the endpoint. The bandwidth specified by the endpoint descriptor includes only the data payload size and does not include overhead time. Consequently, the USBD must calculate the execution time required to transfer the data over the bus. Once total execution time has been calculated, then the frame schedule must be checked to see if the new pipe can be supported.

Several parameters must be known in order to calculate the bus bandwidth requirement for a given pipe, including:

Number of data bytes — This information is read from the MaxPacketSize field within the endpoint descriptor.

Transfer type — Isochronous and interrupt transfers require guaranteed bandwidth, while control transfers have a guaranteed 10% bus reservation. Bulk transfers have no guaranteed bandwidth during any given frame.Transfer type also determines the amount of overhead associated with the transaction. For example, isochronous transfers are not accompanied by handshake packets. The overhead includes the:

•token packet — sync bits (8) + PID (8) + Address (11) + CRC (5) +EOP (2) = 34 bits

•data packet overhead — sync bits (8) + PID (8) + CRC (16) + EOP (2) = 34 bits

•handshake (if required) — sync bits (8) + PID (8) + EOP (2) = 18 bits

Transfer type is encoded into the Attribute field within the endpoint descriptor.

Host recovery time — The time needed for the host controller to recover from the last transmission and prepare for the next. This parameter is host controller implementation specific.

Hub low-speed setup — If the transaction targets a low-speed device, then the time required for the preamble packet delivery and the hub delay associated with enabling the low-speed ports must be included.

Bit stuffing time — Bit stuffing time must also be calculated. Since bit stuffing is a function of the data stream, which is unknown to host software, a worst case theoretical maximum number of additional bit times is included for bit stuffing (1.1667 * 8 * number of bytes).

428