USB Complete fourth- P10 doc

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 ret

Figure 3-3 A Setup Data packet initiates a SuperSpeed control write transfer A Status transaction packet initiates the Status stage.

Figure 3-4 A SuperSpeed control write transfer is identical to a control read transfer except for the direction of the Data stage.

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 transtrans-actions 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-$WU5RGGF /CZKOWO&CVC2CEMGV5K\G

Full 8, 16, 32, or 64

SuperSpeed 512

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

&GVGEVKPICPF*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

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

&GXKEG4GURQPUKDKNKVKGU

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

• For unsupported requests, return a STALL Transaction packet in the Data or Status stage

$WNM6TCPUHGTU

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-speclass-spe-cific protocol to request a quantity of data

*KIJ5RGGF&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

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.

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.

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

$WU5RGGF /CZKOWO&CVC2CEMGV5K\G Full 8, 16, 32, or 64

SuperSpeed 1024

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

&GXKEG4GURQPUKDKNKVKGU

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

+PVGTTWRV6TCPUHGTU

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