Comtrol eCos - Manual (Page 680)

Introduction
USB supports four different types of communication: control messages, interrupt transfers, isochronous transfers,
and bulk transfers. Control messages are further subdivided into four categories: standard, class, vendor and a
reserved category. All USB peripherals must respond to certain standard control messages, and usually this will be
handled by the common USB slave package (for complicated peripherals, application support will be needed). Class
and vendor control messages may be handled by an class-specific USB support package, for example the USB-
ethernet package will handle control messages such as getting the MAC address or enabling/disabling promiscuous
mode. Alternatively, some or all of these messages will have to be handled by application code.
Interrupt transfers are used for devices which need to be polled regularly. For example, a USB keyboard might be
polled once every millisecond. The host will not poll the device more frequently than this, so interrupt transfers
are best suited to peripherals that involve a relatively small amount of data. Isochronous transfers are intended for
multimedia-related peripherals where typically a large amount of video or audio data needs to be exchanged contin-
uously. Given appropriate host support a USB peripheral can reserve some of the available bandwidth. Isochronous
transfers are not reliable; if a particular packet is corrupted then it will just be discarded and software is expected to
recover from this. Bulk transfers are used for everything else: after taking care of any pending control, isochronous
and interrupt transfers the host will use whatever bandwidth remains for bulk transfers. Bulk transfers are reliable.
Transfers are organized into USB packets, with the details depending on the transfer type. Control messages always
involve an initial 8-byte packet from host to peripheral, optionally followed by some additional packets; in theory
these additional packets can be up to 64 bytes, but hardware may limit it to 8 bytes. Interrupt transfers involve a
single packet of up to 64 bytes. Isochronous transfers involve a single packet of up to 1024 bytes. Bulk transfers
involve multiple packets. There will be some number, possibly zero, of 64-byte packets. The transfer is terminated
by a single packet of less than 64 bytes. If the transfer involves an exact multiple of 64 bytes than the final packet
will be 0 bytes, consisting of just a header and checksum which typically will be generated by the hardware. There
is no pre-defined limit on the size of a bulk transfer. Instead higher-level protocols are expected to handle this, so
for a USB-ethernet peripheral the protocol could impose a limit of 1514 bytes of data plus maybe some additional
protocol overhead.
Transfers from the host to a peripheral are addressed not just to that peripheral but to a specific endpoint within
that peripheral. Similarly, the host requests incoming data from a specific endpoint rather than from the peripheral
as a whole. For example, a combined keyboard/touchpad device could provide the keyboard events on endpoint 1
and the mouse events on endpoint 2. A given USB peripheral can have up to 16 endpoints for incoming data and
another 16 for outgoing data. However, given the comparatively high speed of USB I/O this endpoint addressing is
typically implemented in hardware rather than software, and the hardware will only implement a small number of
endpoints. Endpoint 0 is generally used only for control messages.
In practice, many of these details are irrelevant to application code or to class packages. Instead, such higher-level
code usually just performs blocking
read and write , or non-blocking USB-specific calls, to transfer data between
host and target via a specific endpoint. Control messages are more complicated but are usually handled by existing
code.
When a USB peripheral is plugged into the host there is an initial enumeration and configuration process. The
peripheral provides information such as its class of device (audio, video, etc.), a vendor id, which endpoints should
be used for what kind of data, and so on. The host OS uses this information to identify a suitable host device driver.
This could be a generic driver for a class of peripherals, or it could be a vendor-specific driver. Assuming a suitable
driver is installed the host will then activate the USB peripheral and perform additional application-specific initial-
isation. For example for a USB-ethernet device this would involve obtaining an ethernet MAC address. Most USB
peripherals will be fairly simple, but it is possible to build multifunction peripherals with multiple configurations,
interfaces, and alternate interface settings.
It is not possible for any of the eCos packages to generate all the enumeration data automatically. Some of the
576