USB Complete fourth- P11 pdf

Chapter 3 76 send by sending an ERDY Transaction Packet but still must wait for the host to request data packets. #XCKNCDKNKV[ All speeds allow interrupt transfers. Devices aren’t required to support interrupt transfers, but a device class may require it. For example, a HID-class device must support interrupt IN transfers for sending data to the host. 5VTWEVWTG A USB 2.0 interrupt transfer consists of one or more IN transactions or one or more OUT transactions. Transferring data in both directions requires a separate transfer and pipe for each direction. On the bus, interrupt transactions are identical to bulk transactions (Figure 3-5 and Figure 3-6) with these differences: • Interrupt transactions have guaranteed maximum latency and thus differ- ent scheduling by the host. • The host doesn’t use the PING protocol in high-speed interrupt transfers. • SuperSpeed interrupt transfers don’t support Streams. • On a SuperSpeed bus, after receiving NRDY, a host must wait for ERDY before resuming communications with an interrupt endpoint. (Waiting is optional for bulk endpoints.) An interrupt transfer ends successfully when the expected amount of data has transferred or when a transaction contains less than the endpoint’s maximum packet size, including zero data bytes. The USB specification doesn’t define a protocol for specifying the amount of data in an interrupt transfer. When needed, the device and host can use a class-specific or vendor-specific protocol to pass this information. *KIJ5RGGF&KHHGTGPEGU In an interrupt 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. Unlike high-speed bulk OUT transfers, high-speed interrupt OUT transfers can’t use the PING protocol when a transfer has multiple transactions. A Transfer Type for Every Purpose 77 5WRGT5RGGF&KHHGTGPEGU The host schedules ACK Transaction Packets to an IN endpoint until the device has sent all of the transfer’s data, or the device returns a Data Packet Header with the End Of Burst bit set, or the device returns an ERDY or STALL Transaction Packet. The host sends Data Packets to an OUT endpoint until the host has no more data to send or the device returns a NRDY or STALL Trans- action Packet. After receiving NRDY, the host must receive an ERDY Transac- tion Packet to resume communications with the endpoint. To ensure fast response when a device is ready to communicate, the host’s delay between receiving an ERDY and sending an ACK Transaction Packet is at most 2× the service interval specified in the endpoint’s descriptor. The USB 3.0 specification advises that SuperSpeed interrupt transfers are intended only for small amounts of data that must transfer within defined ser- vice intervals. In other words, to transfer a large block of data, another transfer type such as bulk is a better choice. &CVC5K\G The allowed maximum data bytes in an interrupt transaction’s data packet var- ies with bus speed and the number of packets per microframe (high speed) or the number of packets per bus interval and the bMaxBurst value (SuperSpeed): These bytes include only the information transferred in the data packet (USB 2.0) or Data Packet Payload (SuperSpeed), excluding PID and CRC bits. USB 2.0 and USB 3.0 require interrupt endpoints in a default interface to have a maximum packet size of 64 bytes or less. If the data doesn’t fit in a single transaction, the host uses multiple transactions to complete the transfer. $WU5RGGF /CZKOWO &CVC2CEMGV5K\G /CZKOWO)WCTCPVGGF 2CEMGVU+PVGTXCN Low 1–8 1 / 10 frames Full 1–64 1 / frame High 1–1024 1 / microframe 513–1024 2 / microframe 683–1024 3 / microframe SuperSpeed 1–1024 and bMaxBurst = 0 1 / bus interval 1024 and bMaxBurst > 0 3 / bus interval Chapter 3 78 5RGGF An interrupt transfer guarantees a maximum latency, or time between transac- tion attempts. In other words, there is no guaranteed transfer rate, just the guar- antee that the host will make bandwidth available for a transaction attempt in each maximum latency period. A SuperSpeed endpoint can request a burst of up to three 1024-byte packets per bus interval for a maximum data throughput of 24.576 MB/s. A high-speed endpoint can request up to three 1024-byte packets per microframe, which also results in a maximum throughput of 24.576 MB/s. A high-speed endpoint that requests more than 1024 bytes per microframe is called a high-bandwidth end- point. For hosts that don’t support high-bandwidth interrupt endpoints, the maximum is 8.192 MB/s. At this writing, the Windows drivers don’t support high-speed, high-bandwidth interrupt endpoints. If the host’s driver doesn’t support alternate interfaces, the maximum is the 64 kB/s allowed for the default interface. A full-speed endpoint can request up to 64 bytes per frame, or 64 kB/s. A low-speed endpoint can request only up to 8 bytes every 10 ms. Devices with endpoints that need to transfer more than 800 bytes/sec. should not be low speed. On a USB 1.x bus, low-speed traffic uses much more bandwidth than full-speed traffic. Limiting the bandwidth available to low-speed end- points helps keep the bus available for other devices The endpoint descriptor stored in the device specifies the maximum latency period. For low-speed devices, the maximum latency can be any value from 10– 255 ms. For full speed, the range is 1–255 ms. For high speed and SuperSpeed, the range is 125 µs to 4.096 s in increments of 125 µs. In addition, a high-speed or SuperSpeed interrupt endpoint with a maximum latency of 125 µs can request 1, 2, or 3 transactions per interval. The host can begin each transaction at any time up to the specified maximum latency since the previous transaction began. So, for example, on a full-speed bus with a 10 ms maximum latency, five transfers could take as long as 50 ms or as little as 5 ms. OHCI host controllers for low and full speeds schedule trans- actions in periods of 1, 2, 4, 8, 16, or 32 ms. For a full-speed device that requests a maximum anywhere from 8 to 15 ms, an OHCI host will begin a transaction every 8 ms, while a maximum latency from 32 to 255 will cause a transaction attempt every 32 ms. However, devices shouldn’t rely on behavior that is specific to a type of host controller and should assume only that the host complies with the specification. Chapter 8 has more about host-controller types. A Transfer Type for Every Purpose 79 Because the host is free to transfer data more quickly than the requested rate, interrupt transfers don’t guarantee a precise rate of delivery. The only exceptions are when the maximum latency equals the fastest possible rate. For example, on a USB 1.x host, a full-speed interrupt pipe configured for 1 transaction per ms will have reserved bandwidth for one transaction per frame. A class driver or device driver for an interrupt IN endpoint can cause the host controller to schedule an IN transaction in each interval. The HID driver is an example. Or a driver can request the host controller to schedule an IN transaction only when an application has requested data. The WinUSB driver is an example of this behavior. For interrupt OUT data, the driver requests transactions only when an application or other software component has provided data to send. High-speed interrupt and isochronous transfers combined can use no more than 80% of a microframe. SuperSpeed interrupt and isochronous transfers combined can use no more than 80% of a bus interval. Full-speed isochronous transfers and low- and full-speed interrupt transfers combined can use no more than 90% of a frame. The section More about Time-critical Transfers below has more about the capabilities and limits of interrupt transfers. &GVGEVKPICPF*CPFNKPI'TTQTU If a device doesn’t return an expected handshake packet, host controllers retry up to twice more. On receiving NAK, a USB 2.0 host may retry without limit. For example, a keyboard might sit idle for days before someone presses a key. A host driver might increment an error count on every incomplete transaction (with no received handshake packet), resetting the count when the device returns data or ACK and stopping communications to the endpoint if the error count reaches a defined number. These errors should be rare, yet a device that is NAKing for a long time might accumulate enough errors to cause the host to stop communicating. If you can’t change the driver to cause it to reset the error counter and retry in this situation, a solution is for the device to send data peri- odically, defining a “no operation” code if needed for this situation. SuperSpeed endpoints use NRDY and ERDY as described in Chapter 2 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 and to enable an endpoint to request to resume communications. Interrupt transfers can use data toggles (USB 2.0) or Sequence Numbers (SuperSpeed) to ensure that all data is received without errors. A receiving end- Chapter 3 80 point that cares only about getting the most recent data can ignore the data tog- gle or Sequence Number. &GXKEG4GURQPUKDKNKVKGU Device responsibilities for interrupt endpoints are the same as for bulk end- points. +UQEJTQPQWU6TCPUHGTU Isochronous transfers are streaming, real-time transfers that are useful when data must arrive at a constant rate or within a specific time limit and occasional errors are tolerable. At full speed and SuperSpeed, isochronous transfers can transfer more data per frame or bus interval compared to interrupt transfers, but the transfer type doesn’t support automatic resending of data received with errors. Examples of uses for isochronous transfers include encoded voice and music to be played in real time. Data that will eventually be consumed at a constant rate doesn’t always require an isochronous transfer. For example, a host can use a bulk transfer to send a music file to a device. After receiving the file, the device can stream the music on request. Nor does the data in an isochronous transfer have to be real-time data such as audio and video. An isochronous transfer is a way to ensure that any block of data has reserved bandwidth on a busy bus. Unlike with bulk transfers, a host guarantees that a configuration’s requested isochronous bandwidth will be avail- able, so the completion time is predictable. #XCKNCDKNKV[ Low speed doesn’t support isochronous transfers. Devices aren’t required to sup- port isochronous transfers but a device class may require them. For example, many audio- and video-class devices use isochronous endpoints. 5VTWEVWTG Isochronous means that the data has a fixed transfer rate, with a defined number of bytes transferring in every frame, microframe, or bus interval. A USB 2.0 isochronous transfer consists of one or more IN transactions or one or more OUT transactions at equal intervals. Transferring data in both direc- tions requires a separate transfer and pipe for each direction. High-speed and A Transfer Type for Every Purpose 81 SuperSpeed isochronous transfers are more flexible. They can request as many as 3 transactions per microframe (USB 2.0) or 48 transactions per bus interval (SuperSpeed) or as little as 1 transaction every 32,768 microframes/bus inter- vals. Figure 3-7 shows the packets in full-speed isochronous IN and OUT transac- tions. An isochronous transfer is one way. The transactions in a transfer must all be IN transactions or all OUT transactions. Transferring data in both directions requires a separate pipe and transfer for each direction. The USB 2.0 specification doesn’t define a protocol for specifying the amount of data in an isochronous transfer. When needed, the device and host can use a class-specific or vendor-specific protocol to pass this information. Before requesting a device configuration that consumes isochronous band- width, the host controller determines whether the requested bandwidth is avail- able by comparing the available unreserved bus bandwidth with the maximum packet size and requested transfer rate of the configuration’s isochronous end- point(s). Every USB 2.0 or USB 3.0 device with isochronous endpoints must have an interface that requests no isochronous bandwidth so the host can configure the Figure 3-7. USB 2.0 isochronous transfers don’t have handshake packets, so occasional errors must be acceptable. Not shown are the split transactions use d with full-speed devices on a high-speed bus or the data PID sequencing in high-speed transfers with multiple data packets per microframe. Chapter 3 82 device even if the bus has no available reservable bandwidth. In addition to this interface and an alternate interface that requests the optimum bandwidth for a device, a device can support additional alternate interfaces that have smaller iso- chronous data packets or transfer fewer isochronous packets per microframe. The device driver can then request to use an interface that transfers data at a slower rate if needed. Or the driver can try again later in the hope that the bandwidth will be available. After the host configures the device and selects an interface, the transfers are guaranteed to have the time they need. Each transaction has overhead and must share the bus with other devices. The host can schedule a transaction anywhere within a scheduled (micro)frame or bus interval. Isochronous transfers may also synchronize to another data source or recipient, SOF packets (USB 2.0), or Isochronous Timestamp Packets (SuperSpeed). For example, a microphone’s input may synchronize to the out- put of speakers. The descriptor for a USB 2.0 or higher isochronous endpoint can specify a synchronization type and a usage value that indicates whether the endpoint contains data or feedback information used to maintain synchroniza- tion. Figure 3-8. As with USB 2.0, SuperSpeed endpoints don’t acknowledge isochronous data packets. A Transfer Type for Every Purpose 83 *KIJ5RGGF&KHHGTGPEGU If a host is performing an isochronous transfer with a full-speed device on a high-speed bus, the host uses the split transactions introduced in Chapter 2 for all of the transfer’s transactions. Isochronous OUT transactions use start-split transactions but don’t use complete-splits because there is no status information to report back to the host. Isochronous transfers don’t use the PING protocol. 5WRGT5RGGF&KHHGTGPEGU Figure 3-8 shows SuperSpeed isochronous IN and OUT transactions. The first Data Packet in a service interval has Sequence Number = 0. The Sequence Number increments with each Data Packet that follows in the service interval. In an IN transaction, the host sends a single ACK Transaction Packet to request one or more Data Packets in a service interval, and the device sends the packet(s). In an OUT transaction, the host sends data in Data Packets, and the device sends nothing. The endpoint descriptor specifies the length of a service interval and the number of Data Packets per service interval. For the last data packet in the service interval, the sender sets the last packet flag in the Data Packet Header. &CVC5K\G The allowed maximum data bytes in an isochronous transaction’s data packet varies with bus speed and the number of packets per microframe (high speed) or the number of packets per bus interval and bMaxBurst (SuperSpeed): These bytes include only the information transferred in the data packet (USB 2.0) or Data Packet Payload (SuperSpeed), excluding PID and CRC bits. If the data doesn’t fit in a single packet, the host completes the transfer in mul- tiple transactions. Within a USB 2.0 transfer, the amount of data in each trans- $WU5RGGF /CZKOWO &CVC2CEMGV5K\G /CZKOWO0WODGTQH 2CEMGVU+PVGTXCN Full 0–1023 1 / frame High 0–1024 1 / microframe 513–1024 2 / microframe 683–1024 3 / microframe SuperSpeed 0–1024 and bMaxBurst = 0 3 / bus interval 1024 and bMaxBurst > 0 48 / bus interval Chapter 3 84 action doesn’t have to be the same and doesn’t have to be the maximum packet size. For example, data at 44,100 samples per second could use a sequence of 9 packets containing 44 samples each, followed by 1 packet containing 45 sam- ples. SuperSpeed endpoints can support up to 3 burst transactions per service inter- val, with each burst consisting of up to 16 Data Packets. All but the last Data Packet in a burst must be the endpoint’s maximum packet size. In addition, each burst except the last must have an equal number of Data Packets, and the number of Data Packets in each burst except the last must be 2, 4, 8, or 16. For example, with endpoint support for 16 Data Packets per burst, the quickest way to send 48 maximum-size Data Packets is in 3 bursts of 16 Data Packets each. With endpoint support for 3 bursts per service interval, all of the data can transfer within one service interval. But the sender also has the option to send the data in 6 bursts of 8 Data Packets each, 12 bursts of 4 Data Packets each, 24 bursts of 2 Data Packets each, or 48 non-burst Data Packets. In a similar way, transferring 47 Data Packets can use 2 bursts of 16 Data Pack- ets each followed by one burst of 15 packets, 5 bursts of 8 Data Packets each followed by one burst of 7 packets, 11 bursts of 4 Data Packets each followed by one burst of 3 packets, 23 bursts of 2 Data Packets each followed by one burst of 1 packet, or 47 non-burst Data Packets. 5RGGF A full-speed isochronous transaction can transfer up to 1023 bytes per frame, or up to 1.023 MB/s. A high-speed isochronous transaction can transfer up to 1024 bytes. A high-speed isochronous endpoint that requires more than 1024 bytes per microframe can request 2 or 3 transactions per microframe, for a max- imum data throughput of 24.576 MB/s. A SuperSpeed isochronous transaction can transfer up to 1024 bytes. A SuperSpeed isochronous burst transaction con- sists of up to sixteen 1024-byte data packets in a service interval. An endpoint can request up to 3 burst transactions per service interval, for a maximum data throughput of over 393 MB/s. A high-speed endpoint that requests multiple transactions per microframe is a high-bandwidth endpoint. Recent Windows editions support high-bandwidth isochronous endpoints. High-speed and SuperSpeed isochronous endpoints don’t have to reserve bandwidth in every (micro)frame or service interval and thus can request less bandwidth than full-speed transfers. The minimum requested bandwidth is one byte every 4.096 seconds. However, any endpoint A Transfer Type for Every Purpose 85 can transfer less data than the maximum reserved bandwidth by skipping avail- able transactions or by transferring less than the maximum data per transfer. A SuperSpeed isochronous IN endpoint that has no data to transmit responds to a request for data with a zero-length Data Payload. On a high-speed bus, interrupt and isochronous transfers combined can use no more than 80% of a microframe. On a SuperSpeed bus, interrupt and isochro- nous transfers combined can use no more than 80% of a bus interval. On a full-speed bus, isochronous transfers and low- and full-speed interrupt transfers combined can use no more than 90% of a frame. The section More about Time-critical Transfers below has more about the capa- bilities of isochronous transfers. &GVGEVKPICPF*CPFNKPI'TTQTU The price for guaranteed on-time delivery of large blocks of data is no error cor- recting. Isochronous transfers are intended for uses where occasional errors are acceptable. For example, listeners may tolerate or not notice a short dropout in voice or music. In reality, under normal circumstances, a USB transfer should experience only infrequent errors due to line noise. Because isochronous trans- fers must keep to a schedule, the receiver can’t request the sender to retransmit if the receiver is busy or detects an error. A receiver that suspects errors could ask the sender to resend the entire transfer, but this approach isn’t very efficient. A device or host that doesn’t receive an expected data packet or receives a data packet with an error can define what to do. The options include using the data as is, skipping the data, or inserting a packet identical to the previous packet or other “dummy” data. &GXKEG4GURQPUKDKNKVKGU A USB 2.0 device has these responsibilities for transfers on an isochronous end- point: • For OUT transfers, accept received data in data packets. • For IN transfers, return data in data packets in response to IN tokens. A SuperSpeed device has these responsibilities for transfers on a isochronous endpoint: • For OUT transfers, accept data in Data Packets. • For IN transfers, send data in Data Packets in response to requests in ACK Transaction Packets. . only the information transferred in the data packet (USB 2.0) or Data Packet Payload (SuperSpeed), excluding PID and CRC bits. USB 2.0 and USB 3.0 require interrupt endpoints in a default interface. end- point(s). Every USB 2.0 or USB 3.0 device with isochronous endpoints must have an interface that requests no isochronous bandwidth so the host can configure the Figure 3-7. USB 2.0 isochronous. packet (USB 2.0) or Data Packet Payload (SuperSpeed), excluding PID and CRC bits. If the data doesn’t fit in a single packet, the host completes the transfer in mul- tiple transactions. Within a USB