USB has four transmission modes. Control transfer, interrupt transfer, bulk transfer or block transfer, real-time transfer, or isochronous transfer. Each transmission mode has its own characteristics, which are as follows:
Features of Control Transfer
The USB protocol reference control transmission has two reasons, one, in the USB system, the device needs to be configured before the normal operation, and the USB host needs to have the device’s unique address on the bus to map the device, read and complete the equipment of various descriptors, according to the pipeline equipment endpoint configuration descriptor requirement, bandwidth, etc. On the other hand, in the process of device work, the host hopes to get the current status of the device in time, or the host wishes to take corrective action in time, if the device has problems, or the host changes the current configuration to match the device with some requirements. These two purposes apply to all USB devices and for this purpose transfer of control is introduced. All devices must have an endpoint that supports the transfer of power. Usually, endpoint number 0 is the control endpoint, defined as the device’s default endpoint using the USB protocol. The control transfer has the following properties:
- The control transport consists of the following transactions:
- Establishing a connection to transfer the requested information from the host to its application device
- Processing multiple data transfer transactions without working according to the address specified in the command to transfer data
- Returning status information
- The endpoint of the device used to control the transfer is bi-directional; it can receive and send packets, and the corresponding pipeline that controls the transmission is bi-directional
- All devices must have at least one control endpoint with the endpoint number 0
- It is reliable data transmission, supports error detection and data retransmission, and is as close as possible to the synchronization of the host and the device since a control transmission takes three or two stages
- Control mechanisms provide mechanisms for accessing device descriptors and command operations. The USB protocol defines the standard, device class, or device manufacturer-supplied commands (or requests) to a device that manipulates the state of the device. At the same time, the protocol also defines a set of descriptors to store various information about the USB device and to configure the device, which is completed by the control transfer
- The system does not specify the access bus frequency and bandwidth for the control transfer, which is generally determined by the USB protocol software (i.e. the USB control program of the host operating system) from a global optimization point of view
Features of Interrupt Transfer
Interrupt transmission is designed for a class of devices that only transmit or receive small amounts of data and do not normally transmit data, but have a defined transmission period, which is requested once in every specified period (not requiring the data to be sent once after a fixed period sent). Devices that use this type of transmission are keyboards, mice, joysticks, etc. All USB devices are configured by the system before they work properly, and if the configuration is successful, the device is allowed to work properly. Since interrupt transmission is a method of periodic transmission, the system configures the device performing the interrupt transmission so that the device can operate as long as the free bandwidth on the current bus for the periodic transmission can accommodate that device. Interrupt transfers have the following characteristics.
- The maximum service time (in milliseconds) of the interrupt transfer pipeline must be guaranteed
- It is a reliable data transmission method
- The renewed data transfer in case of errors takes place in the next service cycle
- The end of data is also determined by comparing it to the maximum number of transmitted bytes in the packet
- An endpoint used to pause streaming on a device can be used to transmit information about its speed to a real-time stream, e.g. B. an audio device. When using this mode, the endpoint’s synchronous DATA0/DATA1 handoff must change after each packet is sent to the host, regardless of the presence or type of the handshake packet, but only the incoming endpoint that breaks the stream supports this feature.
Features of Bulk Transfer (Block Transfer)
The USB protocol provides a type of batch transfer to support a large amount of data communication at an uncertain time, such as B. printers, scanners, hard drives, CDs, and other devices that have this data transfer property. When the bus time (bandwidth) is free in a frame, the USB host allocates the remaining time (bandwidth) to USB devices waiting for a batch transfer using the bus, i. H. a batch transfer can use any available bus bandwidth for data transfer. Batch streaming has the following properties:
- Bus bandwidth can be acquired dynamically
- It is a reliable data transmission mode. If the transmission fails, the data can be retransmitted
- There is confirmation of data transmission, but the bandwidth and delay of transmission are not guaranteed
- Batch transfers only occur when unused bandwidth is available. When the USB bus has more unused bandwidth, batch transfer will occur more frequently. If there is less unused bandwidth, batch processing may not take place for a long time
Features of Isochronous Transfer (Real-Transfer)
Real-time streaming is suggested to support some time-consuming and data-intensive applications. Devices using this type of transmission include microphones, modems, audio devices, etc. In order to achieve real-time transmission, the bus must first provide enough bandwidth. True direct transmission has the following characteristics:
- The real-time transfer has data with a fixed time delay but with a fixed bandwidth guarantee
- It is an unreliable data transmission that allows for a certain bit error rate
- As long as the data is available, a constant data rate in the pipeline can be guaranteed
- Software using this type of transfer need not run in real-time when used to support synchronous source and destination
- For real-time transfer, real-time performance is more important than data correction and retransmission. Given the low error rate of the bus, the protocol assumes that the transfer will generally be successful and that even a small data error will not have a major impact on the application (e.g. audio software). The receiver of the real-time transfer can determine if data is lost in a frame and how much data is missing
- During real-time transmission, the endpoint of real-time transmission never stops midway because there is no handshake signal to indicate an abort. Even if an error is detected, the real-time pipeline does not stop and the USB host continues to process the next frame of data. Because real-time transfer protocols do not support handshaking for every transaction, error detection is much weaker
- Only full-speed/high-speed devices can use real-time transmission
