Once an address has been allocated, time-division transfers are executed between the host PC and the peripheral device. The host executes the transfers in the order determined according to a set or rules. In terms of priority, Isochronous transfers need to maintain the notion of time, and hence have the highest priority, followed by Interrupt transfers, which must perform periodically access to devices. For example, due to the hot-swapping capability of USB, a device can be connected to or disconnected from a hub at any time. Interrupt transfers must hence be used to periodically inform the host of the hub's status. The priority of Bulk and Control transfers are also determined by the host PC. To avoid situations in which Bulk and Control transfers cannot be initiated, a certain proportion of each frame/microframe is always allocated to Bulk or Control transfer.
Since Control transfers are used to configure and control devices under the USB environment, its contents must be interpreted in the same manner by all USB devices. The format and data contents of Control transfers are hence strictly defined. On the other hand, Bulk, Interrupt, and Isochronous transfers are used to transfer data, so their contents cannot be defined. In other words, the contents of Bulk, Interrupt, and Isochronous transfers do not have much significance as far as the USB bus is concerned.
When executing Control and Bulk transfers, there is no need to make considerations from the perspective of time. However, Isochronous and Interrupt transfers require time management in one form or another. USB manages time in units called "frames" (USB 2.0 further added "microframes"), and uses frames/microframes to realize the concept of time. Each "frame" represents 1 ms, and each microframe represents 125 μs. The amount of Non-Periodic (Bulk or Control) transfers within a particular time unit will vary depending on the amount of Periodic (Interrupt or Isochronous) transfers within the same time unit.
If Periodic transfers occupy a frame/microframe entirely, they may prevent Non-Periodic transfers from being initiated, so a particular section of each frame/microframe is always reserved for Non-Periodic transfers, even though Non-Periodic transfers do not require time management.
1) Periodic and Non-Periodic transfers within a frame
2) Allocation of a frame to various applications
In controlling the transfers, the host controller uses frames/microframes for time management. When performing Control/Bulk/Interrupt transfers with a peripheral device, there is little need to pay attention to the frames/microframes. However, when performing Isochronous transfers, frames/microframes may need to be taken into consideration for proper synchronization with the system. For this reason, the host issues SOF (Start Of Frame) packets to the bus to indicate the starting point of each frame/microframe.
SOF packets are composed of 4 elements: SYNC, PID, Frame No., and CRC5. SOF packets for USB 2.0 microframes essentially have the same structure.
SYNC is used to synchronize the peripheral device's clock with the transferred data. Note that SYNC differs somewhat between USB 1.x and USB 2.0.
PID is the "Packet Identifier," and identifies the content of the transferred packet. PID for SOF is "b0101." Since an error may occur in the PID, PID+PID (1's complement) is transmitted for error detection. Meaning, the PID will actually be sent as "A5h."
The Frame No. is an 11-bit field that is used to label the frames, and is incremented by 1 for every 1 frame. Under USB 2.0, the Frame No. is incremented by 1 for every 8 microframes, and not for every 1 microframe (meaning that the Frame No. is always incremented once every 1 ms). For this reason, the same SOF is transmitted 8 times under the USB 2.0 high-Speed mode.
CRC5 is a 5-bit data that is used to detect bit errors by a method called Cyclic Redundancy Check. This data is used to protect the Frame No. data, and has a better error detection rate than parity checks.
All packets are sent starting from the LSB. For example, SYNC80h, transmitted sequentially from left to right, will be represented as b00000001.
Control, Bulk, Interrupt, and Isochronous transfers all consist of 3 types of packets: Token, Data, and Handshake.
A Token has the same structure as SOF packets described above, but sends an Address and an Endpoint No. instead of the Frame No. (i.e. SYNC -> PID -> Address -> Endpoint -> CRC5). Token packets are sent in the beginning to specify the target and the direction of the transfer. TOKEN ID for data transfers are classified into 3 groups: Setup (2Dh) for sending USB requests such as Set Address, In (69h) for indicating the start of an In transfer, and Out (E1h) for indicating the start of an Out transfer.
Address is a 7-bit data (For specifying up to 127 device addresses. The default address of "00h" cannot be used as a unique address.), and Endpoint No. is a 4-bit data. CRC5 is used to protect the Address and Endpoint No. data.
A Token packet is followed by a Data packet that carries the actual data. Data packets are structured as SYNC -> PID -> Data -> CRC16. Data packets have 2 PIDs: DATA0 (C3h) and DATA1 (4Bh). The 2 Data PIDs are used alternately to allow recovery from transfer problems (to be detailed later). Following the Data PID, a data with a size between 0 to Max Packet Size is sent (Max Packet Size for a peripheral device will either be the Max Packet Size defined in the specification, or a smaller FIFO size). CRC16 is used for data protection.
If an In Token has no data to respond with, it will send a Handshake (NAK or STALL) packet instead of a Data packet. An Out Token will always respond with a Handshake (NAK or STALL) packet after the Data packet, regardless of whether data can be received (PIDs PING and NYET were added in USB 2.0).
Handshake packets are structured as SYNC -> PID. There are 3 PIDs defined for Handshake packets: ACK (D2h) that indicates successful reception, NAK (5Ah) that indicates inability to send or receive due to incomplete processes, and STALL (1Eh) that indicates a problem with the system.
Note that Isochronous transfers do not use Handshake packets, since there is no time to be resending data, regardless of whether all data is delivered successfully.