Anonymous user
Universal Serial Bus: Difference between revisions
Jump to navigation
Jump to search
add ping transaction protocol, fixed other minor things I noticed, and removed redundant/less-detailed information from the original wiki contents
| [unchecked revision] | [unchecked revision] |
(added handshake info) |
(add ping transaction protocol, fixed other minor things I noticed, and removed redundant/less-detailed information from the original wiki contents) |
||
Line 397:
|align="center" |NYET
|align="center" |0110b
|The receiver has not yet responded, or the host should begin sending PING packets.
|-
|rowspan="5" align="center" |Special
Line 550:
|-
|align="center" style="border-right: 1px solid #000000; border-top: 1px solid #000000;" |Function
|align="center" style="border-top: 1px solid #000000;" |
|}
===== NYET =====
Line 667:
A function must always accept data in a SETUP transaction, and must never issue a STALL or NAK handshake in response. All non-control endpoints must simply ignore any SETUP transaction addressed to that endpoint. This allows SETUP transactions to function as a (re)synchronization mechanism between the host and a function's control endpoint.
Consider a USB mass storage device. During a transfer from the host to the function, the function's buffer fills up with data that is pending being committed to the physical media. When the function's buffer is full, the function cannot accept new data until some of the buffer is committed, so if the host continues sending OUT transactions, the function must [[#NAK|NAK]] them.
The problem with this OUT/NAK model is that a function must wait for the handshake stage of the OUT transaction before responding with a NAK. Since the handshake stage occurs after the data stage, this can waste a significant amount of bandwidth. Low- and full-speed buses suffer from this problem, but the USB 2.0 specification introduced the PING transaction protocol for high-speed buses.
The PING transaction protocol is very straightforward. Rather than an OUT transaction, the host issues a PING transaction to the function when the host wishes to send data. The function responds with either NAK to indicate that it is not ready to receive data (specifically, the function's buffer cannot accommodate the endpoint's maximum data payload amount of data), or ACK to indicate that the host may start sending data.
The USB 2.0 framework allows endpoints to specify an interval, in terms of microframes, which is the amount of micorframes that the host should wait before issuing another PING packet to the endpoint. However, the host is not required to wait this interval before issuing the next PING packet.
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.
== TODO ==
Line 679 ⟶ 689:
== Original USB Wiki Content ==
Until the above sections are complete, the original content of this wiki entry that has not been covered in more depth is placed here.
=== USB keyboards/mice ===
Line 694 ⟶ 704:
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 [[:Category:Buses|bus]] and send packets to the identified devices. Documentation about the [http://www.o3one.org/hwdocs/usb/hcir1_0a.pdf Open Host Controller Interface], [http://developer.intel.com/design/USB/UHCI11D.htm Universal Host Controller Interface] and [http://www.intel.com/technology/usb/download/ehci-r10.pdf Extended Host Controller Interface] are available freely. Your USB-aware chipset should support one of these three.
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.
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.
Line 736 ⟶ 742:
Inquiry, Get_Capacity and Read_10 or Write_10
▲==== Transaction ====
==== Configuration ====
Line 762 ⟶ 747:
A list of structures defining USB descriptors is available in [http://clicker.cvs.sourceforge.net/*checkout*/clicker/c32-lxsdk/kernel/src/mods/io/include/usbdescr.h usbdescr.h] from Clicker's CVS (LGPL)
===== Reading descriptors =====
| |||