Universal Serial Bus: Difference between revisions

[[Image:USBDataFlow.gif|frame|right|Figure 9: Illustration of USB Communication Flow]]

It is important to realize that the host controller may rearrange transactions to make better use of the available bandwidth. Of course, two transactions through the same pipe must occur in the correct order, but the transactions of two separate transfers may be reordered at the host controller's discretion. Consider a pending bulk transfer and two pending control transfers. The host could potentially reorder the transfers on the bus as in Figure 11.

=== USB Transfers Revisited ===

A lot of information has been introduced since [[#Basics_of_USB_Transfers|Basics of USB Transfers]], and it is very easy to get lost in the details. With even a decent understanding of the four types of USB transfers, it is often difficult to extrapolate from the intricacies of the USB protocol to an understanding of just how everything fits together. For these reasons, this section intends to clarify some potentially confusing concepts both explicitly and implicitly by revisiting the four transfer types in context of all the information covered since first discussing them.

An apprehensive reader may have noticed that some terms like SETUP and DATA are used both in referring to [[#Packet_Identifier_Field|packet identifiers]], and in referring to types of transactions. This wiki entry may very well be the first and only source of USB information that takes a moment to specifically differentiate between the two.

Under [[#Basics_of_USB_Transfers|Basics of USB Transfers]], USB transactions were mentioned only briefly as has been reproduced below:

Most USB transactions consist of three packets:

* A '''token packet''' indicates the type and direction of the transaction, the device address, and an

endpoint number.

* Depending on the direction of the transaction, either the host or the function sends a '''data packet'''

(which may simply indicate that there is no data to send).

* The receiving device responds with a '''handshake packet''' to indicate if the transfer was successful.

Then, under [[#Packets|Packets]], a packet was described as "the atomic unit of data transfer."

If a packet is an atom, then a transaction would be a molecule. That is, a transaction is made up of several packets in a specific order, and the packets which make up a transaction cannot be reordered or separated and still yield the same transaction. Transactions are normally named after their token packet (or their "special" packet, in the case of PING or SPLIT because these special packets play the same role as token packets), with the exception that IN or OUT transactions are often referred to, collectively, as DATA transactions. In examples, transactions that contain a data stage often indicate the type of DATA PID used by either appending 0, 1, 2, or M to the name, or adding it in parenthesis (e.g, SETUP(0) or SETUP0, OUT1 or OUT(1)).

[[Image:SETUPTransaction.gif|frame|center|Figure 15: Illustrates a SETUP transaction, which consists of a SETUP packet, a DATA0 packet, and a handshake packet (in this case, an ACK handshake).]]

An example of a single SETUP transaction is depicted in figure 15. This transaction contains the typical three packets. The token packet has a SETUP PID, the data packet has a DATA0 PID (recall that a SETUP packet initializes both the function's and the host's data toggle bits to 0), and the handshake response has an ACK PID.

Transfers are made up of transactions. Transactions may not be reordered within a transfer but, as discussed in [[#Frames_and_Microframes|Frames and Microframes]], the transactions of a particular transfer may or may not be sent over the bus in a continuous fashion. The rest of this section looks at the transactions involved in the four transfer types.

==== Control Transfers ====

Control transfers are the only transfers that use the SETUP transaction. Control transfers take place in up to three stages:

* The SETUP stage consists simply of a SETUP transaction

* The DATA stage is optional. If used, it may contain either one or more IN transactions, or one or more OUT transactions. The first of these IN or OUT transactions uses the DATA1 PID. The second, if present, uses the DATA0 PID, the third DATA1, and so on.

* The STATUS stage consists of a single IN or a single OUT transaction, which must use the DATA1 PID. If the DATA stage is present, then the STATUS stage uses the opposite type of transaction as the DATA stage (i.e, if the DATA stage consists of one or more OUT transactions, the STATUS stage consists of a single IN transaction, and vice versa). When the DATA stage is omitted, the STATUS stage uses a single IN transaction.

Figure 16 is taken from Figure 8-37 of the USB 2.0 specification and illustrates the transaction order, data sequence bit value, and DATA PID type for control read and write sequences.

[[Image:ControlTx.gif|frame|center|Figure 16: Control read and write sequences]]

==== Bulk and Interrupt Transfers ====

In the context of the USB protocol, the only difference between bulk and interrupt transfers is that bulk transfers, when operating at high-speed, support the [[#PING_Transaction_Protocol|PING Transaction Protocol]]. Note that in a general context, these two transfer types are also different in that they are scheduled differently by the host (refer to [[#Bus_Time_Rationing|Bus Time Rationing]]).

All bulk and interrupt endpoints transfer in one direction. The data toggle bits for these endpoints are initialized to zero after any configuration event. Figure 17 is taken from Figure 8-35 of the USB 2.0 specification and illustrates the bulk and interrupt transactions for both IN and OUT endpoints. Note that, even though the figure only mentions bulk reads and bulk writes, the USB 2.0 specification references the same figure from section 8.5.4, on Interrupt Transactions.

[[Image:BulkInterruptTx.gif|frame|center|Figure 17: Bulk and interrupt transactions]]

==== Isochronous Transfers ====

Isochronous transfers are the only type of transfers whose transactions do not have a handshake phase. Isochronous transfers should only use DATA0 PIDs, however the host controller must support DATA1 PIDs as well, even though isochronous transfers do not use a data synchronization bit mechanism.

==== High-Speed, High-Bandwidth Isochronous Transfers ====

High-speed, high-bandwidth isochronous transfers are a special case of isochronous transfers, where up to 3 transactions may occur in one microframe. As a specific type of isochronous transfer, high-speed, high-bandwidth isochronous transfers omit the handshake phase of their transactions. Since up to 3 transactions may occur in one microframe, high-speed, high-bandwidth isochronous transfers, it is necessary to use a data sequencing mechanism like the other transfer types.

USB 2.0 does implement a data sequencing mechanism for high-speed, high-bandwidth isochronous transfers, but it works a little differently than as in other transfer types. In fact, data sequencing works differently depending on whether an endpoint is an IN, or an OUT high-speed, high-bandwidth isochronous endpoint.

For IN high-speed, high-bandwidth isochronous endpoints, the data sequencing is depicted in figure 18, which has been taken from figure 5-11 of the USB 2.0 specifications. The last transaction in a microframe always uses the DATA0 PID. The second-to-last transaction in a microframe uses the DATA1 PID, and the third-to-last transaction in a microframe always uses the DATA2 PID.

[[Image:HSHBIsoIN.gif|frame|center|Figure 18: Data Phase Sequence for Isochronous IN High Bandwidth Endpoints]]

For OUT high-speed, high-bandwidth isochronous endpoints, the data sequencing is depicted in figure 19, which has been taken from figure 5-12 of the USB 2.0 specifications. All transactions but the last transaction use the MDATA PID. The last transaction uses either the DATA0, DATA1, or DATA2 PID, depending on how many transactions were intended to take place during the microframe. If one transaction was meant to take place, it is also the last transaction and uses a DATA0 PID. If two transactions were meant to take place, the last transaction uses a DATA1 PID. If three transactions were meant to take place, the last transaction uses a DATA2 PID.

[[Image:HSHBIsoOUT.gif|frame|center|Figure 19: Data Phase Sequence for Isochronous OUT High Bandwidth Endpoints]]