Previous

Next

Descriptors, Interfaces, Endpoints, and Pipes

The USB was designed to support Plug-and-Play. Each device contains Descriptors which contain information about the device. The USB specification contains a list of standard descriptors which every device must support. For example, here is the data declaration of the USB Device Descriptor:

typedef struct { 
   BYTE bLength;              // length in bytes of this descriptor 
   BYTE bDescriptor;          // descriptor ID (1) 
   WORD bcdUSB;               // USB version (BCD format) 
   BYTE bDeviceClass;         // the device's class 
   BYTE bDeviceSubClass;      // and subclass 
   BYTE bDeviceProtocol;      // and protocol 
   BYTE bMaxPacketSize0;      // default control pipe max packet len 
   WORD idVendor;             // vendor ID 
   WORD idProduct;            // product ID 
   WORD bcdDevice;            // device's version 
   BYTE iManufacturer;        // index of vendor's string descriptor 
   BYTE iProduct;             // index of product's string descriptor 
   BYTE iSerialNumber;        // index of product's serial number 
   BYTE bNumConfigurations;   // number of available configurations 
} RTUDeviceDescriptor;

When a device is attached, RTUSB-32 retrieves the device descriptor and all configuration descriptors and makes this information available for all installed USB Clients (drivers which can handle USB devices). USB defines standard descriptors for devices, configurations, interfaces, endpoints, and (optional) strings. In addition, a device can publish class or device specific descriptors.

Communication between the host and a USB device is performed through Pipes. USB client software must open such pipes, much like files have to be opened. Several pipes to a single device can be open at the same time. Instead of using file names, USB pipes are opened to Endpoints. Devices publish Endpoint descriptors to enable clients to query what endpoint are available and what characteristics they have. Endpoint descriptors contain information about the I/O direction (IN which is from the device to the host or OUT which is from the host to the device), the transfer type (Control, Bulk, Interrupt, or Isochronous) and the maximum supported packet size.

The Default Control Endpoint 0 is a special endpoint which is always available and has no associated endpoint descriptor. RTUSB-32 uses a pipe to this endpoint to retrieve descriptors and to configure a device. USB clients can also open pipes to the Default Control Endpoint to perform standard requests and/or class/device specific requests.

With the exception of the default control endpoint, USB devices publish their endpoints as part of an Interface. One interface can group zero, one, or more endpoints to a set of endpoints comprising the interface. For example, a USB disk drive may define an interface with a Bulk IN and a Bulk OUT endpoint to send/receive sectors of data. Implicitly, the default control endpoint is also used by the interface to set and retrieve device options.

One or more interfaces are grouped together in a Configuration, each described by a configuration descriptor. Within one configuration, several interfaces can be active at the same time. USB clients communicate with an interface. Thus, if a device's configuration supports several interfaces, several USB clients could work with the device simultaneously. This is important to keep in mind when a USB client is designed. A client cannot assume it owns a device; it can merely own one or more interfaces.

When a device is attached to the bus, it is initially unconfigured. If a client wants to handle the device, it must select and set a configuration before the interfaces of that configuration become usable. Under RTUSB-32, a device is implicitly placed in the configured state when an interface is claimed using RTUClaimInterface. Once a configuration has been selected, it cannot be changed without disconnecting (or at least resetting) the device.

The Universal Serial Bus

Transfer Types