Comtrol eCos - Manual (Page 705)

Control Endpoints
} usbs_state_change;
The USB standard defines a number of states for a given USB peripheral. The initial state is detached, where the
peripheral is either not connected to a host at all or, from the host’s perspective, the peripheral has not started up
yet because the relevant pins are tristated. The peripheral then moves via intermediate attached and powered states
to its default or reset state, at which point the host and peripheral can actually start exchanging data. The first
message is from host to peripheral and provides a unique 7-bit address within the local USB network, resulting in a
state change to addressed. The host then requests enumeration data and performs other initialization. If everything
succeeds the host sends a standard set-configuration control message, after which the peripheral is configured and
expected to be up and running. Note that some USB device drivers may be unable to distinguish between the
detached, attached and powered states but generally this is not important to higher-level code.
A USB host should generate at least one token every millisecond. If a peripheral fails to detect any USB traffic for a
period of time then typically this indicates that the host has entered a power-saving mode, and the peripheral should
do the same if possible. This corresponds to the suspended bit. The actual state is a combination of suspended
and the previous state, for example configured and suspended rather than just suspended. When the peripheral
subsequently detects USB traffic it would switch back to the configured state.
The USB device driver and the common USB slave package will maintain the current state in the control endpoint’s
state field. There should be no need for any other code to change this field, but it can be examined whenever ap-
propriate. In addition whenever a state change occurs the generic code can invoke a state change callback function.
By default, no such callback function will be installed. Some class-specific packages such as the USB-ethernet
package will install a suitable function to keep track of whether or not the host-peripheral connection is up, that is
whether or not ethernet packets can be exchanged. Application code can also update this field. If multiple parties
want to be informed of state changes, for example both a class-specific package and application code, then typi-
cally the application code will install its state change handler after the class-specific package and is responsible for
chaining into the package’s handler.
The state change callback function is invoked with four arguments. The first identifies the control endpoint. The
second is an arbitrary pointer: higher-level code can fill in the
state_change_data field to set this. The third
argument specifies the state change that has occurred, and the last argument supplies the previous state (the new
state is readily available from the control endpoint structure).
eCos does not provide any utility functions for updating or examining the state_change_fn or
state_change_data fields. Instead, it is expected that the fields in the usbs_control_endpoint data structure
will be manipulated directly. Any utility functions would do just this, but at the cost of increased code and cpu
overheads.
Standard Control Messages
typedef struct usbs_control_endpoint {
...
unsigned char control_buffer[8];
usbs_control_return (*standard_control_fn)(struct usbs_control_endpoint*, void*);
void* standard_control_data;
...
} usbs_control_endpoint;
typedef enum {
USBS_CONTROL_RETURN_HANDLED = 0,
USBS_CONTROL_RETURN_UNKNOWN = 1,
USBS_CONTROL_RETURN_STALL = 2
} usbs_control_return;
601