Comtrol eCos - Manual (Page 706)

Control Endpoints
extern usbs_control_return usbs_handle_standard_control(struct usbs_control_endpoint*);
When a USB peripheral is connected to the host it must always respond to control messages sent to endpoint 0.
Control messages always consist of an initial eight-byte header, containing fields such as a request type. This may
be followed by a further data transfer, either from host to peripheral or from peripheral to host. The way this is
handled is described in the
Buffer Management section below.
The USB device driver will always accept the initial eight-byte header, storing it in the control_buffer field.
Then it determines the request type: standard, class, vendor, or reserved. The way in which the last three of these
are processed is described in the section
Other Control Messages . Some standard control messages will be handled
by the device driver itself; typically the set-address request and the get-status, set-feature and clear-feature requests
when applied to endpoints.
If a standard control message cannot be handled by the device driver itself, the driver checks the
standard_control_fn field in the control endpoint data structure. If higher-level code has installed a
suitable callback function then this will be invoked with two argument, the control endpoint data structure itself
and the
standard_control_data field. The latter allows the higher level code to associate arbitrary data
with the control endpoint. The callback function can return one of three values: HANDLED to indicate that the
request has been processed; UNKNOWN if the message should be handled by the default code; or STALL to
indicate an error condition. If higher level code has not installed a callback function or if the callback function has
returned UNKNOWN then the device driver will invoke a default handler,
usbs_handle_standard_control
provided by the common USB slave package.
The default handler can cope with all of the standard control messages for a simple USB peripheral. However, if
the peripheral involves multiple configurations, multiple interfaces in a configuration, or alternate settings for an
interface, then this cannot be handled by generic code. For example, a multimedia peripheral may support various
alternate settings for a given data source with different bandwidth requirements, and the host can select a setting
that takes into account the current load. Clearly higher-level code needs to be aware when the host changes the
current setting, so that it can adjust the rate at which data is fed to or retrieved from the host. Therefore the higher-
level code needs to install its own standard control callback and process appropriate messages, rather than leaving
these to the default handler.
The default handler will take care of the get-descriptor request used to obtain the enumeration data. It has support
for string descriptors but ignores language encoding issues. If language encoding is important for the peripheral
then this will have to be handled by an application-specific standard control handler.
The header file < cyg/io/usb/usb.h > defines various constants related to control messages, for example the
function codes corresponding to the standard request types. This header file is provided by the common USB
package, not by the USB slave package, since the information is also relevant to USB hosts.
Other Control Messages
typedef struct usbs_control_endpoint {
...
usbs_control_return (*class_control_fn)(struct usbs_control_endpoint*, void*);
void* class_control_data;
usbs_control_return (*vendor_control_fn)(struct usbs_control_endpoint*, void*);
void* vendor_control_data;
usbs_control_return (*reserved_control_fn)(struct usbs_control_endpoint*, void*);
void* reserved_control_data;
...
} usbs_control_endpoint;
602