Книга: Writing Windows WDM Device Drivers

USB Device Framework

USB Device Framework

This section shows how the low-level USB packets and transactions are used. The USB protocol defines how the USB system is set up and run, as well as how it may be used by clients.

The host works with the hubs to find all the devices on the bus. It uses standard control requests to set up a device. It reads various descriptors from the device, works out which drivers to load, and enables the device. A hub reports any new device insertions or removals through its Status Change endpoint.

After this, the USB system drivers control access to the bus, scheduling all the transfer requests to fit into the available bandwidth.

The PC host has to deal with USB device insertion and removal, both at power up and while running. Any hubs in the system help in this task. A hub is itself a device that talks to the system USB device driver usbhub.sys to inform it of any device insertions or removals.

The host knows when a device is inserted or removed. The hub tells it which port a new device is on. The host tells the hub to enable the port and issue a reset command to the device. The device initially responds at the default address of zero. The host reads the device's device descriptor and then allocates it a free USB address in the range 1-127.

The host can then read the rest of the device's descriptors. Eventually, the host selects one of the device configurations. This fully enables the device so that all the endpoints can be used.

The USB system will only let a device configuration be selected if there is enough bandwidth available.

Window inspects the configuration, interface, and endpoint descriptors and loads the appropriate drivers. In the unlikely case of a device with more than one configuration, Windows itself prompts the user to choose between them.

Root Hub

The PC host contains a root hub that it finds on its internal buses when the host is switched on. A USB host controller is usually found by the PCI enumerator. The host controller's PCI configuration space is accessed and set with appropriate values. The controller's registers are permanently mapped into memory. A USB host controller can usually take bus mastership to do its data transfers.

The PC talks directly to the root hub electronics embedded in the host controller. The root hub then reports any devices or further hubs that are attached. Any further hubs are enumerated in the same way until all the USB devices have been found.

If Windows finds two root hubs for example, it treats them as two separate USB buses.

Hub Functionality

A hub is a standard USB device of class HubClass, which must implement functions defined in the USB Specification. It has the necessary USB descriptors to describe its functionality.

A hub primarily consists of a signal repeater and controller. The repeater passes the USB signals in the correct direction. The controller understands the protocol and instructs the repeater. The hub controller is itself controlled by the host through two endpoints.

A hub is configured and interrogated through its standard Endpoint 0. This default pipe implements most of the standard control transactions and then goes on to implement various hub class specific control transactions (ClearHubFeature, ClearPortFeature, GetBusState, GetHubDescriptor, GetHubStatus, GetPortStatus, SetHubDescriptor, SetHubFeature, and SetPortFeature).

A hub also has a Status Change interrupt endpoint, used to inform the host of changes to each of its downstream ports. A port change bit is set if any of the following states change: device connected, port enabled, suspended, over-current indicated, reset, and powered. The host asks for the Status Change interrupt data every 255ms. The hub simply returns NAK if nothing has changed (e.g., if no devices have been added or removed).

The USB system uses standard control transactions to set up all devices. Further class and vendor specific requests can be defined.

A control transaction starts with a SETUP packet that includes eight data bytes in a customizable format, as shown in Table 20.2. Table 20.3 shows the bit definitions of the first byte, bmRequestType. The next byte is the request code.

Table 20.2 Control transfers

Table 20.3 bmRequestType bit definitions

The basic USB spec only defines the Standard type control transfers listed in Table 20.4. The table indicates the possible destinations, such as Device (D), Interface (I), or Endpoint (E).

Table 20.4 Standard USB SETUP transfer requests

For example, the SET_ADDRESS request is sent to assign a USB address to a device. The device returns ACK when complete. A GET_DESCRIPTOR request asks for one of the descriptors. The descriptor is returned in one or more DATA packets.

Each device class usually has various control transfer requests defined. See the appropriate specification for details.

Table 20.5 shows the basic types of descriptor that a device should return, along with a summary of the information in each descriptor. Figure 20.1 gives a view of the relationship between the various descriptors. String descriptors are optional. Further class specific or vendor specific descriptors can be returned. Table 20.6 lists the standard descriptor type constants.

Configuration and endpoint descriptors must not include a descriptor for Endpoint 0.

An interface may have alternate settings that redefine the number or characteristics of the associated endpoints.

For isochronous requests, the endpoint maximum packet size reserves bus time.

Table 20.5 USB descriptor types and fields

Table 20.6 Standard descriptor type constants

Windows uses values in the Device or Interface descriptors to choose which driver to load. Windows initially forms Hardware IDs using the Device descriptor vendor and product fields (idVendor, idProduct, and bcdDevice). If no installation INF file can be found with a model that matches the Hardware IDs, Windows forms Compatible IDs out of the Interface descriptor class fields (bInterfaceClass, bInterfaceSubClass, and bInterfaceProtocol). Windows then searches for an installation file that handles one of these Compatible IDs. If nothing can be found, it prompts the user for a new driver. The chosen installation file specifies the driver to load.

The Interface descriptor class field, bInterfaceClass, is zero for a basic USB device. If the interface meets one of the standard device class specifications, bInterfaceClass is one of the values listed earlier in Table 20.1.

Note that the Device descriptor class fields are not used in the driver selection process. Instead, the bDeviceProtocol field can be used to indicate which, if any, new features are supported, as described in the following text.

As mentioned earlier, the basic USB device framework is enhanced to provide specifications for several different classes of USB device. A Class constant is defined for each device class. Each class may then go on to define various Subclass and Protocol constants to further define the general type of functionality provided in the device.

These class constants are not given in the standard USB device descriptor, but set in the Interface descriptor, instead. If Windows cannot find a driver that matches the Device descriptor Hardware ID, it uses the Interface descriptor class constants to form a Compatible ID.

The USB class specifications define what interfaces and endpoints must appear in a particular class of device. A class may define one or more additional class-specific descriptors for the class device, interface, or endpoint. These devices still provide the standard device, configuration, interface, and endpoint descriptors.

Device classes typically also define a series of class specific request codes for control transactions. Bits 6 and 5 of the request code are set to 01 to indicate that these are class-specific requests. For example, the Hub class request ClearHubFeature has code 0x20.

Obtain the appropriate class specification from the USB website at www.usb.org/developers/. The HID class and its USB implementation are discussed in detail in Chapter 22. The power supply device class is defined purely as a HID device.

The class-specific descriptors are usually types of Interface descriptors. Class-specific descriptor IDs have the top three bits set to 001. Table 20.7 shows the first assigned class-specific descriptor IDs.

Table 20.7 Class-specific descriptor IDs

Printer Class

As an example of a USB class, it is worth looking here at the printer class. USB printers should resemble FPP or ECP parallel port printers, as defined in the IEEE 1284 specification. The format of the print data sent to the printer is not defined by this spec.

The printer class does not define any class-specific descriptors. The standard device descriptor has zeroes for its class, subclass, and protocol. The standard interface descriptor has constant USB_DEVICE_CLASS_PRINTER (0x07) in its bInterfaceClass field. bInterfaceSubClass is always set to 0x01 indicating a Printer. The bInterfaceProtocol field has 1 if the printer is unidirectional (i.e., it only accept incoming data) or 2 if bidirectional (i.e., it can return status information). A printer can have only one such interface, but it could perhaps switch between the two operating modes using an alternate interface setting.

A printer class device always has a Bulk OUT pipe for data sent to the printer. A bidirectional printer also has a Bulk IN pipe. These pipes are used to carry the relevant page control/description information and status.

A printer uses the default control pipe Endpoint 0 for standard USB purposes. However, it is also used for three printer class-specific requests. GET_DEVICE_ID (request 0) reads an IEEE 1284 device ID. GET_PORT_STATUS (1) gets a status byte that mimics the Centronics printer port status. SOFT_RESET (2) flushes all the buffers, resets the Bulk pipes, and clears all stall conditions.

USB continues to evolve, both to define new classes of devices and to make implementation of these devices easier. The USB Common class specification document firstly defines how new class specifications should be written. Then it goes on to describe new features that may be used to extend the basic USB functionality.

Table 20.8 lists the USB extensions. The Shared Endpoint extension is described in the next section.

Support for the USB enhancements is indicated in the device descriptor. The device bDeviceSubClass field is 0x00 and bDeviceProtocol is a bitmap of supported features. Shared endpoint support is indicated in bit 0.

Currently, there seems to be no indication that Windows supports any of these new features[50].

Table 20.8 USB new feature summary

Shared Endpoints

Designers of some devices might find that they need many endpoints and pipes, which might require lots of resources. The basic USB standard says that only the default pipe Endpoint 0 can be shared between interfaces.

The Shared Endpoint USB extension allows several logical pipes to be carried on one normal "physical" pipe. Such shared pipes must have the same transfer type (control, interrupt, bulk, or isochronous) and be in the same direction. Each logical pipe defines one or more logical packets for the data it might send.

Hosts and devices that handle shared pipes multiplex the data from each logical source on the physical pipe. For isochronous pipes, the combined maximum data packet size must fit into a frame. The software must ensure that a stall on one logical pipe does halt data flow on another logical pipe.

Flow control can optionally be implemented using a pipe in the opposite direction to data transfer. A source must not send data on a logical pipe until the target has provided a grant to send: a count of the number of logical packets it can receive.

Оглавление книги