|This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
USB device drivers interact with the peripherals that they control by using the USBD interface functions. These functions, which are provided by the USBD module, constitute the core of a USB device driver's functionality. There are several categories of USBD interface functions, each related to a different aspect of interacting with a USB device, including transfer, pipe, frame, and configuration functions, as well as functions for performing other miscellaneous tasks.
Transfer functions are the most important category because they handle sending data to and receiving data from a USB device. There are four basic types of transfer: control, bulk, interrupt, and isochronous. For convenience, there are several special transfer functions that provide common types of control transfer, such as device configuration and setup requests. All transfer functions have an optional callback parameter. If a callback function is provided, the transfer functions return immediately, or asynchronously, without waiting for the transfer request to complete. When the transfer request finishes, the USBD module invokes the function pointed to by the callback parameter. Additionally, a USB device driver can use the USB_NO_WAIT flag to cause the transfer functions to return asynchronously, even if no callback is specified. USB device drivers typically do this in situations when they queue several requests to the device and wait for only the last one to finish. In such cases, the device driver is still responsible for closing all transfer handles. If the USB device driver provides no callback function and does not use the USB_NO_WAIT flag, the transfer function blocks until the transfer is complete. Note that if a transfer request fails, possibly even before the transfer is issued, then the transfer function will return FALSE immediately and will not invoke any callback functions.
The USBD module calls the callback function in a context that may block other USB operations. Therefore, these callback functions should perform very minimal processing, preferably just setting some state variables and signaling an event so that any substantial post-processing can be handled by another thread; such callback functions cannot call any USBD interface functions. In particular, callback functions that handle notifications from AbortTransfermust not call the CloseTransferfunction. See the HID sample driver for examples of using callback functions.
HCD implementations generally have an internal contiguous buffer of memory which is used as a temporary staging location for data during transfers. However, copying data into and out of this buffer may impose an unacceptable limit on the performance of a USB device driver. In such cases, the driver may pass an optional physical memory address that the USB system uses directly for data transfers. A driver-specific buffer used in this way must be contiguous within 4KB segments and must not be accessed by the USB device driver during transfer operations. The LockPagesAPI can be used to obtain physical address information.
The following list shows the transfer functions:
The following list shows the pipe functions that open and close communication channels between a USB device driver and a USB device:
The following list shows the frame functions that control the physical characteristics of frame timing on the bus:
The following list shows device configuration functions for specific kinds of data transfers defined in the Universal Serial Bus Specification, Revision 1:
The following list shows miscellaneous functions for tasks related to interacting with the USB system software:
Last updated on Tuesday, July 13, 2004