Anonymous user
Universal Serial Bus: Difference between revisions
added data toggling information, added illustrations, reorganized earlier sections
| [unchecked revision] | [unchecked revision] |
(add ping transaction protocol, fixed other minor things I noticed, and removed redundant/less-detailed information from the original wiki contents) |
(added data toggling information, added illustrations, reorganized earlier sections) |
||
Line 60:
===== Hubs =====
[[Image:LFSpeedDevToHSPort.gif|thumb|Figure 3: Low- or Full-speed device connected to a high-speed capable USB port]]▼
In a high-speed system, a high-speed hub plays a special role. Since the high-speed hub establishes a high-speed transfer rate with the host, it must isolate any full- or low-speed signaling from both the host and any attached high-speed devices.
[[Image:HSHubToHSPort.gif|thumb|Figure 4: High-speed hub connected to a high-speed capable USB port]]▼
[[Image:HSDevsToHSHubToHSPort.gif|thumb|Figure 5: High-speed devices connected to a high-speed hub which is connected to a high-speed USB port]]▼
To better understand, consider that the EHCI controller is accompanied by one or more companion controllers, as illustrated in figure 1 above. When a full- or low-speed device is attached directly to the root hub, the EHCI controller can relinquish ownership of that specific port to a companion controller as seen in figure 3. However, if a high-speed hub is connected to a port, as in Figure 4, then the EHCI controller must retain ownership of the port because it is a high-speed device. Now suppose other high-speed devices are attached to the high-speed hub in figure 4; obviously the EHCI controller retains control as in figure 5.
[[Image:LFHSDevsHSHubHSPortIncorrect.gif|thumb|Figure 6: Incorrect illustration of Low- and Full-speed devices on a high-speed bus]]▼
[[Image:LFHSDevsHSHubHSPortCorrect.gif|thumb|Figure 7: Correct illustration of split transactions allowing Low- and Full-speed devices on a high-speed bus]]▼
But what happens when a full- or low-speed device is connected to the high-speed hub in figure 5? If the EHCI controller were to relinquish ownership of the port, the high-speed devices will no longer be able to operate at high-speed, if at all, as in figure 6. Instead, the host controller and the hub support a special type of transaction called a split transaction. A '''split transaction''' involves only the host controller and a high-speed hub; it is transparent to any devices. This scheme of using split-transaction to support low- and full-speed devices on a high-speed hub is illustrated in figure 7.
<gallery perrow=5>
Image:LFSpeedDevToHSPort.gif|Figure 3: Low- or Full-speed device connected to a high-speed capable USB port
Image:HSHubToHSPort.gif|Figure 4: High-speed hub connected to a high-speed capable USB port
▲
▲
▲
</gallery>
<!--
▲[[Image:LFSpeedDevToHSPort.gif|thumb|left|Figure 3: Low- or Full-speed device connected to a high-speed capable USB port]]
▲[[Image:HSHubToHSPort.gif|thumb|Figure 4: High-speed hub connected to a high-speed capable USB port]]
[[Image:HSDevsToHSHubToHSPort.gif|thumb|none|Figure 5: High-speed devices connected to a high-speed hub which is connected to a high-speed USB port]][[Image:LFHSDevsHSHubHSPortIncorrect.gif|thumb|none|Figure 6: Incorrect illustration of Low- and Full-speed devices on a high-speed bus]][[Image:LFHSDevsHSHubHSPortCorrect.gif|thumb|none|Figure 7: Correct illustration of split transactions allowing Low- and Full-speed devices on a high-speed bus]]
-->
==== USB Interconnect ====
The '''USB interconnect''' provides a connection from the USB device(s) to the USB host. Physically, the USB interconnect is a tiered star topology. A maximum of seven tiers are allowed, and the root hub occupies the first tier. Since compound devices contain an embedded hub, a compound device cannot be attached in tier 7. Figure 8 illustrates a USB topology (taken from Figure 4-1 of the USB 2.0 specifications).
▲[[Image:USBTopology.gif|frame|none|Figure 8: USB Topology]]
==== USB Host ====
Line 253 ⟶ 260:
Frames and microframes are mostly a physical-layer detail and should not be confused with any of the previous concepts. Frames and microframes do not correspond to any packet or transaction; in fact, several transactions usually take place during one (micro)frame. The host controller issues a '''start-of-frame''' ('''SOF''') packet at the beginning of every (micro)frame. The remainder of the (micro)frame is available for the host controller to carry out transactions. A transaction may not take place if it cannot be completed in the same (micro)frame (because otherwise the next SOF packet would interrupt the transaction).
[[Image:Usbframes.gif|frame|center|Figure 10: Illustration of USB (micro)frames.]]
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 host controller may, for example, schedule the SETUP transaction for a control transfer, followed by the SETUP transaction of a separate control transfer, especially if the DATA transaction for the first control transfer would not fit in the remaining time of the particular (micro)frame.▼
▲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
[[Image:Usbtransactionreorder.gif|frame|center|Figure 11: Illustrates how a host controller may potentially reorder a bulk transfer and two control transfers on the USB.]]
==== Bus Time Rationing ====
Line 301 ⟶ 312:
The USB protocol highlights the following possible method for the host or a device to detect an error in an isochronous stream:
*
* The host controller and device can both see SOF packets on the bus. If the SOF packet is issued for a (micro)frame that is expected to carry the periodic data of an isochronous endpoint, but the data is not transmitted, then the hardware can determine that a packet was missed.
* The protocol provides CRC protection to ensure that the data has not been corrupted.
Line 366 ⟶ 377:
|-
|rowspan="4" align="center" |Data
|align="center" |<div id="DATAPIDS">DATA0</div>
|align="center" |0011b
|This packet is an even data packet.
Line 677 ⟶ 688:
During a high-speed control or bulk transfer from the host to function, when an OUT transactions causes a function's free buffer space to drop below the endpoint's maximum data payload, the function responds with a NYET handshake packet. This indicates that the host should start issuing PING packets rather than additional OUT transactions.
=== Data Toggle Synchronization ===
During a transfer, the host and function must remain synchronized. The ability to maintain synchronization means that the host or function can detect when synchronization has been lost and, in most cases, resynchronize.
Every endpoint maintains, internally (in the function's hardware), a data toggle bit, also called a data sequence bit. The host also maintains a data toggle bit for every endpoint with which it communicates. The state of the data toggle bit on the sender is indicated by which [[#DATAPIDS|DATA PID]] the sender uses.
The receiver toggles its data sequence bit when it is able to accept data and it receives an error-free data packet with the expected [[#DATAPIDS|DATA PID]]. The sender toggles its data sequence bit only upon receiving a valid ACK handshake. This data toggling scheme requires that the sender and receiver synchronize their data toggle bits at the start of a transaction.
Data toggle synchronization works differently depending on the type of transfer used:
* Control transfers initialize the endpoint's data toggle bits to 0 with a SETUP packet.
* Interrupt and Bulk endpoints initialize their data toggle bits to 0 upon any configuration event.
* Isochronous transfers do not perform a handshake and thus do not support data toggle synchronization.
* High-speed, high-bandwidth isochronous transfers do support data sequencing within a microframe.
The remainder of this section illustrates how the sending and receiving devices each manage their data toggle bits during different transmission scenarios. Black arrows signify the intended data transmission on the USB. Gray arrows signify that the intended data transmission completed without error. Red, discontinuous arrows signify that the intended data was corrupted during transmission or entirely failed to transmit.
==== Successful transmissions ====
[[Image:SuccessfulDataTx.gif|thumb|right|Figure 12: Illustration of how the sender and receiver manage their data toggle bits during a successful data transfer]]
Figure 12 illustrates a successful data transfer. Both devices have data toggle bits set to 0 at the beginning of transfer i. Accordingly, the sending device issues a DATA0 PID followed by the data packet. The receiving device successful reads the DATA0 PID as well as the data packet. Since the receiver's data toggle bit matches the DATA0 PID and there were no errors in transmitting the remaining data, the receiver toggles its data toggle bit to 1 and issues an ACK handshake response. The sender receives the ACK handshake without error, and thus toggles its data toggle bit to 1.
Supposing that the next transfer occurs without error as well, the only difference is that the DATA1 PID is used rather than DATA0, and the sending and receiving devices toggle their data toggle bits from 1 to 0 in the same stages that the same bit toggled to a 1 in the previous transfer.
[[Image:FailedDataTx.gif|thumb|left|Figure 13: Illustration of how the sender and receiver manage their data toggle bits during a failed or corrupt data transfer]]
==== Failed or corrupted data transmissions ====
Figure 13 illustrates a failed or corrupted data transmission. Both devices have data toggle bits set to 0 at the beginning of transfer i. Accordingly, the sending device issues a DATA0 PID followed by the data packet. The receiving device either does not see the data packet, or reads a corrupted data packet. The receiever maintains its data toggle bit and issues a NAK handshake. The sender successfully sees the NAK handshake and thus does not toggle its data toggle bit.
At the beginning of the next transfer, both the sending and receiving device have data toggle bits still set to 0. Supposing this transfer completes successfully, it is carried as as described above, under [[#Successful_transmissions|successful transmissions]].
==== Failed or corrupted ACK handshake ====
[[Image:FailedACKTx.gif|thumb|right|Figure 14: Illustration of how the sender and receiver manage their data toggle bits during a failed or corrupt ACK response]]
Figure 14 illustrates a failed or corrupted ACK handshake. Both devices have data toggle bits set to 0 at the beginning of transfer i. Accordingly, the sending device issues a DATA0 PID followed by the data packet. The receiving device successfully reads the DATA0 PID as well as the data packet. Since the receiver's data toggle bit matches the DATA0 PID and there were no errors in transmitting the remaining data, the receiver toggles its data toggle bit to 1 and issues an ACK handshake response. The sender does not receive, or receives a corrupted ACK response, and thus discards the packet without modifying it's data toggle bit.
At this point, the sending device's data toggle bit is still 0, and the receiving device's data toggle bit has been set to 1. The sender, having not seen a valid ACK response for transfer i, reattempts transfer i. With a data toggle bit of 0, the sender issues a DATA0 PID followed by the data packet. The receiving device successfully reads the DATA0 PID as well as the data packet. Since the receiver's data toggle bit does not match the DATA0 PID, the receiver maintains it's data toggle bit value of 1 and issues an ACK handshake response. The sender receives the ACK response without error, and thus toggles its data toggle bit to 1.
Supposing that the next transfer occurs without error, it begins with both device's data toggle bits set to 1 and ends with them toggling to 0 at the appropriate stage of the transfer.
== TODO ==
Currently the above article is missing the following topics:
* USB Framework
** Device States
| |||