Jan Axelson, USB Complete
Подождите немного. Документ загружается.
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.
*KIJ5RGGF&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.
&CVC5K\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.
$WU5RGGF /CZKOWO
&CVC2CEMGV5K\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.
&GVGEVKPICPF*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.
&GXKEG4GURQPUKDKNKVKGU
Device responsibilities for interrupt endpoints are the same as for bulk end-
points.
+UQEJTQPQWU6TCPUHGTU
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
*KIJ5RGGF&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.
&CVC5K\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-
$WU5RGGF /CZKOWO
&CVC2CEMGV5K\G
/CZKOWO0WODGTQH
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.
&GVGEVKPICPF*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.
&GXKEG4GURQPUKDKNKVKGU
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.