Universal Serial Bus
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.
Host Controllers
The Host Controller is the USB interface to the host computer system. In other words, the host controller is what the system software uses to communicate with USB devices.
USB 1.0 Host Controllers
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).
Specifications
- Universal Host Controller Interface (UHCI) Specifiations
- Open Host Controller Interface (OHCI) Specifications
USB 2.0 Host Controllers
In designing USB 2.0, the USB-IF insisted on a single implementation. That single implementation is Intel's Extended 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 hubs, and in more detail under Split Transactions
Specifications
USB 3.0 Host Controllers
In late 2008, the USB-IF released the USB 3.0 specifications. USB 3.0 host controllers are just starting to make their way into consumer devices since NEC introduced the world's first “SuperSpeed USB 3.0 host controller” in May, 2009, techspot reports.
Specifications
Supporting USB
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 a his/her primary language). Not only is the USB 2.0 specification long, but it's a prerequisite for the EHCI, UHCI, and OHCI specifications, all of which must be implemented for full USB 2.0 support.
The truth is that you don'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 11, but reading those sections of the specification is recommended.
On the other hand, the specifications were not written to simply take up space. The USB architecture is relatively extensive and can only be summarized so much. At the very least, the system programmer should keep a copy of the USB 2.0 specifications to reference when he/she is unsure about something. Hopefully the information here will also make the specifications easier to understand, as some terms can be confusing at first.
Fortunately, all of the necessary documentation is available or free:
Key Concepts and Nomenclature
The USB is a polled bus, meaning the host controller must initiate all transfers. Do not mistake this to mean that the system software must poll the USB. The host controller takes care of polling the bus and can be programmed to issue interrupts to the OS whenever the bus needs attention.
USB System
A USB System consists of three discrete parts: the USB device(s), the USB interconnect, and the USB host. Figure 2 illustrates a USB System.
USB Device(s)
USB devices are classified as either a hub or a function (not to be confused with a program procedure). Hubs provide additional attachment points, whereas functions provide capabilities to the system. Some devices may implement several functions and an embedded hub in one physical package. These are called compound devices.
Functions
All functions understand the USB protocol, respond to standard operations (e.g, configuration or reset), and describe capabilities to the USB host.
There are three speed classes of functions:
- 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. USB 3.0 will add a fourth transfer speed of up to 5 Gb/s, called SuperSpeed.
Hubs
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.
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.
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.
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).
USB Host
A USB system contains only one USB host. The host interfaces with the USB interconnect via a host controller. The host includes an embedded hub called the root hub which provides one or more attachment points, or ports.
USB Communication Flow
Figure 9 illustrates the concepts of USB communication flow and is taken from Figure 5-10 of the USB 2.0 Specifications.
Device Endpoints and Endpoint Numbers
Each USB device contains a collection of endpoints. Every endpoint has the following characteristics:
- Bus access frequency/latency requirement
- Bandwidth requirement
- A unique device-determined identifier called the endpoint number
- Error handling behavior requirements
- Maximum packet size the endpoint can send or receive
- The transfer type of the endpoint
- Device-determined direction of data transfer:
- Input: from the device to the host
- Output: from the host to the device
As an example, consider an “all-in-one” printer/scanner device. Such a device may implement an endpoint number for printing functionality, and a separate endpoint number for scanning functionality.
Although endpoints have a specific direction, two endpoints may have the same endpoint number but opposing data transfer directions. All functions implement two such endpoints with the endpoint number 0. Only endpoints with the endpoint number 0 may be accessed as soon as the device is powered and has received a bus reset; all other endpoints are in an undefined state until the device is configured.
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. The reasons for this limit will be clear later on.
Endpoint Zero
All USB devices implement input and output endpoints with an endpoint number of 0. These endpoints are collectively known as the default control pipe. Endpoints with an endpoint number 0 are special in that they are accessible whenever the device is attached, powered and has received a bus reset.
In the interest of backwards compatibility, all high-speed functions must support these endpoints even when connected to a hub operating at full-speed. This means that high-speed devices must be able to reset at full-speed, as well as respond successfully to standard requests at full-speed. The high-speed device is not, however, required to support its intended functionality at full-speed. This allows USB 1.0 systems to identify a USB 2.0 device and alert the user if the device cannot function properly at full-speed
Pipes
A pipe associates software on the host (specifically, a buffer on the host) with an endpoint on a device.
There are two kinds of pipe communication modes:
- Stream pipes impose no structure on the data being transferred. Stream pipes are always uni-directional in their communication flow.
- Message pipes impose some structure on the data being transfered. Message pipes are bi-directional, however data may predominantly transfer in one direction.
Pipes also have the following attributes:
- A claim on bus access and bandwidth usage
- A transfer type
- The associated endpoint's characteristics
Data flow in one pipe is independent of data flow in any other pipe. Most pipes are available after a device has been configured, however the default control pipe always exists after a USB device is powered and has received a bus reset.
Default Control Pipe
The default control pipe is a special type of message pipe that is always accessible once a device is powered and has received a bus reset. Thus, the default control pipe provides a means to identify and configure devices so that additional endpoints, if any, are made available.
The information required to completely identify a device is associated with the default control pipe; such information falls into the following categories:
- Standard information is common among all USB devices.
- Class information depends on the class of the USB device, as identified by the standard information.
- USB Vendor information is free for use by the hardware vendor.
Basics of USB Transfers
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.
USB supports four basic types of data transfer which take place via pipes. A single pipe supports only (and exactly) one transfer type for any given device configuration. That is, a function may provide a means to change the transfer type of a device-implemented endpoint number.
Briefly, the four basic transfer types are:
- Control Transfers provide lossless transmissions and are used to configure a device. Thus, all USB devices must support control transfers at least via the default control pipe.
- Bulk Data Transfers provide lossless, sequential transmissions and are typically used to transfer large amounts of data.
- Interrupt Data Transfers provide reliable, limited-latency transmissions typically needed by human input devices such as a mouse or a joystick.
- Isochronous Data Transfers, also called Streaming Real-time Transfers, negotiate a required bandwidth and latency when initializing the transfer. This transfer type is predominantly used for such applications as streaming audio. Since data-delivery rate is considered more important than data integrity for this type of transfer, it does not provide any type of error checking or correction mechanism.
Control Transfers
Control transfers support configuration/command/status type communication flow. The host initiates a control transfer with a SETUP bus transaction to the function, which establishes details of the intended data transfer such as whether the host wishes to send or receive data. Next, zero or more DATA transactions take place in the appropriate direction. Finally, a STATUS transaction from the function to the host indicates whether the transfer was successful.
Clearly, control transfers adhere to a USB-defined structure, so it should come as no surprise that control transfers may only be carried out via messages pipes.
Neither a function nor the host are guaranteed any specific latency or bandwidth for control transfers.
Maximum Data Payload Size
An endpoint used for a control transfer specifies the maximum data payload size that it can accept or transmit to the bus. The allowable maximum data payload sizes depend on the speed of the device:
- High-speed device endpoints may only select a maximum data payload size of 64 bytes.
- Full-speed device endpoints may select a maximum data payload size of 8, 16, 32, or 64 bytes.
- Low-speed device endpoints may only select a maximum data payload size of 8 bytes.
A control transfer always uses it's maximum data payload size for data payloads unless the data payload is less than the maximum data payload size. That is, if an endpoint has a maximum data payload size of 64 bytes, and a control transfer intends to transmit 100 bytes, the first data payload must contain 64 bytes and no less. The remaining 36 bytes are transferred in the second payload and need not be padded to 64 bytes. When the host receives a data payload less than the maximum data payload, the host may consider the transfer complete.
A SETUP packet is always 8 bytes and thus receivable by the endpoint of any USB device. Consequently, the host may query the appropriate descriptor from a newly-attached full-speed device during configuration in order to determine the maximum data payload size for any endpoint; the host can then adhere to that maximum for any future transmissions.
Transmission Errors
Too Much Data
When transferring from host to device, if the host sends more data than negotiated during the SETUP transaction (i.e., the device receives more data than it expects; specifically, the host does not advance to the STATUS stage when the device expects), the device endpoint halts the pipe.
When transferring from device to host, if the device sends more data than negotiated during the SETUP transaction (i.e., the host receives an extra data payload, or the final data payload is larger than it should be), the host considers it an error and aborts the transfer.
Bus Errors
In the event of a bus error or anomaly, an endpoint may receive a SETUP packet in the middle of a control transfer. In such a case, the endpoint must abort the current transfer and handle the unexpected SETUP packet. This behavior should be completely transparent to the host; the host should neither expect nor take advantage of this behavior.
Halt Conditions
A control endpoint may recover from a halt condition upon receiving a SETUP packet. If the endpoint does not recover from a SETUP packet, it may need to be recovered via a different pipe. If an endpoint with the endpoint number 0 does not recover with a SETUP packet, the host should issue a device reset.
Bulk Data Transfers
A pipe with a bulk transfer type provides:
- Access to the USB on a bandwidth-available basis
- Retry of transfers that encounter the occasional delivery failure
- Guaranteed data integrity, but no guaranteed bandwidth
The host controller gives bulk data transfers low priority; they are generally only processed when bandwidth is available, however software may not assume that a control transfer will be processed before a bulk transfer. If multiple bulk transfers are pending, the host controller may begin moving bulk transfers over the bus according to an implementation-dependent policy. The system software may vary the bus time made available for a bulk transfer to a specific endpoint.
The USB does not impose any structure on the data content of a bulk transfer; thus, bulk transfers are carried via stream pipes.
Maximum Data Payload Size
An endpoint used for a bulk data transfer specifies the maximum data payload size that it can accept or transmit to the bus. The allowable maximum data payload sizes depend on the speed of the device:
- High-sped device endpoints may only select a maximum data payload size of 512 bytes.
- Full-speed device endpoints may select a maximum data payload size of 8, 16, 32, or 64 bytes.
- Low-speed devices may not implement bulk endpoints.
Like control transfers, a bulk transfer endpoint must transmit data payloads of the maximum data payload size for that endpoint with the exception of the last data payload in a particular transfer. The last data payload need not (and should not) be padded out to the maximum data payload size.
The bulk transfer is considered complete when the endpoint has transferred exactly as much data as expected, the endpoint transfers a packet with a data payload size less than the endpoint's maximum data payload size, or the endpoint transfers a zero-length packet.
Transmission Errors
If a data payload is transferred that is larger than expected, the transfer should be aborted along with any pending bulk transfers through the same pipe.
Bulk data transfers employ data toggle bits to both detect errors and provide the necessary synchronization to recover from an error. If a halt condition is detected, any remaining bulk transfers should be retired. The halt condition is resolved by means of a separate control pipe.
Interrupt Data Transfers
Interrupt data transfers guarantee a maximum service time for any data transfer. In the even of a transmission failure, data is retransmitted at the next period. Thus, an interrupt data transfer is ideal for devices that do not send data often, but when they do, they require timely transmission as well as data integrity; most human input devices have these requirements.
Interrupt data transfers are carried out by a stream pipe and thus do not need to adhere to any USB data structure.
Maximum Data Payload Size
An endpoint used for a interrupt data transfer specifies the maximum data payload size that it can accept or transmit to the bus. The allowable maximum data payload sizes depend on the speed of the device:
- High-speed device endpoints may select a maximum data payload size of up to 1024 bytes.
- Full-speed device endpoints may select a maximum data payload size of up to 64 bytes.
- Low-speed device endpoints may select a maximum data payload size of up to 8 bytes.
Additionally, a high-speed, high-bandwidth endpoint may specify that it requires two or three transactions per microframe. High-speed, high-bandwidth endpoints, frames, and microframes will be discussed later.
Notice that the maximum data payload size for interrupt data transfers allows for more granularity than control or bulk data transfers. That is, an interrupt data transfer endpoint for a high-speed device may be any integer from 0 to 1024. The maximum data payload size for an interrupt transfer endpoint remains constant during the lifetime of the device's configuration.
Like control and bulk data transfers, an interrupt transfer endpoint must transmit data payloads of the maximum data payload size for that endpoint with the exception of the last data payload in a particular transfer. The last data payload need not (and should not) be padded out to the maximum data payload size.
The interrupt transfer is considered complete when the endpoint has transferred exactly as much data as expected, the endpoint transfers a packet with a data payload size less than the endpoint's maximum data payload size, or the endpoint transfers a zero-length packet.
Transmission Errors
If a data payload is transferred that is larger than expected, the transfer should be aborted and the pipe stalls any future interrupt transfers until the error is acknowledged and corrected.
Interrupt data transfers may use one of two data toggle bit schemes to ensure successful data transmission. Devices that require higher through-put may choose to toggle every transmission rather than perform a handshake with the host. This method is more susceptible to errors than the alternative method of toggling bits upon successful transaction (after a handshake).
If a halt condition is detected, any pending interrupt transfers should be retired. The halt condition is resolved via a separate control pipe.
Isochronous Data Transfers
Isochronous data transfers are similar to interrupt transfers in that they guarantee a maximum service time for any transfer, but isochronous data transfers do not ensure data integrity. When data is ready to be transmitted to or from an isochronous endpoint, the data is always transferred at a constant rate.
The data being transmitted via an isochronous pipe need not have any specific structure, therefore isochronous pipes are stream pipes.
Maximum Data Payload Size
An endpoint used for a isochronous data transfer specifies the maximum data payload size that it can accept or transmit to the bus. The allowable maximum data payload sizes depend on the speed of the device:
- High-speed device endpoints may select a maximum data payload size of up to 1024 bytes.
- Full-speed device endpoints may select a maximum data payload size of up to 1023 bytes.
- Low-speed devices may not implement isochronous endpoints.
Like interrupt endpoints, isochronous endpoints may specify a maximum data payload size with byte granularity. Also like interrupt endpoints, high-speed, high-bandwidth isochronous endpoints may specify if they require two or three transactions per microframe.
Unlike any other transfer types, isochronous transfers may transmit any amount of data up to the maximum data payload size during any transaction.
Transmission Errors
Isochronous transfers are meant for devices where data transmission rate is more important than data integrity. For that reason, isochronous transfers do not allow handshakes and thus cannot stall. It is still important that the agent of an isochronous transfer know if an error occurred, and possibly how much data was lost. The USB protocol provides several mechanisms for detecting data transmission errors in an isochronous transfer, these mechanisms will be discussed later. Determining the amount of data lost is implementation-dependent. It is up to the software on the host or firmware on the function to implement any sort of data corruption detection/correction.
TODO
Currently the above article is missing the following topics:
- High-speed, high-bandwidth endpoints
- Split transactions
- Frames and Microframes
- More detailed isochronous transfer information
- Basic USB Protocol Information
- Data Toggling
- Error Detection/Recovery
- Device States
- Standard requests and descriptors
- Typical organization of system software
- Hubs
Original USB Wiki Content
Until the above sections are complete, the original content of this wiki entry is placed here.
USB keyboards/mice
Keyboards and mice are what the USB standard calls HID (Human Interface Device) class devices, and follow a special superset of the USB standard. Once you have a driver for a HID device, all USB HID devices will work with it, including mice, keyboards, joysticks, game controllers, and so forth. The HID standard is built on top of lower-level USB API's to send and receive data packets across the wire, but provides a translation layer that interprets the USB data so that the HID layer could conceivably be implemented on top of other protocols (Like PS/2 or serial).
For early stages, you can probably ignore the fact that those devices are USB. Virtually every chipsets will offer a good old PS/2 emulation of the USB human interface devices, so you can use I/O port 0x60 like the rest of us ...
Booting off of a USB flash disk
If the BIOS supports it is it as simple as selecting USB-FDD in the boot order and putting a simple bootloader (grub might do, I rolled my own) into the first 512 bytes of the device. The BIOS will handle all the fancy PCI / USB stuff via int 0x13. Note that there is no need for any specific filesystem or partitions (which means you can just "dd" a 2.2 linux kernel (which used to contain a simple floppy loader) to /dev/sda and it will easily come up).
Adding USB support
As a first step, you'll need to provide a driver for the USB Host Controller, which appears in most cases as a PCI device and will allow you to enumerate devices on the USB bus and send packets to the identified devices. Documentation about the Open Host Controller Interface, Universal Host Controller Interface and Extended Host Controller Interface are available freely. Your USB-aware chipset should support one of these three.
Some computer may have support for more than one of these standards (there are computer with UHCI or OHCI for USB 1.1 and EHCI for high-speed USB 2.0 using the same USB ports)
Once you know what devices are present, you'll have to identify a device-specific driver that will match that hardware. For some devices (webcams, scanners, etc), this may require a vendor-specific driver while other devices (USB keychains, HID etc) have to adhere to _class_ standards. This means that one can write a generic USB storage driver that will work with all possible keychains, embedded mp3 players, flash card readers, etc.
USB uses a tree topology, with non-leaf devices in the tree providing _hub_ class services. The tree can be up to 16 levels deep, with each hub theoretically providing up to 16 devices. The "root" of the tree is not considered a hub for some reason. Before you can start talking to devices on the USB, you will want to be able to enumerate all devices. Fortunately, the USB standard requires that all devices, including hubs, are self-describing.
Don't forget that USB devices are hot-pluggable, that is they can be added and removed at any time while the system is running.
Brief Sequence of Operation
Note: This is taken from this thread and may be inaccurate. It needs adding to at any rate.
Setup
- 1) Find Host Controller Type, Info and IO address using the PCI bus
- 2) Reset Host
- 3) Reset Port
- 4) Check Port status to detect for device insertion
- 5) Enable Port.
Device Interaction
- 1) Get Device Descriptor of device
- 2) Get Config Descriptor of device
- 3) Set Address of device
- 4) Set Configuration of device
Sending Commands
Sending commands is protocol specific, this is dependant on the Device Type (OHCI, UHCI and EHCI - UHCI being the easiest).
The command is send in a similar manner to the Device Interaction section:
- 1) Setup Queue Heads linked list
- 2) Setup Transfer Descriptors linked list
- 3) Populate both lists with valid data
- 4) Inform USB Host Controller to start command transaction
For Mass Storage Devices you must send specific commands using the CBW and CBS structures. You will also have to implement the following SCSI commands:
Inquiry, Get_Capacity and Read_10 or Write_10
Functioning
USB looks much more like a network protocol than like RS232 (good old serial cables). Data transmissions follow formatted packets rather than being made of plain characters. However, unlike network protocols like Ethernet, Token Ring, etc. all communications are directed by the host (i.e. your computer), and even 'interrupts' are actually polled by the host.
More information about this section can be found on Usb In A Nutshell (ch. 3)
Packets
These are the smallest formatted things that may transfer on the USB cable. Each USB packet at least have a SYNC header and a EOP trailer that carry no information but help in identifying packets boundaries. Each USB must also have a PID field (Packet IDentifier) that tells the role of the packet in a transfer or a transaction.
Transaction
A transaction is a "single sentence" between the host and a device. Transactions may be used to send/read data from the device, initiate transfers, set up parameters, get information, etc. Each transaction is typically made of 3 packets:
- a token packet that always comes from the host and carries the address of the device/endpoint concerned in the transaction. USB defines 4 types of tokens: SETUP (initiates a control transaction), IN (initiates a device->host data transaction) and OUT (initiates a host->device data transaction). Tokens are typically have a small fixed size.
- a data packet which carries the transaction payload. Depending on the USB version, transfer speed and type of data packet used (DATA0, DATA1, DATA2 or MDATA), the maximum payload may be 8, 64 or 1024.
- a handshake packet which informs the data emitter of the reception status. Handshake may be ACK (data received correctly), NAK (unable to receive/emit data right now, or no data to send) or STALL (device state invalid, host intervention required)
Transfers
Transactions are used to build more complex protocols like control transfer, interrupt transfer (single small sized status poll), isochronous transfer (periodic non-acknowledged packet transmission, like a sample to play on speakers) and bulk transfer (non-predictable large-sized transfers like a page to print)
More on USB transfers can be found on USB in a nutshell, ch 4
Configuration
The configuration part of the USB standard occurs through the notion of descriptors. Descriptors are blocks of information retrieved through the host controller which defines things like vendor/product identifiers for each device and class/subclass/protocol codes for each device's interface. Based on these informations, the Operating System can assign the proper driver to each device/interface.
A list of structures defining USB descriptors is available in usbdescr.h from Clicker's CVS (LGPL)
Endpoints
Configuration communications are performed on endpoint 0. The USB device will usually define more endpoints used as communication channels between the device and the host, link those endpoints to interfaces which can be assigned a class, subclass and protocol codes (identifying what the device is able to do). For instance a digital camera could offer a couple of endpoints to implement the USBstorage interface (for the camera's memory card) and other endpoints for a webcam interface.
Reading descriptors
The host has to explicitly request descriptors from the device before it manipulates them. This is achieved by a setup transfer using a GET_DESCRIPTOR as the host->device data and receiving the descriptor as the data from the host. The whole transfer will look like
- command transaction:
Setup_TOKEN(addr=device, endpoint=0) : host -> device
DATA[ RequestType=0x80, Request=0x06, value=DESCR_TYPE|DESCR_SELECTOR,
index=0, length=wished_length] : h->d, 8 bytes
ACK : host <- device
- response transaction:
IN_TOKEN(addr=device, endpoint=0) : host -> device DATA(the_descriptor) : host <- device (as much bytes as requested) ACK : host -> device
- confirm transaction:
OUT_TOKEN(addr=device, endpoint=0) : host -> device DATA() : host -> device (empty) ACK : host <- device
The DATA packet in the command transaction is called the "Setup Packet" (according to Beyond Logic), and carries almost all of the 'interesting' stuff:
- the RequestType of 0x80 (DeviceToHost=0x80| StandardRequest=0| DeviceTargetted=0)
- the Request (command) 0x06 for "GET_DESCRIPTOR"
- the value (encoding unknown atm)
See Also
Links
- USB.org
- The USB 2.0 Specification. Here you can download the official Universal Serial Bus Revision 2.0 specification, which defines the hardware and software. This is by far the best place to start, although not a light reading.
- information about the HID standard.
- 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).
- In Intel chipsets manuals.
- 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 ...
- any link to a description of USBstorage, USBprinter, HID, USB vendor list, etc. is of course welcome ;)
Forum Topics
- USB stick - discusses the feasability of booting from an USB memory stick
- USB driver - suggests a few startup links about USB
- support USB keyboard explained by Schol-R-Lea
- Collecting links about USB - PypeClicker and Df's collection of links about USB