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