Types of USB Data Transfers
All communication between a USB host and a USB device is addressed to a specific endpoint on the device. Each device endpoint is a unidirectional receiver or transmitter of data; either specified as a sender or receiver of data from the host.
Each endpoint is different, specified through their bandwidth requirements and the way they transfer data. The Universal Serial Bus specification defines four transfer/endpoint types:
Control Transfers
Control transfers are Non-periodic transfers. Typically, used for device configuration, commands, and status operation. They are essential to set up a USB device with all enumeration functions being performed using control transfers. They are typically robust, random packets which are initiated by the host and use best effort delivery. The packet length of control transfers in low speed devices must be 8 bytes, high speed devices allow a packet size of 8, 16, 32 or 64 bytes and full speed devices must have a packet size of 64 bytes.
Let's say for example, the Host wants to request a device descriptor during enumeration. The packets which are sent are as follows.
The host will send the Setup token telling the function that the following packet is a Setup packet. The Address field will hold the address of the device the host is requesting the descriptor from. The endpoint number should be zero, specifying the default pipe. The host will then send a DATA0 packet. This will have an 8 byte payload which is the Device Descriptor Request. The USB function then acknowledges the setup packet has been read correctly with no errors. If the packet was received corrupt, the device just ignores this packet. The host will then resend the packet after a short delay.
| SYNC | PID | ADDR | ENDP | CRC5 | EOP |
|---|
| SYNC | PID | DATA0 | CRC16 | EOP |
|---|
| SYNC | PID | EOP |
|---|
The above three packets represent the first USB transaction. The USB device will now decode the 8 bytes received, and determine if it was a device descriptor request. The device will then attempt to send the Device Descriptor, which will be the next USB transaction.
| SYNC | PID | ADDR | ENDP | CRC5 | EOP |
|---|
| SYNC | PID | Data1 | CRC16 | EOP |
|---|
| SYNC | PID | EOP |
|---|
| SYNC | PID | ADDR | ENDP | CRC5 | EOP |
|---|
| SYNC | PID | Data0 | CRC16 | EOP |
|---|
| SYNC | PID | EOP |
|---|
In this case, we assume that the maximum payload size is 8 bytes. The host sends the IN token, telling the device it can now send data for this endpoint. As the maximum packet size is 8 bytes, we must split up the 12 byte device descriptor into chunks to send. Each chunk must be 8 bytes except for the last transaction. The host acknowledges every data packet we send it.
Once the device descriptor is sent, a status transaction follows. If the transactions were successful, the host will send a zero length packet indicating the overall transaction was successful. The function then replies to this zero length packet indicating its status.
| SYNC | PID | ADDR | ENDP | CRC5 | EOP |
|---|
| SYNC | PID | Data1 | CRC16 | EOP |
|---|
| SYNC | PID | EOP |
|---|
Interrupt Transfers
This is a transaction that is guaranteed to occur within a certain time interval. The device will specify the time interval at which the host should check the device to see if there is new data. This is used by input devices such as mice and keyboards.
Any one who has had experience of interrupt requests on microcontrollers will know that interrupts are device generated. However under USB if a device requires the attention of the host, it must wait until the host polls it before it can report that it needs urgent attention!
Interrupt Transfers
Interrupt transfers are typically non-periodic, small device "initiated" communication requiring bounded latency. An Interrupt request is queued by the device until the host polls the USB device asking for data.
The above diagram shows the format of an Interrupt IN and Interrupt OUT transaction.
IN: The host will periodically poll the interrupt endpoint. This rate of polling is specified in the endpoint descriptor which is covered later. Each poll will involve the host sending an IN Token. If the IN token is corrupt, the function ignores the packet and continues monitoring the bus for new tokens.
If an interrupt has been queued by the device, the function will send a data packet containing data relevant to the interrupt when it receives the IN Token. Upon successful reciept at the host, the host will return an ACK. However if the data is corrupted, the host will return no status. If on the other hand an interrupt condition was not present when the host polled the interrupt endpoint with an IN token, then the function signals this state by sending a NAK. If an error has occurred on this endpoint, a STALL is sent in reply to the IN token instead.
OUT: When the host wants to send the device interrupt data, it issues an OUT token followed by a data packet containing the interrupt data. If any part of the OUT token or data packet is corrupt then the function ignores the packet. If the function's endpoint buffer was empty and it has clocked the data into the endpoint buffer it issues an ACK informing the host it has successfully received the data. If the endpoint buffer is not empty due to processing of a previous packet, then the function returns a NAK. However if an error occurred with the endpoint consequently and its halt bit has been set, it returns a STALL.
Isochronous Transfers
Periodic and continuous transfer for time-sensitive data. There is no error checking or retransmission of the data sent in these packets. They typically contain time sensitive information, such as an audio or video stream. If there were a delay or retry of data in an audio stream, then you would expect some erratic audio containing glitches. The beat may no longer be in sync. However if a packet or frame was dropped every now and again, it is less likely to be noticed by the listener. This is used for devices that need to reserve bandwidth and have a high tolerance to errors. Examples include multimedia devices for audio and video.
Isochronous Transfers provide
The maximum size data payload is specified in the endpoint descriptor of an Isochronous Endpoint. This can be up to a maximum of 1023 bytes for a full speed device and 1024 bytes for a high speed device. As the maximum data payload size is going to effect the bandwidth requirements of the bus, it is wise to specify a conservative payload size. If you are using a large payload, it may also be to your advantage to specify a series of alternative interfaces with varying isochronous payload sizes. If during enumeration, the host cannot enable your preferred isochronous endpoint due to bandwidth restrictions, it has something to fall back on rather than just failing completely. Data being sent on an isochronous endpoint can be less than the pre-negotiated size and may vary in length from transaction to transaction.
The above diagram shows the format of an Isochronous IN and OUT transaction. Isochronous transactions do not have a handshaking stage and cannot report errors or STALL/HALT conditions.
Bulk Transfers
General transfer scheme for large amounts of data. Such examples could include a print-job sent to a printer or an image generated from a scanner. This is for contexts where it is more important that the data is transmitted without errors than for the data to arrive in a timely manner. Bulk transfers have the lowest priority. If the bus is busy with other transfers, this transaction may be delayed. The data is guaranteed to arrive without error. If an error is detected in the CRCs, the data will be retransmitted.
Bulk transfers will use spare un-allocated bandwidth on the bus after all other transactions have been allocated. If the bus is busy with isochronous and/or interrupt then bulk data may slowly trickle over the bus. As a result Bulk transfers should only be used for time insensitive communication as there is no guarantee of latency.
Bulk Transfers
Bulk transfers are only supported by full and high speed devices. For full speed endpoints, the maximum bulk packet size is either 8, 16, 32 or 64 bytes long. For high speed endpoints, the maximum packet size can be up to 512 bytes long. If the data payload falls short of the maximum packet size, it doesn't need to be padded with zeros. A bulk transfer is considered complete when it has transferred the exact amount of data requested, transferred a packet less than the maximum endpoint size, or transferred a zero-length packet.
The above diagram shows the format of a bulk IN and OUT transaction.
IN: When the host is ready to receive bulk data it issues an IN Token. If the function receives the IN token with an error, it ignores the packet. If the token was received correctly, the function can either reply with a DATA packet containing the bulk data to be sent, or a stall packet indicating the endpoint has had a error or a NAK packet indicating to the host that the endpoint is working, but temporary has no data to send.
OUT: When the host wants to send the function a bulk data packet, it issues an OUT token followed by a data packet containing the bulk data. If any part of the OUT token or data packet is corrupt then the function ignores the packet. If the function's endpoint buffer was empty and it has clocked the data into the endpoint buffer it issues an ACK informing the host it has successfully received the data. If the endpoint buffer is not empty due to processing a previous packet, then the function returns an NAK. However if the endpoint has had an error and its halt bit has been set, it returns a STALL.
