Universal Serial Bus: Difference between revisions
m
fixed misspelling
| [unchecked revision] | [unchecked revision] |
(→Hubs) |
m (fixed misspelling) |
||
| (19 intermediate revisions by 9 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 ===▼
▲=== USB 2.0 Host Controllers ===
[[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 '''Enhanced Host Controller Interface''' ('''EHCI'''). However, even though the USB 2.0 specification requires that a USB 2.0 interface support USB 1.0 devices, this doesn't mean that the EHCI must support USB 1.0 devices, and in fact, it doesn't. Each EHCI host controller is accompanied by (usually several) UHCI and/or OHCI host controllers. When a USB 1.0 device is attached, the EHCI simply hands control over to a '''companion controller'''. Refer to figure 1 for a simple block diagram implementation of this behavior. Therefore, the system programmer must support all three standards in order to support USB 2.0.
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.
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.
* [http://www.usb.org/developers/docs/usb_30_spec_052109.zip USB 3.0 Specifications]▼
== Basic Concepts and Nomenclature ==
Line 63 ⟶ 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 590 ⟶ 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,474 ⟶ 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,047 ⟶ 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]]
| |||