Comtrol eCos - Manual (Page 703)

Control Endpoints
Name
Control Endpoints — Control endpoint data structure
Synopsis
#include < cyg/io/usb/usbs.h >
typedef struct usbs_control_endpoint {
*hellip;
} usbs_control_endpoint;
usbs_control_endpoint
Data Structure
The device driver for a USB slave device should supply one usbs_control_endpoint data structure per USB device.
This corresponds to endpoint 0 which will be used for all control message interaction between the host and that
device. The data structure is also used for internal management purposes, for example to keep track of the current
state. In a typical USB peripheral there will only be one such data structure in the entire system, but if there are
multiple USB slave ports, allowing the peripheral to be connected to multiple hosts, then there will be a separate
data structure for each one. The name or names of the data structures are determined by the device drivers. For
example, the SA11x0 USB device driver package provides
usbs_sa11x0_ep0 .
The operations on a control endpoint do not fit cleanly into a conventional open/read/write I/O model. For example,
when the host sends a control message to the USB peripheral this may be one of four types: standard, class, vendor
and reserved. Some or all of the standard control messages will be handled automatically by the common USB slave
package or by the device driver itself. Other standard control messages and the other types of control messages may
be handled by a class-specific package or by application code. Although it would be possible to have devtab entries
such as
/dev/usbs_ep0/standard and /dev/usbs_ep0/class , and then support read and write operations on
these devtab entries, this would add significant overhead and code complexity. Instead, all of the fields in the control
endpoint data structure are public and can be manipulated directly by higher level code if and when required.
Control endpoints involve a number of callback functions, with higher-level code installing suitable function point-
ers in the control endpoint data structure. For example, if the peripheral involves vendor-specific control messages
then a suitable handler for these messages should be installed. Although the exact details depend on the device
driver, typically these callback functions will be invoked at DSR level rather than thread level. Therefore, only
certain eCos functions can be invoked; specifically, those functions that are guaranteed not to block. If a potentially
blocking function such as a semaphore wait or a mutex lock operation is invoked from inside the callback then the
resulting behaviour is undefined, and the system as a whole may fail. In addition, if one of the callback functions
involves significant processing effort then this may adversely affect the system’s real time characteristics. The eCos
kernel documentation should be consulted for more details of DSR handling.
Initialization
The usbs_control_endpoint data structure contains the following fields related to initialization.
typedef struct usbs_control_endpoint {
599