IceCube display
LED display to show IceCube event data
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.