Comtrol eCos - Manual (Page 681)

Introduction
required information such as the vendor id cannot be supplied by generic packages; only by the application de-
veloper. Class support code such as the USB-ethernet package could in theory supply some of the information
automatically, but there are also hardware dependencies such as which endpoints get used for incoming and outgo-
ing ethernet frames. Instead it is the responsibility of the application developer to provide all the enumeration data
and perform some additional initialisation. In addition, the common USB slave package can handle all the stan-
dard control messages for a simple USB peripheral, but for something like a multifunction peripheral additional
application support is needed.
Note: The initial implementation of the eCos USB slave packages involved hardware that only supported
control and bulk transfers, not isochronous or interrupt. There may be future changes to the USB code and
API to allow for isochronous and interrupt transfers, especially the former. Other changes may be required to
support different USB devices. At present there is no support for USB remote wakeups, since again it is not
supported by the hardware.
eCos USB I/O Facilities
For protocols other than control messages, eCos provides two ways of performing USB I/O. The first involves
device table or devtab entries such as
/dev/usb1r , with one entry per endpoint per USB device. It is possible to
open these devices and use conventional blocking I/O functions such as read and write to exchange data between
host and peripheral.
There is also a lower-level USB-specific API, consisting of functions such as usbs_start_rx_buffer . A USB
device driver will supply a data structure for each endpoint, for example a usbs_rx_endpoint structure for every
receive endpoint. The first argument to usbs_start_rx_buffer should be a pointer to such a data structure. The
USB-specific API is non-blocking: the initial call merely starts the transfer; some time later, once the transfer has
completed or has been aborted, the device driver will invoke a completion function.
Control messages are different. With four different categories of control messages including application and vendor
specific ones, the conventional
open / read / write model of I/O cannot easily be applied. Instead, a USB device
driver will supply a usbs_control_endpoint data structure which can be manipulated appropriately. In practice the
standard control messages will usually be handled by the common USB slave package, and other control messages
will be handled by class-specific code such as the USB-ethernet package. Typically, application code remains
responsible for supplying the
enumeration data and for actually starting up the USB device.
Enabling the USB code
If the target hardware contains a USB slave device then the appropriate USB device driver and the common pack-
ages will typically be loaded into the configuration automatically when that target is selected (assuming a suitable
device driver exists). However, the driver will not necessarily be active. For example a processor might have an
on-chip USB device, but not all applications using that processor will want to use USB functionality. Hence by
default the USB device is disabled, ensuring that applications do not suffer any memory or other penalties for
functionality that is not required.
If the application developer explicitly adds a class support package such as the USB-ethernet one then this im-
plies that the USB device is actually needed, and the device will be enabled automatically. However, if no suitable
class package is available and the USB device will instead be accessed by application code, it is necessary to
enable the USB device manually. Usually the easiest way to do this is to enable the configuration option
CYG-
577