细谈USB TYPE-C_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
细谈USB TYPE-C
阅读已结束，下载文档到电脑
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，方便使用
还剩1页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢USB 描述符详细解析，来自老外网站，比协议描述清晰 - CSDN博客
USB 描述符详细解析，来自老外网站，比协议描述清晰
来自：http://wiki.osdev.org/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.
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&,&,&,
and&specifications, all of which must be implemented for full USB 2.0 support. Furthermore, the USB specification defines a plethora
of terms, some used interchangeably
as a lengthy technical document, it is neither easy nor practical to flip back and forth to clarify a confusing term or concept.
The truth is that a software developer doesn't need to read the entire USB 2.0 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,&. 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&).
Please note that USB, unlike other standards like&&or&,
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&&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&&or&)
detailing how the operating system initiates and maintains communication with USB devices. Although such information may be found on wiki entries discussing a particular&, those wiki entries assume an understanding of the concepts and terms discussed here.
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.
Main article:&Main article:&
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).
Main article:&
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&&section,
and in more detail in the wiki entry for&. 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.
Main article:&
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,&.
Intel is currently working on a USB 3.0 host controller specification called the&eXtensible Host Controller Interface&(xHCI).
A Linux driver is available for reference&&developed by Sarah Sharp at Intel.
In 2009, NEC introduced the&, a USB 3.0 host controller compliant with Intel's draft&&specification.
On June 18th, 2010, Intel publicly released the xHCI specification.
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.
Figure 2: USB System Illustration
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 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.
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.
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- 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.
Figure 3: Low- or Full-speed device connected to a high-speed capable USB port
Figure 4: High-speed hub connected to a high-speed capable USB port
Figure 5: High-speed devices connected to a high-speed hub which is connected to a high-speed USB port
Figure 6: Incorrect illustration of Low- and Full-speed devices on a high-speed bus
Figure 7: Correct illustration of split transactions allowing Low- and Full-speed devices on a high-speed bus
Figure 8: USB Topology
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).
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,
Figure 9: Illustration of 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.
Each USB device contains a collection of endpoints. Every endpoint has the following characteristics:
Bus access frequency/latency requirementBandwidth requirementA unique device-determined identifier called the endpoint numberError handling behavior requirementsMaximum packet size the endpoint can send or receiveThe transfer type of the endpointDevice-determined direction of data transfer:
Input: from the device to the hostOutput: 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
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. This is a physical limitation of the USB protocol and is discussed under&.
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
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 usageA transfer typeThe 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 thedefault control pipe&always exists after a USB device is powered and has received a bus reset.
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
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.
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 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.
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 transaction's data payload 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 s the host can then adhere to that maximum for any future transmissions.
When transferring from host to device, if the host sends more data than negotiated during the SETUP transaction (i.e., the device receives more
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.
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
the host should neither expect nor take advantage of this behavior.
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.
A pipe with a bulk transfer type provides:
Access to the USB on a bandwidth-available basisRetry of transfers that encounter the occasional delivery failureGuaranteed data integrity, but no guaranteed bandwidth
The host controller gives bulk data tr 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 conten thus, bulk transfers are carried via stream pipes.
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
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 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 we 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.
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
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 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.
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.
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.
The topics in this section build upon the topics previously discussed. The information in this section provides some useful lower-level details about USB systems.
To ensure synchronization between the host and the functions, the USB divides bus time into fixed-length segments. For low- or full-speed buses, the USB divides the bus time into 1 millisecond units, called&frames. For a high-speed bus, the
USB divides the bus time into 125 microsecond units, called&microframes.
Note that frames and microframes do no low- and full-speed buses used frames, but in developing a high-speed bus, a shorter frame was necessary because the significantly higher signaling bit rate is more sensitive to smaller shifts in synchronization
between the host and the function.
Frames and microframes are mostly a physical-layer detail and should not be confused with any of the previous concepts. Frames and microframes do not correspond to any p in fact, several transactions usually take place during one (micro)frame.
The host controller issues a&start-of-frame&(SOF) packet at the beginning of every (micro)frame. The remainder of the (micro)frame is available for the host controller to carry out transactions. A transaction may not take
place if it cannot be completed in the same (micro)frame (because otherwise the next SOF packet would interrupt the transaction).
Figure 10: Illustration of USB (micro)frames.
It is important to realize that the host controller may rearrange transactions to make better use of the available bandwidth. Of course, two transactions through the same pipe must occur in the correct order, but the transactions of two separate transfers may
be reordered at the host controller's discretion. Consider a pending bulk transfer and two pending control transfers. The host could potentially reorder the transfers on the bus as in Figure 11.
Figure 11: Illustrates how a host controller may potentially reorder a bulk transfer and two control transfers on the USB.
There are separate rules for the allocation of frames on a full-/low-speed bus, and for the allocation of microframes on a high-speed bus.
For full- or low- speed buses:
If a control transfer requires less than 10% of a frame, the remaining bus time can be used to support bulk transfersIf there are more control transfers than reserved time, yet additional frame time that is unused by interrupt or isochronous transfers, the host controller may move additional control transfers onto the bus.No more than 90% of a frame may be allocated for periodic (isochronous and interrupt) transfers.The host must not issue more than 1 transaction in a single frame for a specific isochronous endpoint.
For a high-speed bus:
If a control transfer requires less than 20% of a microframe, the remaining bus time can be used to support bulk transfers.If there are more control transfers than reserved time, yet additional microframe time that is unused by interrupt or isochronous transfers, the host controller may move additional control transfers onto the bus.No more than 80% of a frame may be allocated for periodic (isochronous and interrupt) transfers.The host must not issue more than 1 transaction in a single microframe for a specific isochronous endpoint unless it is a high-speed, high-bandwidth endpoint.Split transaction bus access time is allocated from the 80% of the microframe guaranteed to periodic transfers.
High-speed interrupt or isochronous endpoints that require high bandwidth may specify that they support up to three transaction in a single (micro)frame. In this case, all but the last transaction in a particular (micro)frame must have a data payload of the
maximum data payload size for that endpoint.
The host controller never retries a transaction with an isochronous endpoint. If a transaction with a high-speed, high-bandwidth interrupt endpoint fails, the host controller may retry the transaction during the same (micro)frame if the maximum number of transactions
per (micro)frame has not been reached. Otherwise, the transaction is retried at the next period.
Recall that isochronous transfers occur over stream pipes, which provide one-way data transfer. On one of the pipe, called the&source, data is produced, and on the other end, called the&sink, data is delivered.
Devices that implement isochronous endpoints require that data be transmitted from source to sink at a certain rate, sometimes in large payloads (e.g, streaming audio or video). This section discusses how the USB accomplishes these requirements.
Due to application-specific sampling rates, different hardware clock designs, scheduling policies in the operating system, or even physical anomalies, the host and isochronous device could fall out of synchronization. Therefore, special consideration is required
to maintain synchronization. Isochronous endpoints specify one of three synchronization types.
Asynchronous&endpoints are incapable of synchronizing to SOF packet frequency (1ms periods for full-speed endpoints, 125 microsecond periods for high-speed endpoints). These endpoints have either:a set of one or more fixed data sampling rates,
or a continuously programmable data rate. The device must report the programmability of an asynchronous endpoint in some manner (defined by the class of the device rather than by the USB specifications); if the data rate is programmable, then it must be set
by the host during initialization of the isochronous endpoint.
Asynchronous source endpoints imply their data rate by the number of samples produced per (micro)frame. Asynchronous sink endpoints must provide explicit feedback to the source endpoint. When the source endpoint is the host, it is the responsibility of the
device driver to process the explicit feedback properly. This feedback allows the host and device to make slight adjustments to the data rate in order to compensate for any clock drift.
Synchronous&endpoints must synchronize their data transmissions to the SOF packet frequency (1ms periods for full-speed endpoints, 125 microsecond periods for high-speed endpoints). These endpoints have either a set of one or more fixed data
sampling rates, or a continuously programmable data rate. The device must report the programmability of a synchronous endpoint in some manner (defined by the class of the device rather than by the USB specifications); if the data rate is programmable, then
it must be set by the host during initialization of the isochronous endpoint.
Adaptive&endpoints can source or sink data at any rate within their specified operating range. These endpoints may have an operating range that centers around a specific data rate, it may have a finite set of data rate ranges, or it may select
between several programmable or auto-detecting data rates. The device must report the programmability of an adaptive endpoint in some manner (defined by the class of the device rather than by the USB specifications); unlike the previous synchronization types,
adaptive endpoints may adjust it's instantaneous data rate during operation.
Adaptive sink endpoints provide explicit feedback to the source like asynchronous endpoints.
Handshakes are not performed for isochronous transactions, therewith eliminating the bandwidth overhead of acknowledgment packets. Unlike other transfer types, the applications of isochronous endpoints are responsible for any error detection and handling. Although
it may be more important to continue delivering streaming data rather than retransmit a missed data packet, applications of isochronous endpoints often still need to know that an error did occur in the stream.
The USB protocol highlights the following possible method for the host or a device to detect an error in an isochronous stream:
High-speed, high-bandwidth isochronous transactions use data PID sequencing (data bit toggling), an isochronous sink can determine that a data packet was missed when it receives an invalid data PID sequence.The host controller and device can both see SOF packets on the bus. If the SOF packet is issued for a (micro)frame that is expected to carry the periodic data of an isochronous endpoint, but the data is not transmitted, then the hardware can determine that
a packet was missed.The protocol provides CRC protection to ensure that the data has not been corrupted.If an endpoint sees the token packet but does not see the associated data packet within a bus transaction timeout period, then the data packet failed to transfer.
Once an application is aware that there is an error in the stream, it is up to the application to determine the next course of action.
The atomic unit of data transfer is a packet. A packet is a bundle of organized data which typically contains three elements:
Control information (e.g. source, destination, length of data)User/Application-specific dataError detection and correction bits
The SYNC field is omitted from packet diagrams in the USB specifications, and usually in other material on USB meant for programmers. Here I will briefly describe the semantics of the SYNC field simply because USB sources often reference the SYNC field which
may confuse the reader. However, for clarity, the system programmer (and probably most USB device firmware developers as well) does not need to know about the SYNC field.
All USB packets start with a SYNC field which serves, unsurprisingly, as a synchronization mechanism between the receiver and the sender. The SYNC field consists of 6 or 30 alternating bits for low- and full-speed or high-speed buses, respectively. The last
two bits of the SYNC field are equal (and low). High-speed hubs may drop up to 4 bits of the SYNC field, so a receiving device may not see the entire field, but the final two bits are all the device needs to identify exactly where the SYNC field ends, and
useful data begins.
The&Packet Identifier&(PID) immediately follow the SYNC field. There are a total of 17 defined PIDs (included the PID of 0000b, which is reserved), therefore a PID requires 4 bits to encode. If errors on the bus alter the PID
field (changing an OUT PID to an IN PID, for example), the result could be anything from unexpected behavior to massive data loss. Due to the importance of the PID integrity, the PID field is 8 bits wide. The last 4 bits simply compliment the first four bits,
this provides a means to determine if an error on the bus has altered the PID field. The PID Field is illustrated below.
Packet Identifier Field Format
PID codes are categorized into 4 groups which share the same two least-significant bits. USB 2.0 defines the PIDs in the following table.
Description
The packet describes a host-to-function transaction.
The packet describes a function-to-host transaction.
The packet marks the start of frame and specifies the frame number.
Packet describes a SETUP transaction from the host to the function via a control pipe.
This packet is an even data packet.
This packet is an odd data packet
This packet is only used in high-speed, high-bandwidth isochronous transfers.
This packet is only used in split transactions, or high-speed, high-bandwidth isochronous transfers.
This packet acknowledges the successful receipt of a data packet.
This packet indicates that data is not ready to be transmitted yet.
This packet indicates that the endpoint has halted, or a control pipe does not support a certain request.
The receiver has not yet responded, or the host should begin sending PING packets.
This packet is a host-issued preamble for a split-transaction.
This packet is a handshake response that a split transaction error occurred. Note that this PID is identical to the PID for a PRE packet.
This packet supports split transactions between the host and a high-speed hub.
This packet is used for flow-control in high-speed control and bulk transfers.
This is a reserved PID and must not be used.
Address fields select a specific endpoint on a specific function. Naturally, two such fields are defined: an address field and an endpoint field. All devices must fully a mismatch of either field (including an endpoint field which specifies
an endpoint that have not been initialized) must be ignored.
The address field is specified for the following PIDs:
INSETUPOUTPINGSPLIT
The address field is 7 bits wide and illustrated below. Each possible value may only indicate a single function. Address zero is reserved as thedefault address&and cannot be assigned to any function. All functions must respond to the default
address upon reset and power-up until the host assigns the function a specific address. Therefore, one host controller can support up to 127 devices at one time.
Address Field
The endpoint field is specified for the following PIDs:
INSETUPOUTPING
The endpoint field is 4 bits wide and illustrated below. All functions must support at least endpoint number 0 (the default control pipe). Low-speed functions may only implement 2 additional pipes, while full- and high-speed devices are only limited by the
width of the endpoint field. In other words, the width of the endpoint field is the reason that full- and high-speed devices are limited to implementing up to 15 additional IN endpoints, and 15 additional OUT endpoints, as noted above under&.
Endpoint Field
The data field may range from zero to 1,024 bytes and must be an integral number of bytes. Data bytes are sent least-significant-bit first.
Cyclic Redundancy Checks (CRC) protect all non-PID fields and provide 100% coverage for all single- and double-bit errors. CRCs are provided for each token field as well as the data field. This provides a mechanism for the host or device to recognize and either
correct or ignore corrupted fields or, in most cases, an entire corrupted packet.
Transaction types which support flow control return handshakes to indicate:
Successful reception of dataCommand acceptance or rejectionFlow controlHalt conditions
Handshakes are always returned in the handshake phase of a transaction, but may also be returned in the data phase (in place of an expected data packet). To best understand a certain handshake response, it is useful to understand what each handshake packet
type means, as well as the conditions under which each handshake response may be issued. This section is divided thusly.
All of the handshake packet types were listed previously and briefly in&. This section discusses those packet
types in greater detail.
ACK Handshake Packet
May be issued by...
For these transactions
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 counter intuitive, but the reasoning will become clear in the sections discussing data toggling.
NAK Handshake Packet
May be issued by...
For these transactions
The NAK handshake packet is generally used for flow control to indicate that a function is temporarily unable to transmit or receive data. The host never issues a NAK handshake packet to a device.
A function returns a NAK handshake packet to the host after an OUT transaction when the function is unable to receive data (usually because the function's internal buffer is currently full). This response is not an error, but instead indicates that the host
should retry transmission later, allowing the function time to process the data currently in its buffer.
A function returns a NAK handshake packet to the host during the data phase of an IN transaction to indicate that the function does not have any data to transfer.
STALL Handshake Packet
May be issued by...
For these transactions
A function uses the STALL handshake packet to indicate that it is unable to transmit or receive data. Besides the default control pipe, all of a function's endpoints are in an undefined state after the device issues a STALL handshake packet. The host must never
issue a STALL handshake packet.
Typically, the STALL handshake indicates a functional stall. A&functional stall&occurs when thehalt feature&(which will be covered under &USB Framework&) of an endpoint is set. In this circumstance, host intervention is required via
the default control pipe to clear the&halt feature&of the halted endpoint.
Less often, the function returns a STALL handshake during a SETUP or DATA stage of a control transfer. This is called a&protocol stall&and is resolved when the host issues the next SETUP transaction.
NYET Handshake Packet
May be issued by...
For these transactions
The NYET packet may be issued by a function as part of the PING protocol.
Hubs may issue a NYET handshake packet in response to a split transaction that has not yet completed on the low-/full-speed bus.
ERR Handshake Packet
May be issued by...
For these transactions
Hubs may issue the special ERR handshake packet to report an error on a low-/full-speed bus as part of the split transaction protocol.
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
specifications, section 8.4.6. Dashes denote a &don't care.&
Token received corrupted
Function Tx endpoint halt feature
Function can transmit data
Action taken by function
Return no response
Issue STALL handshake
Issue NAK handshake
Issue data packet
Data packet corrupted
Host can accept data
Action taken by host
Handshake returned by host
Discard Data
Return no response
Discard Data
Return no response
Accept Data
Issue ACK handshake
Data packet corrupted
Receiver halt feature
Sequence bits match
Function can accept data
Action taken by function
Return no response
Issue STALL handshake
Issue ACK handshake
Issue ACK handshake
Issue NAK handshake
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&&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 microframes 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.
During a transfer, the host and function must remain synchronized. The ability to maintain synchronization means that the host or function can detect when synchronization has been lost and, in most cases, resynchronize.
Every endpoint maintains, internally (in the function's hardware), a data toggle bit, also called a data sequence bit. The host also maintains a data toggle bit for every endpoint with which it communicates. The state of the data toggle bit on the sender is
indicated by which&&the sender uses.
The receiver toggles its data sequence bit when it is able to accept data and it receives an error-free data packet with the expected&.
The sender toggles its data sequence bit only upon receiving a valid ACK handshake. This data toggling scheme requires that the sender and receiver synchronize their data toggle bits at the start of a transaction.
Data toggle synchronization works differently depending on the type of transfer used:
Control transfers initialize the endpoint's data toggle bits to 0 with a SETUP packet.Interrupt and Bulk endpoints initialize their data toggle bits to 0 upon any configuration event.Isochronous transfers do not perform a handshake and thus do not support data toggle synchronization.High-speed, high-bandwidth isochronous transfers do support data sequencing within a microframe.
The remainder of this section illustrates how the sending and receiving devices each manage their data toggle bits during different transmission scenarios. Black arrows signify the intended data transmission on the USB. Gray arrows signify that the intended
data transmission completed without error. Red, discontinuous arrows signify that the intended data was corrupted during transmission or entirely failed to transmit.
Figure 12: Illustration of how the sender and receiver manage their data toggle bits during a successful data transfer
Figure 12 illustrates a successful data transfer. Both devices have data toggle bits set to 0 at the beginning of transfer i. Accordingly, the sending device issues a DATA0 PID followed by the data packet. The receiving device successful reads the DATA0 PID
as well as the data packet. Since the receiver's data toggle bit matches the DATA0 PID and there were no errors in transmitting the remaining data, the receiver toggles its data toggle bit to 1 and issues an ACK handshake response. The sender receives the
ACK handshake without error, and thus toggles its data toggle bit to 1.
Supposing that the next transfer occurs without error as well, the only difference is that the DATA1 PID is used rather than DATA0, and the sending and receiving devices toggle their data toggle bits from 1 to 0 in the same stages that the same bit toggled
to a 1 in the previous transfer.
Figure 13: Illustration of how the sender and receiver manage their data toggle bits during a failed or corrupt data transfer
Figure 13 illustrates a failed or corrupted data transmission. Both devices have data toggle bits set to 0 at the beginning of transfer i. Accordingly, the sending device issues a DATA0 PID followed by the data packet. The receiving device either does not see
the data packet, or reads a corrupted data packet. The receiver maintains its data toggle bit and issues a NAK handshake. The sender successfully sees the NAK handshake and thus does not toggle its data toggle bit.
At the beginning of the next transfer, both the sending and receiving device have data toggle bits still set to 0. Supposing this transfer completes successfully, it is carried as as described above, under&.
Figure 14: Illustration of how the sender and receiver manage their data toggle bits during a failed or corrupt ACK response
Figure 14 illustrates a failed or corrupted ACK handshake. Both devices have data toggle bits set to 0 at the beginning of transfer i. Accordingly, the sending device issues a DATA0 PID followed by the data packet. The receiving device successfully reads the
DATA0 PID as well as the data packet. Since the receiver's data toggle bit matches the DATA0 PID and there were no errors in transmitting the remaining data, the receiver toggles its data toggle bit to 1 and issues an ACK handshake response. The sender does
not receive, or receives a corrupted ACK response, and thus discards the packet without modifying it's data toggle bit.
At this point, the sending device's data toggle bit is still 0, and the receiving device's data toggle bit has been set to 1. The sender, having not seen a valid ACK response for transfer i, reattempts transfer i. With a data toggle bit of 0, the sender issues
a DATA0 PID followed by the data packet. The receiving device successfully reads the DATA0 PID as well as the data packet. Since the receiver's data toggle bit does not match the DATA0 PID, the receiver maintains it's data toggle bit value of 1 and issues
an ACK handshake response. The sender receives the ACK response without error, and thus toggles its data toggle bit to 1.
Supposing that the next transfer occurs without error, it begins with both device's data toggle bits set to 1 and ends with them toggling to 0 at the appropriate stage of the transfer.
A lot of information has been introduced since&, and it is very easy to get lost in the details. With even
a decent understanding of the four types of USB transfers, it is often difficult to extrapolate from the intricacies of the USB protocol to an understanding of just how everything fits together. For these reasons, this section intends to clarify some potentially
confusing concepts both explicitly and implicitly by revisiting the four transfer types in context of all the information covered since first discussing them.
An apprehensive reader may have noticed that some terms like SETUP and DATA are used both in referring to&, and
in referring to types of transactions. This wiki entry may very well be the first and only source of USB information that takes a moment to specifically differentiate between the two.
Under&, USB transactions were mentioned only briefly as has been reproduced below:
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.
Then, under&, a packet was described as &the atomic unit of data transfer.&
If a packet is an atom, then a transaction would be a molecule. That is, a transaction is made up of several packets in a specific order, and the packets which make up a transaction cannot be reordered or separated and still yield the same transaction. Transactions
are normally named after their token packet (or their &special& packet, in the case of PING or SPLIT because these special packets play the same role as token packets), with the exception that IN or OUT transactions are often referred to, collectively, as
DATA transactions. In examples, transactions that contain a data stage often indicate the type of DATA PID used by either appending 0, 1, 2, or M to the name, or adding it in parenthesis (e.g, SETUP(0) or SETUP0, OUT1 or OUT(1)).
Figure 15: Illustrates a SETUP transaction, which consists of a SETUP packet, a DATA0 packet, and a handshake packet (in this case, an ACK handshake).
An example of a single SETUP transaction is depicted in figure 15. This transaction contains the typical three packets. The token packet has a SETUP PID, the data packet has a DATA0 PID (recall that a SETUP packet initializes both the function's and the host's
data toggle bits to 0), and the handshake response has an ACK PID.
Transfers are made up of transactions. Transactions may not be reordered within a transfer but, as discussed in&,
the transactions of a particular transfer may or may not be sent over the bus in a continuous fashion. The rest of this section looks at the transactions involved in the four transfer types.
Control transfers are the only transfers that use the SETUP transaction. Control transfers take place in up to three stages:
The SETUP stage consists simply of a SETUP transactionThe DATA stage is optional. If used, it may contain either one or more IN transactions, or one or more OUT transactions. The first of these IN or OUT transactions uses the DATA1 PID. The second, if present, uses the DATA0 PID, the third DATA1, and so on.The STATUS stage consists of a single IN or a single OUT transaction, which must use the DATA1 PID. If the DATA stage is present, then the STATUS stage uses the opposite type of transaction as the DATA stage (i.e, if the DATA stage consists of one or more
OUT transactions, the STATUS stage consists of a single IN transaction, and vice versa). When the DATA stage is omitted, the STATUS stage uses a single IN transaction.
Figure 16 is taken from Figure 8-37 of the USB 2.0 specification and illustrates the transaction order, data sequence bit value, and DATA PID type for control read and write sequences.
Figure 16: Control read and write sequences
In the context of the USB protocol, the only difference between bulk and interrupt transfers is that bulk transfers, when operating at high-speed, support the&. Note that in a general context, these two transfer types are also different in that they are scheduled differently by the host (refer to&).
All bulk and interrupt endpoints transfer in one direction. The data toggle bits for these endpoints are initialized to zero after any configuration event. Figure 17 is taken from Figure 8-35 of the USB 2.0 specification and illustrates the bulk and interrupt
transactions for both IN and OUT endpoints. Note that, even though the figure only mentions bulk reads and bulk writes, the USB 2.0 specification references the same figure from section 8.5.4, on Interrupt Transactions.
Figure 17: Bulk and interrupt transactions
Isochronous transfers are the only type of transfers whose transactions do not have a handshake phase. Isochronous transfers should only use DATA0 PIDs, however the host controller must support DATA1 PIDs as well, even though isochronous transfers do not use
a data synchronization bit mechanism.
High-speed, high-bandwidth isochronous transfers are a special case of isochronous transfers, where up to 3 transactions may occur in one microframe. As a specific type of isochronous transfer, high-speed, high-bandwidth isochronous transfers omit the handshake
phase of their transactions. Since up to 3 transactions may occur in one microframe, high-speed, high-bandwidth isochronous transfers, it is necessary to use a data sequencing mechanism like the other transfer types.
USB 2.0 does implement a data sequencing mechanism for high-speed, high-bandwidth isochronous transfers, but it works a little differently than as in other transfer types. In fact, data sequencing works differently depending on whether an endpoint is an IN,
or an OUT high-speed, high-bandwidth isochronous endpoint.
For IN high-speed, high-bandwidth isochronous endpoints, the data sequencing is depicted in figure 18, which has been taken from figure 5-11 of the USB 2.0 specifications. The last transaction in a microframe always uses the DATA0 PID. The second-to-last transaction
in a microframe uses the DATA1 PID, and the third-to-last transaction in a microframe always uses the DATA2 PID.
Figure 18: Data Phase Sequence for Isochronous IN High Bandwidth Endpoints
For OUT high-speed, high-bandwidth isochronous endpoints, the data sequencing is depicted in figure 19, which has been taken from figure 5-12 of the USB 2.0 specifications. All transactions but the last transaction use the MDATA PID. The last transaction uses
either the DATA0, DATA1, or DATA2 PID, depending on how many transactions were intended to take place during the microframe. If one transaction was meant to take place, it is also the last transaction and uses a DATA0 PID. If two transactions were meant to
take place, the last transaction uses a DATA1 PID. If three transactions were meant to take place, the last transaction uses a DATA2 PID.
Figure 19: Data Phase Sequence for Isochronous OUT High Bandwidth Endpoints
The USB device framework is the thing that makes USB support so appealing. The transfer types and USB protocol are well-designed, of course, but the USB device framework defines standard device states that all devices must support, as well as standard requests
and responses that allow the host to retrieve more than enough information about a device to determine the correct device driver and report information about the device even if the correct device driver isn't available (e.g, the manufacturer's name, the product's
name, etc).
Figure 20: Illustration of the relationship between functions, configurations, interfaces, and endpoints.
All USB devices, or functions, have at least one configuration, and every configuration has at least one interface. An interface may define zero or more endpoints. This relationship is illustrated in figure 20.
Although configurations descriptors are addressed sequentially starting with configuration descriptor zero, each configuration specifies a unique (within the scope of the function), none-zero configuration value. The&configuration value&is
what the host needs to know in order to apply a certain configuration to a device. When asking for the current configuration of a device, a returned value of zero indicates that the device is not configured and is thus in the address state.
An&interface&defines the functional use of a set of endpoints and may imply that certain class-specific requests can be executed via the default control pipe. Thus, an interface need not necessarily define any additional endpoints. No interface
may define the functional use of endpoint zero.
Each interface describes a unique set of endpoints within the scope of the configuration. However, an interface may provide one or more&alternate settings, which may have different definitions for the same set of endpoints. When the host selects
an alternate setting for an interface, the alternate setting's definitions are used instead of the default settings of the same interface.
A USB device may define states that are internal to the device, however the USB device framework defines a set of states that are visible to both the host and the device. Those visible states are the following:
Attached&- Immediately after the USB device is attached to the USB system, it is in this state. The USB specifications do not define the state of a USB device that is detached from a USB system.Powered&- A device is in this state after it has both been attached to the bus, and the VBUS&line is applied to the device (the host controller drives the VBUS&at
+5V, however this is only particularly important for hardware developers). In this state, the device must not respond to any bus transactions. The USB specification recognizes three potential scenarios with respect to how a device draws power:
Self-Powered Devices&draw power from an external power source (e.g, a USB printer plugs into the wall as well as a USB port). Although the device may be considered technically &powered& even before attachment to the USB, it is still only considered
powered after the VBUS&line is applied to the device.Bus-Powered Devices&draw power solely from the USB up to 100mA.Self- or Bus-Powered Devices&may draw power from either the bus or an external power source, depending on the configuration. These devices may change power source at any time. If a device is currently self-powered and requires more than 100mA of
power, but switches to being bus-powered, then the device must return to the Address state.
Default&- A device in the powered state enters the default state after receiving a bus reset. In this state, the device is addressable at the default, reserved address of 0. At this point, the device is operating at the correct speed. The
host is expected to allow 10 milliseconds before expecting the device to respond to data transfers after reset.Address&- A device enters this state after the host assigns it an address via the default control pipe, which is always accessible whether the device's address has been set or not.Configured&- A device is in this state after the host examines its possible configurations and selects one. All endpoint's data toggle bits are initialized to zero when a device enters this state.Suspended&- When no traffic is observed on the bus for a period of 1 millisecond, a USB device enters this state, characterized by its low power consumption. The device's address and configuration settings are maintained while suspended.
A device exits the suspended state as soon as it begins seeing bus activity again. The host is expected to allow 10 milliseconds before expecting the device to respond to data transfers after resume.
One of the reasons a USB device may stop seeing USB traffic and thus enter a suspended state is because the host may have entered a suspended state as well. Some devices, typically keyboards and mice, support the ability to issue a remote wakeup signal to the
host. In case the host software does not support remote wakeup, this capability must be disabled when a USB device is reset. If the host does support remote wakeup, then it may selectively enable the remote wakeup capability for specific devices (typically
as chosen by the user). Then, these devices may issue a remote wakeup signal while in a suspended state to request that the host exits its own suspended state.
The following describes the process of bus enumeration, which occurs after a device is connected to a powered port:
The hub to which the device has been attached notifies the host via its status change pipe. The newly attached device is in the powered state at this point, and the port to which it has been attached is disabled.The host queries more information from the hub to determine that a device has been attached, and to which port.The host must wait at least 100 millisecond to allow a device to complete its insertion process, and for power to stabilize at the device. After the delay, the host enables the port and issues a reset signal to the device for at least 50 milliseconds.The hub performs any required reset processing. After the reset signal has been released, the port is enabled and the device enters the default state.The host assigns the device a unique address, thereby transitioning the device into the address state.The host requests the device descriptor from the device via the default control pipe in order to determine the actual maximum data payload size of the default control pipe for the device. This step may occur before or after the host assigns the device an
address.The host reads all the possible device configuration information.The host selects a certain configuration from the list of configurations supported by the device and sets the device to use that configuration. Optionally, the host may also select alternate interface settings within a configuration. All endpoints are initialized
as described by the selected configuration, and the device is ready to use.
Standard, class-specific, and vendor-specific requests are made to the USB device over the default control pipe. The SETUP transaction always has a data payload size of 8 bytes, as noted in the&&section of&. The format of the setup data is as follows:
Description
bmRequestType
Data transfer direction&* The value of this bit is ignored when wLength is zero
0b = Host-to-device1b = Device-to-host
Type of request
00b = Standard01b = Class10b = Vendor11b = Reserved
00000b = Device00001b = Interface00010b = Endpoint00011b = Other00100b to 11111b = Re}