Universal Serial Bus: Difference between revisions
m
fixed misspelling
[unchecked revision] | [unchecked revision] |
(Add link to EHCI 1.1 Addendum) |
m (fixed misspelling) |
||
(34 intermediate revisions by 13 users not shown) | |||
Line 2:
== Introduction ==
Despite how attractive USB support is, the 650-page USB 2.0 specification manages to deter even some of the most driven hobbyists (especially if English isn't their primary language). Not only is the USB 2.0 specification long, but it's a prerequisite for the [[XHCI]], [[EHCI]], [[UHCI]], and [[OHCI]] specifications,
=== What this text covers ===
Line 20:
=== USB 1.0 Host Controllers ===
{{Main|Universal Host Controller Interface}}
{{Main|Open Host Controller Interface}}
Intel brought USB 1.0 to the market with its '''Universal Host Controller Interface''' ('''UHCI'''), while Compaq, Microsoft, and National Semiconductors did the same with their '''Open Host Controller Interface''' ('''OHCI'''). Naturally, the two interfaces are incompatible, and to make things worse, VIA Technologies licensed Intel's UHCI standard, thereby ensuring that both standards survived. Typically, an on-board chip set will contain a UHCI implementation, whereas a peripheral card typically implements the OHCI standard (but this is by no means a guarantee).
=== USB 2.0 Host Controllers ===
{{Main|Enhanced Host Controller Interface}}
[[Image:PortRoutingBlockDiagram.gif|frame|Figure 1: Block Diagram of Port Routing Behavior]]
In designing USB 2.0, the USB-IF insisted on a single implementation. That single implementation is Intel's '''
The EHCI host controller only handles USB 1.0 devices if they are attached indirectly through a USB 2.0 hub. The specifics of handling USB 1.0 devices attached to a USB 2.0 hub are briefly discussed and illustrated in the [[#Hubs|hubs]] section, and in more detail in the wiki entry for [[USB Hubs]]. Note that some newer chipsets like the Intel 5-series chipsets do not have companion controllers at all and instead have internal "rate matching" hubs that all USB devices go through.
=== USB 3.0 Host Controllers ===
{{Main|eXtensible Host Controller Interface}}
Like its predecessor USB 2.0, USB 3.0 has only one host controller specification: Intel's '''eXtensible Host Controller Interface'''. Unlike its predecessor EHCI, however, xHCI controllers can and do interface with USB 1.0 and 2.0 devices without the use of companion controllers. Even on early hardware where there was both an EHCI and xHCI controller included (so that OSes which did not yet support xHCI could still use at least some USB devices), ports attached to the EHCI controller could generally be "re-routed" to the xHCI controller, and the EHCI controller disabled entirely.
* [http://www.usb.org/developers/docs/usb_30_spec_052109.zip USB 3.0 Specifications]▼
Also unlike its predecessors, xHCI was designed with some degree of ''forwards compatibility'', so that revisions to the USB specification can be made without designing a new host controller interface (for instance, USB 3.1 and 3.2 add new speeds, with only minor updates to the specification to match them.) Unfortunately, this means that xHCI bears only a passing resemblance to the controllers that came before it, and make it challenging to write drivers for.
== Basic Concepts and Nomenclature ==
Line 54 ⟶ 53:
All functions understand the USB protocol, respond to standard operations (e.g, configuration or reset), and describe capabilities to the USB host.
There are
* '''Super-speed''' functions operate at up to 5 Gb/s.
* '''High-speed''' functions operate at up to 480 Mb/s.
* '''Full-speed''' functions operate at up to 12 Mb/s.
* '''Low-speed''' functions operate at up to 1.5 Mb/s.
The original USB specification defined low- and full-speed devices, while USB 2.0 added high-speed devices
===== Hubs =====
Line 67:
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.
Note that some newer chipsets like the Intel 5-series chipsets do not have companion controllers at all and instead have internal "rate matching" hubs that all USB devices go through.
<gallery perrow=5>
Image:LFSpeedDevToHSPort.gif|Figure 3: Low- or Full-speed device connected to a high-speed capable USB port
Line 76 ⟶ 79:
[[Image:USBTopology.gif|thumb|right|Figure 8: USB Topology]]
==== 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).
Line 306 ⟶ 310:
==== Handling Errors ====
Handshakes are not performed for isochronous transactions, therewith eliminating the bandwidth overhead of
The USB protocol highlights the following possible method for the host or a device to detect an error in an isochronous stream:
Line 510 ⟶ 514:
An ACK handshake is issued to communicate that a data packet was successfully received without any bit stuffing or CRC errors over the data field, and the PID field was not corrupted.
ACK packets may be issued when the receiver's sequence bit matches the sequence bit of the received data packet (and the data can be accepted), but the an ACK packet may also be issued when the receiver's sequence bit does not match the sequence bit of the received data packet (and the data cannot be accepted). This may seem
===== NAK =====
Line 577 ⟶ 581:
==== Function/Host Response Circumstances ====
This section describes the functional circumstances that cause the host or a function to issue an expected response, no response, or certain handshake packet responses. The tables in this section are taken and slightly modified for clarity from the USB 2.0
===== Function Response to IN Transactions =====
Line 1,461 ⟶ 1,465:
Some descriptors contain fields which specify an index of a STRING descriptor, but it is optional for a device to support STRING descriptors. If a device does not support STRING descriptors, then all fields which reference an index of a STRING descriptor should be reset to zero. Thus, a value of zero in any field that is meant to supply an index of a STRING descriptor indicates that no such STRING descriptor is available.
If the second byte of a descriptor identifies that descriptor as one of the standard USB descriptors, but the first byte of that descriptor specifies a length less than the lengths defined in the USB 2.0
If class- or vendor-specific descriptors use the same format as standard descriptors (i.e, the two mandatory bytes at the beginning of the descriptor), then the class- or vendor-specific descriptors are interleaved within the results when the host requests a CONFIGURATION descriptor. Otherwise, the class- or vendor-specific descriptors are accessed by passing a class- or vendor-specific descriptor type in a GET_DESCRIPTOR request.
The remainder of this section serves to catalog the standard USB device descriptors and very closely mirrors section 9.6 of the USB 2.0
==== DEVICE ====
Line 2,034 ⟶ 2,038:
Additionally, host controller drivers are loaded by the PCI subsystem when a corresponding host controller is discovered during PCI enumeration. The host controller driver is thus also responsible for initializing the host controller and perhaps loading the USB Hub Driver and the USB driver. Combined, the USB driver, USB hub driver, and the host controller driver make up a USB subsystem.
== See Also ==
=== External Links ===▼
▲=== Links ===
* [http://www.usb.org/home USB.org]
* [
* [https://usb.org/document-library/usb-32-specification-released-september-22-2017-and-ecns Universal Serial Bus Revision 3.2 Specification]
* [http://www.kernel.org/ The Linux kernel] (though things tends to be confusing there, and you have to be careful with educating yourself from Linux sources if your project isn't GPL'ed).▼
▲* [http://www.usb.org/developers/
* [http://www.beyondlogic.org/usbnutshell/usb1.htm USB in a Nutshell] may also interest you. It looks like a really good tutorial giving all the required knowledge to understand any other USB documentation/source code in a couple of HTML pages ...▼
▲* [http://www.kernel.org/ The Linux kernel] (
▲* [http://www.beyondlogic.org/usbnutshell/usb1.
* [http://www.usb.org/developers/docs/USB_LANGIDs.pdf Currently accepted LANGIDs]
* [http://www.usbmadesimple.co.uk/index.html USB Made Simple]
* [https://www.fysnet.net/the_universal_serial_bus.htm USB: The Universal Serial Bus] is a book on writing device/system drivers for UHCI, OHCI, EHCI, and xHCI with various example devices and available source code.
[[Category:Buses]]
[[de:Universal_Serial_Bus]]
▲[[Category:Buses]]
|