USB Complete fourth- P10 doc

Chapter 3 66 Figure 3-3. A Setup Data packet initiates a SuperSpeed control write transfer. A Status transaction packet initiates the Status stage. A Transfer Type for Every Purpose 67 Figure 3-4. A SuperSpeed control write transfer is identical to a control read transfer except for the direction of the Data stage. Chapter 3 68 &CVC5K\G In a control transfer’s Data stage, the allowed maximum data packet size varies with bus speed: These bytes include only the information transferred in the data packet (USB 2.0) or Data Packet Payload (SuperSpeed), excluding PID and CRC bits. In the Data stage, all data packets except the last must be the maximum packet size for the endpoint. The maximum packet size for the default control pipe is in the device descriptor that the host retrieves during enumeration. If a transfer has more data than will fit in one data transaction, the host sends or receives the data in multiple transactions. For some control read transfers, the amount of data returned by the device can vary. If the amount is less than the requested number of bytes and is an even multiple of the endpoint’s maximum packet size, the device should indicate when it has no more data to send by returning a ZLP (USB 2.0) or a zero-length Data Payload (SuperSpeed) in response to a request for data after the device has sent all of its data. 5RGGF The host must make its best effort to ensure that all control transfers complete as quickly as possible. The host controller reserves a portion of the bus band- width for control transfers: 10% for low- and full-speed buses and 20% for high-speed and SuperSpeed buses. If the control transfers don’t need all of the reserved bandwidth, bulk transfers can use what remains. If the bus has other unused bandwidth, control transfers can use more than the reserved amount. The host attempts to parcel out the available time as fairly as possible to all devices. A single frame, microframe, or bus interval can contain multiple trans- actions for the same transfer, or a transfer’s transactions can be spread among multiple (micro)frames or bus intervals. There are two opinions on whether control transfers are appropriate for trans- ferring data other than enumeration and configuration data. Some believe con- $WU5RGGF /CZKOWO&CVC2CEMGV5K\G Low 8 Full 8, 16, 32, or 64 High 64 SuperSpeed 512 A Transfer Type for Every Purpose 69 trol transfers should be reserved as much as possible for servicing the standard USB requests and performing other infrequent configuration tasks. This approach helps ensure that the transfers complete quickly by keeping the reserved bandwidth as open as possible. But the USB specifications don’t forbid other uses for control transfers, and some see no problem in using control trans- fers for any purpose. Low-speed devices have no other option except periodic interrupt transfers that can waste bandwidth if data transfers are infrequent. Control transfers aren’t the most efficient way to transfer data. Each transfer has significant overhead. At low speed, a single control transfer with 8 data bytes uses over 1/3 of a frame’s bandwidth, though the transfer’s individual transac- tions may travel in multiple frames. In a control transfer with multiple data packets in the Data stage, the data may travel in the same or different (micro)frames or bus intervals. On a busy bus, all control transfers may have to share the reserved portion of the bandwidth. The USB specifications define timing limits that apply to control requests unless a class requires a faster response. Where stricter timing isn’t specified, in a transfer where the host requests data from the device, a device may delay as long as 500 ms before making the data available to the host. To find out if data is available, a USB 2.0 host sends a token packet to request the data. If the data is ready, the device returns the data in that transaction’s data packet. Otherwise the device returns NAK to advise the host to retry later. The host keeps trying at intervals for up to 500 ms. SuperSpeed devices can delay communications by setting NumP = 0 and Sequence Number = 0 in response to a Setup Data Packet or by sending NRDY in response to requested or received data. In a transfer where the host sends data to the device, if the host sends the data at the maximum rate the device can accept the data, a USB 2.0 device can take up to 5 seconds to accept all of the data and complete the Status stage (though once begun, the Status stage must complete within 50 ms). USB 3.0 devices must complete each transaction within 50 ms. Additional delays by the host extend the allowed time. In a transfer with no Data stage, the device must complete the request and the Status stage within 50 ms. The host and its drivers aren’t required to enforce the limits, but all devices should comply with the limits to ensure proper operation with any host. For the hub class, USB 2.0 and USB 3.0 recommend average response times of under 5 ms. &GVGEVKPICPF*CPFNKPI'TTQTU If a USB 2.0 device doesn’t return an expected handshake packet during a con- trol transfer, the host retries. On receiving no response after a (typical) total of Chapter 3 70 three tries, the host notifies the software that requested the transfer and stops communicating with the endpoint until the problem is resolved. The two retries include only those sent in response to no handshake at all. A NAK trig- gers a retry but doesn’t increment the error count. Control transfers use data toggles (USB 2.0) or Sequence Numbers (Super- Speed) to protect against lost data. In the Data stage of a USB 2.0 Control read transfer, on receiving the data from the device, the host normally returns ACK and then sends an OUT token packet to begin the Status stage. If the device for any reason doesn’t see the ACK returned after the transfer’s final data packet, the device must interpret a received OUT token packet as evidence that the Sta- tus stage has begun. Devices must accept all error-free Setup packets. If a new Setup packet arrives before a previous control transfer completes, the device must abandon the pre- vious transfer and start the new one. &GXKEG4GURQPUKDKNKVKGU A USB 2.0 device has these responsibilities for transfers on a control endpoint: • Send ACK in response to every Setup packet received without error. • For supported control write requests, send ACK in response to received data in the Data stage (if present) and return a ZLP in the Status stage. • For supported control read requests, send data in response to IN token packets in the Data stage and ACK the received ZLP in the Status stage. • For unsupported requests, return STALL in the Data or Status stage. A SuperSpeed device has these responsibilities for transfers on a control end- point: • Send an ACK Transaction Packet in response to Setup data received with- out error in Data Packets. • For supported control write requests, when there is a Data stage, send an ACK Transaction Packet in response to received data in Data Packets. In the Status stage, send an ACK Transaction Packet in response to a received STATUS Transaction Packet. • For supported control read requests, receive acknowledgements and requests to send data in ACK Transaction Packets and send data in Data Packets. In the Status stage, send an ACK Transaction Packet in response to a received STATUS Transaction Packet. A Transfer Type for Every Purpose 71 • For unsupported requests, return a STALL Transaction packet in the Data or Status stage . $WNM6TCPUHGTU Bulk transfers are useful for transferring data when time isn’t critical. A bulk transfer can send large amounts of data without clogging the bus because the transfers defer to the other transfer types, waiting until time is available. Uses for bulk transfers include sending data to a printer, sending data from a scanner, and reading and writing to a drive. On an otherwise idle bus, bulk transfers are the fastest transfer type. #XCKNCDKNKV[ Low speed doesn’t support bulk transfers. Devices aren’t required to support bulk transfers, but a specific device class may require them. For example, a mass-storage device must have a bulk endpoint in each direction. 5VTWEVWTG A USB 2.0 bulk transfer consists of one or more IN or OUT transactions (Fig- ure 3-5). All data travels in one direction. Transferring data in both directions requires a separate pipe and transfer for each direction. A bulk transfer ends successfully when the expected amount of data has trans- ferred or when a transaction contains less than the endpoint’s maximum packet size, including zero data bytes. The USB 2.0 specification doesn’t define a pro- tocol for indicating the number of data bytes in a bulk transfer. When needed, the device and host can use a class-specific or vendor-specific protocol to pass this information. For example, a transfer can begin with a header that specifies the number of bytes to be transferred, or the device or host can use a class-spe- cific or vendor-specific protocol to request a quantity of data. *KIJ5RGGF&KHHGTGPEGU To conserve bus time, a host may use the PING protocol in some high-speed bulk transfers. If a high-speed bulk OUT transfer has more than one data packet and the device returns NYET after receiving a packet, the host may use PING to find out when it’s OK to send more data. In a bulk transfer on a high-speed bus with a low- or full-speed device, the host uses split transactions for all of the transfer’s transactions. Chapter 3 72 5WRGT5RGGF&KHHGTGPEGU Figure 3-6 shows SuperSpeed bulk IN and OUT transactions. In an IN transac- tion, the host sends an ACK Transaction Packet to request one or more Data Packets and acknowledge previous data, if any, and the device sends Data Packet(s), NRDY, or STALL. On receiving a Data Packet, the host returns an ACK Transaction Packet. If the host requests multiple Data Packets by setting NumP > 1, the device doesn’t have to wait for each ACK before sending the next packet. If NumP > 0 in an ACK Transaction Packet that the host sends in Figure 3-5. USB 2.0 bulk and interrupt transfers have identical structure, but different scheduling by the host. Not shown are the PING protocol used in some high-speed bulk OUT transfers with multiple data packets or the split transactions used with low- and full-speed devices on a high-speed bus. A Transfer Type for Every Purpose 73 response to received data, the packet also serves as a request for more data. In an OUT transaction, the host sends data in Data Packets, and the device acknowl- edges receiving data in ACK Transaction Packets or returns NRDY or STALL. After an endpoint has sent NRDY, a host can attempt to resume communica- tions even if the endpoint hasn’t sent ERDY. SuperSpeed bulk transfers can use a Stream Protocol to transfer multiple, inde- pendent data streams using a single endpoint. A class or other host driver can define uses for the streams. Each stream has its own endpoint buffer. A CStream ID identifies the current stream in Data Packet Headers and in ACK, NRDY, and ERDY Transaction Packets. Figure 3-6. SuperSpeed bulk and interrupt transfers use ACK transaction packets to request and acknowledge data. Chapter 3 74 &CVC5K\G The allowed maximum data bytes in a bulk transaction’s data packet vary with the bus speed: These bytes include only the information transferred in the data packet (USB 2.0) or Data Packet Payload (SuperSpeed), excluding PID and CRC bits. During enumeration, the host reads the maximum packet size for each bulk endpoint from the device’s descriptors. The amount of data in a transfer may be less than, equal to, or greater than the maximum packet size. If the data doesn’t fit in a single packet, the host uses multiple transactions to complete the trans- fer. 5RGGF The host controller guarantees that bulk transfers will complete eventually but doesn’t reserve bandwidth for them. Control transfers are guaranteed to have 10% of the bandwidth at low and full speeds and 20% at high speed and Super- Speed. Interrupt and isochronous transfers may use the rest. So if a bus is very busy, a bulk transfer can take a very long time. However, when the bus is otherwise idle, bulk transfers can use the most band- width of any type and have low overhead and thus are the fastest of all. When a full-speed bulk endpoint’s maximum packet size is less than 64, some host con- trollers schedule no more than one packet per frame even if more bandwidth is available. Thus for best performance, a full-speed bulk endpoint should have a maximum packet size of 64. At full speed on an otherwise idle bus, up to nineteen 64-byte bulk transfers can transfer up to 1,216 data bytes per frame, for a data rate of 1.216 MB/s. In the- ory, at high speed on an otherwise idle bus, up to thirteen 512-byte bulk trans- fers can transfer up to 6,656 data bytes per microframe, for a data rate of 53.248 MB/s. Real-world performance varies with the host-controller hardware and driver and the host architecture, including latencies when accessing system memory. Some high-speed hosts can transfer bulk data at around 35 MB/s. A SuperSpeed bus can transfer around 400 MB/s in bulk transfers. $WU5RGGF /CZKOWO&CVC2CEMGV5K\G Full 8, 16, 32, or 64 High 512 SuperSpeed 1024 A Transfer Type for Every Purpose 75 &GVGEVKPICPF*CPFNKPI'TTQTU If a USB 2.0 device doesn’t return an expected handshake packet, the host tries up to twice more. A host also retries on receiving NAK. The class or device driver determines whether the host eventually gives up on receiving multiple NAKs. For SuperSpeed endpoints, a device uses NRDY and ERDY to cause the host to stop requesting to send or receive data when an endpoint isn’t ready to receive data or has no data to send. Data toggles (USB 2.0) or Sequence Num- bers (SuperSpeed) detect lost or repeated data. &GXKEG4GURQPUKDKNKVKGU A USB 2.0 device has these responsibilities for transfers on a bulk endpoint: • For OUT transfers, ACK data received in data packets. • For IN transfers, return data in data packets in response to IN token pack- ets. A SuperSpeed device has these responsibilities for transfers on a bulk endpoint: • For OUT transfers, send ACK Transaction Packets to acknowledge data received in Data Packets. • For IN transfers, receive requests to send data and acknowledgements of received data in ACK Transaction Packets and send data in Data Packets. +PVGTTWRV6TCPUHGTU Interrupt transfers are useful when data has to transfer without delay. Typical applications include keyboards, pointing devices, game controllers, and hub status reports. Users don’t want a noticeable delay between pressing a key or moving a mouse and seeing the result on screen. A hub needs to report the attachment or removal of devices promptly. Low-speed devices, which support only control and interrupt transfers, are likely to use interrupt transfers. At low and full speeds, the bandwidth available for an interrupt endpoint is limited, but high speed and SuperSpeed loosen the limits. Interrupt transfers are interrupt-like because they guarantee fast response from the host. For both bulk and interrupt endpoints, firmware typically uses inter- rupts to detect new received data. On a USB 2.0 bus, both bulk and interrupt endpoints must wait for the host to request data before sending data. Super- Speed bulk and interrupt endpoints can notify the host that they have data to . data, a USB 2.0 device can take up to 5 seconds to accept all of the data and complete the Status stage (though once begun, the Status stage must complete within 50 ms). USB 3.0 devices must complete. operation with any host. For the hub class, USB 2.0 and USB 3.0 recommend average response times of under 5 ms. &GVGEVKPICPF*CPFNKPI'TTQTU If a USB 2.0 device doesn’t return an expected. as possible for servicing the standard USB requests and performing other infrequent configuration tasks. This approach helps ensure that the transfers complete quickly by keeping the reserved