Universal Serial Bus: Difference between revisions
m
fixed misspelling
| [unchecked revision] | [unchecked revision] |
(finished framework section) |
m (fixed misspelling) |
||
| (42 intermediate revisions by 16 users not shown) | |||
Line 1:
The Universal Serial Bus was first introduced in 1994 with the intention of replacing various specialized interfaces, and to simplify the configuration of communication devices. The communication industry did not develop as the USB-IF foresaw, but the various transfer modes that USB introduced allowed it to become one of the most popular standards in use today. Virtually every modern computer supports USB.
== 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, which define the actual hardware OSes interface with. Furthermore, the USB specification defines a plethora of terms, some used interchangeably and seemingly lazily; as a lengthy technical document, it is neither easy nor practical to flip back and forth to clarify a confusing term or concept.
=== What this text covers ===
The truth is that a software developer doesn't need to read the entire USB 2.0 specification; there are sections specific to hardware developers, for example. The information presented here attempts to summarize chapters 4, 5, and 8 through 10.
Chapter 11 is specific to hubs and is also essential for a full USB 2.0 implementation, however it is almost as long as chapters 4, 5, 8, 9, and 10 combined, and could be regarded as the documentation for a specific (albeit special) class of USB devices. Chapter 11 is covered thusly in its own wiki entry, [[USB Hubs]]. Even so, some concepts which pertain to USB hubs are briefly discussed where relevant in this article.
Ideally, the text here will establish familiarity with the terms and concepts that a hobby OS developer needs to begin implementing USB support and, if necessary, easily parse the USB specification without becoming intimidated by the amount of information. At the very least, the system programmer should keep a copy of the USB 2.0 specification for reference while working with USB-related hardware.
Fortunately, all of the necessary documentation is available for free (see [http://wiki.osdev.org/USB#Links Links]).
=== What this text does not cover ===
Please note that USB, unlike other standards like [[VGA]] or [[PCI]], is agnostic of the hardware interface to the system bus (and, by extension, to the operating system). Such an interface is provided by one or more [[#Host_Controllers|USB host controllers]] and is defined by the appropriate documentation. Therefore, one should not expect this text to discuss specifics or code samples (e.g., as one finds in the wiki entries about [[VGA]] or [[PCI]]) detailing how the operating system initiates and maintains communication with USB devices. Although such information may be found on wiki entries discussing a particular [[#Host_Controller_Driver|Host Controller Driver]], those wiki entries assume an understanding of the concepts and terms discussed here.
== Host Controllers ==
Line 5 ⟶ 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 '''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.
== Basic Concepts and Nomenclature ==
Line 52 ⟶ 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 65 ⟶ 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 73 ⟶ 78:
</gallery>
[[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 107 ⟶ 108:
Besides the two required endpoints, functions may implement additional endpoints as necessary, with the following limitations:
* Low-speed functions may implement up to two additional endpoints.
* Full- and high-speed devices may implement up to 15 additional input endpoints and 15 additional output endpoints.
==== Endpoint Zero ====
Line 267 ⟶ 268:
==== Bus Time Rationing ====
There are separate rules for the allocation of frames on a full-
For full- or low- speed buses:
Line 309 ⟶ 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 513 ⟶ 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 580 ⟶ 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,464 ⟶ 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 1,937 ⟶ 1,938:
==== STRING ====
Devices may optionally support STRING descriptors. If a device does not support STRING descriptors, any field which references the index of a STRING descriptor must be reset to zero. STRING descriptors use unicode encodings and may support multiple languages. The host requests a STRING descriptor with the [[#GET_DESCRIPTOR|GET_DECRIPTOR]] request and must pass the 16-bit LANGID (as defined by the USB-IF) of the desired language in the ''wIndex'' field. The list of currently accepted LANGIDs is located
String index 0 for all languages returns a STRING descriptor that contains an array of all the two-byte LANGID codes that the device supports.
Line 2,009 ⟶ 2,010:
|}
== Typical organization of system software ==
This section discusses how system software is typically, reasonably organized. This section also serves as an index to the wiki entries which provide, or will provide, farther information and perhaps programming examples.
==
As with any device driver, a USB device driver abstracts away from the low-level details on just how a specific device is being accessed, and provides the rest of the system and applications with a common interface (e.g, a file manager shouldn't have to know whether it is dealing with an external versus internal hard drive).
USB device drivers typically implement a certain class of device as per the appropriate specifications. Such classes of USB devices include, but are not limited to:
* [[USB Mass Storage Class Devices]]
* [[USB Human Input Devices]]
=== USB Driver ===
Even a USB device driver need not be concerned with some of the lower-level details. For instance, it shouldn't matter to the device driver if a device is connected directly to the root hub, or if it lies behind 3 hubs. The device driver shouldn't worry about how much power the device needs from the bus. This is where the USB driver comes in.
The USB driver essentially provides the USB framework interface to device drivers. The USB driver also handles connect and disconnect events on the USB, as well as determining which device driver is needed (according to the Class, Subclass, and Protocol codes), and if that device driver even exists.
===
Although the USB Driver knows some details about the USB topography, the responsibility of hub-specific communication (including split-transactions) is often separated from the USB Driver into another module called the USB Hub Driver.
Depending on the design of the system, the USB Driver might bypass the USB Hub Driver when communicating with devices on the root hub, or the system may use the reserved address of 0 to indicate the root hub to the USB Hub Driver (it appears that Linux does this).
Details on USB Hubs will eventually be discussed in the [[USB Hubs]] wiki entry.
===
As a request for a data transfer moves from the device driver, through the USB Driver, and through the USB Hub Driver, the request gains all the information needed for the host controller to generate the appropriate transactions on the bus. However, depending on the host controller, this information needs to be formatted in a certain way and added for scheduling by the host controller.
This task if given to the host controller driver. Requests reach the host controller driver in a system-defined format, often called a USB Request Block (URB), or an I/O Request Packet (IRP).
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 ===
* [http://www.usb.org/home USB.org]
* [https://usb.org/document-library/usb-20-specification USB Universal Serial Bus Revision 2.0 Specification]
* [https://usb.org/document-library/usb-32-specification-released-september-22-2017-and-ecns Universal Serial Bus Revision 3.2 Specification]
* [http://www.usb.org/developers/wusb/wusb1_1_20100910.zip Wireless USB Specification Revision 1.1]
* [http://www.kernel.org/ The Linux kernel] (things tend to be confusing there, plus you have to be careful with educating yourself from Linux sources if your project isn't GPL'ed).
* [http://www.beyondlogic.org/usbnutshell/usb1.shtml 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.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:USB]]
[[Category:Buses]]
[[de:Universal_Serial_Bus]]
| |||