Jan Axelson, USB Complete

Подождите немного. Документ загружается.

Chapter 3

/QTGCDQWV6KOGETKVKECN6TCPUHGTU

Just because an endpoint is capable of a rate of data transfer doesn’t mean that a

particular device and host will be able to achieve the rate. Several things can

limit an application’s ability to send or receive data at the rate that a device

requests. The limiting factors include bus bandwidth, the capabilities of the

device, the capabilities of the device driver and application software, and laten-

cies in the host’s hardware and software.

$WU$CPFYKFVJ

When a device requests more interrupt or isochronous bandwidth than is avail-

able, the host refuses to configure the device. A high-speed interrupt endpoint

can request up to three 1024-byte data packets in each microframe, using as

much as 40% of the bus bandwidth. To help ensure that devices can enumerate

without problems, the interrupt endpoints in default interfaces must specify a

maximum packet size of 64 bytes or less. The device driver is then free to try to

increase the endpoint’s reserved bandwidth by requesting alternate interface set-

tings or configurations. Many drivers don’t support requesting alternate inter-

face settings or configurations, however.

Isochronous endpoints might also request more bandwidth than is available. In

particular, full-speed endpoints on a 1.x bus and SuperSpeed endpoints can

request over half of the bus bandwidth. To help ensure that devices will enu-

merate without problems, default interfaces in USB 2.0 and USB 3.0 devices

must request no isochronous bandwidth. In other words, a default interface can

transfer no isochronous data at all and typically includes no isochronous end-

points. After enumeration, the device driver can request isochronous band-

width by requesting an alternate interface setting or a configuration with one or

more isochronous endpoints. Note that even full-speed endpoints must meet

this requirement to comply with USB 2.0.

A specific host might configure a device with non-compliant default interfaces,

but future editions of the operating system might enforce this part of the speci-

fication and refuse to configure the device.

&GXKEG%CRCDKNKVKGU

If the host has promised that the requested USB bandwidth will be available,

there’s still no guarantee that a device will be ready to send or receive data when

needed.

A Transfer Type for Every Purpose

To transfer data efficiently, a device should be ready to send and receive data on

request. To send data, the device must write the data into the endpoint’s buffer

so the data is ready to send when requested by the host. Otherwise, in all but

isochronous transfers, the endpoint returns NAK or NRDY and the host wastes

time retrying. When receiving data, the device must read previously received

data from the endpoint’s buffer before new data arrives from the host. Other-

wise the old data will be overwritten, or the endpoint will return NAK or

NRDY and require the host to retry.

One way to help ensure that a device is always ready for a transfer is to use a

device controller that supports multiple buffers as described in Chapter 6. Dou-

ble or quadruple buffering gives the firmware extra time to load the next data to

transfer or to retrieve received data.

*QUV%CRCDKNKVKGU

The capabilities of the device driver and application software on the host can

also affect whether transfers occur as efficiently as possible and without losing

data.

A device driver requests a transfer by submitting an I/O request packet (IRP) to

a lower-level driver. For interrupt and isochronous transfers, the host controller

attempts a scheduled transaction only if the host has an outstanding IRP for the

endpoint. To ensure that no transfer opportunities are missed, drivers with large

amounts of data to send or request typically submit a new IRP immediately on

completing the previous one.

The application software that uses the data also has to be able to keep up with

the transfers. For example, the Windows driver for HID-class devices places

report data received in interrupt transfers in a buffer, and applications use Read-

File to retrieve reports from the buffer. If the buffer is full when a new report

arrives, the driver discards the oldest report and replaces it with the newest one.

If the application can’t keep up with reading the buffer, some reports are lost. A

solution is to increase the size of the buffer the driver uses to store received data

or increase the size of the ReadFile buffer to enable reading multiple reports at

once.

One way to help ensure that an application sends or receives data with minimal

delay is to place the code that communicates with the device driver in its own

program thread. The thread should have few responsibilities other than manag-

ing these communications.

Chapter 3

Doing fewer, larger transfers rather than multiple, small transfers can also help.

A host application can typically send or request a few large chunks of data more

efficiently than sending or requesting many smaller chunks. Lower-level drivers

manage the scheduling for transfers with multiple transactions.

*QUV.CVGPEKGU

Another factor in the performance of time-critical USB transfers under Win-

dows is latencies due to how the operating system handles multi-tasking. Win-

dows was never designed as a real-time operating system that can guarantee a

rate of data transfer with a peripheral.

With multi-tasking, multiple program threads run at the same time, and the

operating system grants a portion of the available time to each thread. Different

threads can have different priorities, but under Windows, no thread has guaran-

teed CPU time at a defined rate such as once per millisecond. Latencies under

Windows are often well under 1 ms, but in some cases a thread can keep other

code from executing for over 100 ms. Newer Windows editions tend to have

improved performance over older editions.

A USB device and its software have no control over what other tasks the host

CPU is performing and how fast the CPU performs them. If possible, the

device should handle any critical, real-time processing so the timing of the host

communications can be as non-critical as possible. For example, consider a

full-speed device that reads a sensor once per millisecond. The device could

attempt to send each reading to the host in a separate interrupt transfer, but if a

transfer fails to occur for any reason, the data will never catch up. If the device

instead collects a series of readings and transfers them using less frequent, larger

transfers, the timing of the bus transfers is less critical. Data compression can

also help by reducing the number of bytes that transfer.



'PWOGTCVKQP

*QYVJG*QUV.GCTPU

CDQWV&GXKEGU

Before applications can communicate with a device, the host needs to learn

about the device and assign a driver. Enumeration is the exchange of informa-

tion that accomplishes these tasks. The process includes assigning an address to

the device, reading descriptors from the device, assigning and loading a driver,

and selecting a configuration that specifies the device’s power requirements and

interfaces. The device is then ready to transfer data.

This chapter describes the enumeration process, including the structure of the

descriptors that the host reads from the device during enumeration. Under-

standing enumeration is essential in creating the descriptors that will reside in

the device and in writing firmware that responds to enumeration requests.

Chapter 4

6JG2TQEGUU

One of a hub’s duties is to detect attachment and removal of devices on its

downstream ports. Each hub has an interrupt IN endpoint for reporting these

events to the host. On system boot-up, hubs inform the host if any devices are

attached, including additional downstream hubs and any devices attached to

those hubs. After boot-up, a host continues to poll periodically (USB 2.0) or

receives ERDY Transaction Packets (SuperSpeed) that request communications

to learn of any newly attached or removed devices.

On learning of a new device, the host sends requests to the device’s hub to cause

the hub to establish a communications path between the host and device. The

host then attempts to enumerate the device by issuing control transfers contain-

ing standard USB requests to the device. All USB devices must support control

transfers, the standard requests, and endpoint zero. For a successful enumera-

tion, the device must respond to requests by returning requested information

and taking other requested actions.

From the user’s perspective, enumeration is invisible and automatic except for

possibly a message that announces the new device and whether the attempt to

configure it succeeded. Sometimes on first use, the user needs to assist in select-

ing a driver or telling the host where to look for driver files. Under Windows,

when enumeration is complete, the new device appears in the Device Manager.

(Right-click Computer, click Manage, and in the Computer Management

pane, select Device Manager.) When a user removes a device from the bus, the

device disappears from the Device Manager. In a typical device, firmware

decodes and responds to requests for information. Some controllers can manage

enumeration entirely in hardware except possibly for vendor-provided values in

EEPROM. On the host side, the operating system handles enumeration.

'PWOGTCVKQP5VGRU

The USB 2.0 specification defines six device states. During enumeration, a

device moves through the Powered, Default, Address, and Configured states.

(The other states are Attached and Suspend.) In each state, the device has

defined capabilities and behavior.

6[RKECN75$5GSWGPEG

The steps below are a typical sequence of events that occurs during enumera-

tion of a USB 2.0 device under Windows. Device firmware shouldn’t assume

that enumeration requests and events will occur in a particular order. To func-

Enumeration: How the Host Learns about Devices

tion successfully, a device must detect and respond to any control request or

other bus event at any time. Figure 4-1 shows received requests and other events

at a device during a device enumeration.

1. The system has a new device. A user attaches a device to a USB port, or the

system powers up with a device attached. The port may be on the root hub at

the host or on a hub that connects downstream from the host. The hub pro-

vides power to the port, and the device is in the Powered state. The device can

draw up to 100 mA from the bus.

2. The hub detects the device. The hub monitors the voltages on the signal

lines (D+ and D-) at each of its ports. The hub has a pull-down resistor of

Figure 4-1. To enumerate a newly attached device, the host sends a series of

requests to obtain descriptors and set the device’s bus address and

configuration. (Screen capture from Ellisys USB Explorer analyzer.)

Chapter 4

14.25k–24.8kΩ on each line. A device has a pull-up resistor of 900–1575Ω on

D+ for a full-speed device or D- for a low-speed device. High-speed-capable

devices attach at full speed. On attaching to a port, the device’s pull-up brings

its line high, enabling the hub to detect that a device is attached. On detecting a

device, the hub continues to provide power but doesn’t yet transmit USB traffic

to the device. Chapter 15 has more on how hubs detect devices.

3. The host learns of the new device. Each hub uses its interrupt endpoint to

report events at the hub. The report indicates only whether the hub or a port

(and if so, which port) has experienced an event. On learning of an event, the

host sends the hub a Get Port Status request to find out more. Get Port Status

and the other hub-class requests described are standard requests that all hubs

support. The information returned tells the host when a device is newly

attached.

4. The hub detects whether a device is low or full speed. Just before resetting

the device, the hub determines whether the device is low or full speed by exam-

ining the voltages on the two signal lines. The hub detects the device’s speed by

determining which line has a higher voltage when idle. The hub sends the

information to the host in response to the next Get Port Status request. A USB

1.x hub may instead detect the device’s speed just after a bus reset. USB 2.0

requires speed detection before the reset so the hub knows whether to check for

a high-speed-capable device during reset as described below.

5. The hub resets the device. When a host learns of a new device, the host

sends the hub a Set Port Feature request that asks the hub to reset the port. The

hub places the device’s USB data lines in the Reset condition for at least 10 ms.

Reset is a special condition where both D+ and D- are logic low. (Normally, the

lines have opposite logic states.) The hub sends the reset only to the new device.

Other hubs and devices on the bus don’t see the reset.

6. The host learns if a full-speed device supports high speed. Detecting

whether a device supports high speed uses two special signal states. In the Chirp

J state, only the D+ line is driven and in the Chirp K state, only the D- line is

driven.

During the reset, a device that supports high speed sends a Chirp K. A

high-speed-capable hub detects the Chirp K and responds with a series of alter-

nating Chirp K and Chirp J. On detecting the pattern KJKJKJ, the device

removes its full-speed pull-up and performs all further communications at high

speed. If the hub doesn’t respond to the device’s Chirp K, the device knows it

Enumeration: How the Host Learns about Devices

must continue to communicate at full speed. All high-speed devices must be

capable of responding to control requests at full speed.

7. The hub establishes a signal path between the device and the bus. The

host verifies that the device has exited the reset state by sending a Get Port Sta-

tus request. A bit in the returned data indicates whether the device is still in the

reset state. If necessary, the host repeats the request until the device has exited

the reset state.

When the hub removes the reset, the device is in the Default state. The device’s

USB registers are in their reset states, and the device is ready to respond to con-

trol transfers at endpoint zero. The device communicates with the host using

the default address of 00h.

8. The host sends a Get Descriptor request to learn the maximum packet

size of the default pipe. The host sends the request to device address 00h, end-

point zero. Because the host enumerates only one device at a time, only one

device will respond to communications addressed to device address 00h even if

several devices attach at once.

The eighth byte of the device descriptor contains the maximum packet size sup-

ported by endpoint zero. A Windows host requests 64 bytes but after receiving

just one packet (whether or not it has 64 bytes), the host begins the Status stage

of the transfer. On completing the Status stage, Windows requests the hub to

reset the device as in step 5 above. The USB 2.0 specification doesn’t require a

reset here. The reset is a precaution that ensures that the device will be in a

known state when the reset ends.

9. The host assigns an address. When the reset is complete, the host controller

assigns a unique address to the device by sending a Set Address request. The

device completes the Status stage of the request using the default address and

then implements the new address. The device is now in the Address state. All

communications from this point on use the new address. The address is valid

until the device is detached, a hub resets the port, or the system reboots. On the

next enumeration, the host may assign a different address to the device.

10. The host learns about the device’s abilities. The host sends a Get

Descriptor request to the new address to read the device descriptor. This time

the host retrieves the entire descriptor. The descriptor contains the maximum

packet size for endpoint zero, the number of configurations the device supports,

and other basic information about the device.

The host continues to learn about the device by requesting the one or more

configuration descriptors specified in the device descriptor. A request for a con-

Chapter 4

figuration descriptor is actually a request for the configuration descriptor fol-

lowed by all of its subordinate descriptors up to the number of bytes requested.

A Windows host begins by requesting just the configuration descriptor’s nine

bytes. Included in these bytes is the total length of the configuration descriptor

and its subordinate descriptors.

Windows then requests the configuration descriptor again, this time requesting

the number of bytes in the retrieved total length. The device responds by send-

ing the configuration descriptor followed by all of the configuration’s subordi-

nate descriptors, including interface descriptor(s), with each interface descriptor

followed by any endpoint descriptors for the interface. Some configurations

also have class- or vendor-specific descriptors. This chapter has more on what

the descriptors contain.

11. The host assigns and loads a device driver (except for composite devices).

After learning about a device from its descriptors, the host looks for the best

match in a driver to manage communications with the device. Windows hosts

use INF files to identify the best match. The INF file may be a system file for a

USB class or a vendor-provided file that contains the device’s Vendor ID and

Product ID. Chapter 9 has more about selecting a driver.

For devices that have been enumerated previously, Windows may use stored

information instead of searching the INF files. After the operating system

assigns and loads the driver, the driver may request the device to resend descrip-

tors or send other class-specific descriptors.

An exception to this sequence is composite devices, which can have different

drivers assigned to multiple interfaces in a configuration. The host can assign

these drivers only after enabling the interfaces, so the host must first configure

the device as described below.

12. The host’s device driver selects a configuration. After learning about a

device from the descriptors, the device driver requests a configuration by send-

ing a Set Configuration request with the desired configuration number. Many

devices support only one configuration. If a device supports multiple configura-

tions, the driver can decide which configuration to request based on informa-

tion the driver has about how the device will be used, or the driver can ask the

user what to do or just select the first configuration. (Many drivers only select

the first configuration.) On receiving the request, the device implements the

requested configuration. The device is now in the Configured state and the

device’s interface(s) are enabled.

Enumeration: How the Host Learns about Devices

For composite devices, the host can now assign drivers. As with other devices,

the host uses the information retrieved from the device to find a driver for each

active interface in the configuration. The device is then ready for use.

Hubs are also USB devices, and the host enumerates a newly attached hub in

the same way as other devices. If the hub has devices attached, the host enumer-

ates these after the hub informs the host of their presence.

Attached state. If the hub isn’t providing power to a device’s V

BUS line, the

device is in the Attached state. The absence of power may occur if the hub has

detected an over-current condition or if the host requests the hub to remove

power from the port. With no power on V

BUS, the host and device can’t com-

municate, so from their perspective, the situation is the same as when the device

isn’t attached.

Suspend State. A device enters the Suspend state after detecting no bus activity,

including SOF markers, for at least 3 ms. In the Suspend state, the device

should limit its use of bus power. Both configured and unconfigured devices

must support this state. Chapter 16 has more about the Suspend state.

5WRGT5RGGF&KHHGTGPEGU

Enumerating SuperSpeed devices has some differences compared to USB 2.0:

• On detecting a downstream SuperSpeed termination at a port, a hub ini-

tializes and trains the port’s link. Enumeration then proceeds at SuperSpeed

with no need for further speed detecting.

• The host isn’t required to reset the port after learning of a new device.

• The bus-current limits are 150 mA before configuration and 900 mA after

configuration.

• The host sends a Set Isochronous Delay request to inform the device of the

bus delay for isochronous packets.

• The host sends a Set SEL request to inform the device of the system exit

latency (the amount of time required to transition out of a low-power

state).

• Protocols for entering and exiting the Suspend state differ.

• For hubs, the host sends a Set Hub Depth request to set the hub-depth

value.