Default control endpoint

Supported requests

Aside from the standard request support required by the USB standard for proper functioning of the device, a number of vendor specific requests can also be handled.

Request handling

The control endpoint processes requests in the following way, as illustrated by the diagram below:

• Initially, the control endpoint's FSM is in the CTRL_IDLE state.
• When a new setup packet is received, it should be copied into a usb_setup_packet_t object. This should then be passed, together with a (new) control_transfer_t object, to init_control_transfer().
• After the control_transfer_t object is properly initialised, it should be passed to process_setup(). The control_transfer_t object will now be in the CTRL_SETUP state.
• Pass the initialised control transfer object to process_setup(). If the state did not follow one of the allowed transitions from CTRL_SETUP, then this is a bad request and the endpoint should be stalled to notify the host. The stall is automatically cleared once the next setup request is received.
• Depending on the nature of the transfers, three valid states are now possible:
  • The data direction is IN, so the data for transmission is made available and the control transfer enters the CTRL_DATA_IN state.
  • The direction of the request is OUT, and additional data will follow. The FSM transitions to CTRL_DATA_OUT.
  • The direction of the request is OUT, but the request will have no data stage. In this case, the FSM transitions to CTRL_HANDSHAKE_OUT to acknowledge the transaction.
• If there is a data stage (CTRL_DATA_IN or CTRL_DATA_OUT), data has to be transferred from the host to the device or vice-versa. Since the data size is potentially larger than the endpoint size, this may mean multiple transfers will take place. Every time data is succesfully transfered, control_mark_data_done() should be called. This will increment the data pointer by the transferred amount and perform the data stage callback.
• Once all data is transferred, there is a compulsory handshake phase. For the CTRL_HANDSHAKE_IN state, this means waiting for a zero-length packet (ZLP) from the host confirming all the data from the device was correctly received. For the CTRL_HANDSHAKE_OUT state, this means sending a ZLP to indicate all data was received by the device. This is then followed by possible a post-handshake action and state if needed. The FSM should then be put back in the CTRL_IDLE state, waiting for a new setup request.