USB communication when host and device to do things

Turn from: http://blog.chinaunix.net/uid-23795818-id-2385141.html
What the host will do: Hardware and software
The hardware required for the host side is: USB host controller and a root hub with one or more USB ports.
The SOFTWARE is: an operating system, enables device drivers to communicate with Lower-level, that access the USB drivers.
A host controller is always combined with a root hub (but it is still not possible to combine the two into a single device because they still have a specific difference) from the Linux host controller driver can see that struct HC The operation of the host controller is included in the _driver, and the operation of the root hub is included. The software mentioned above is the host controller driver.

1. Detection equipment (Detect device)
On power-up, hubs make the host aware to all attached USB devices. In a process
Called enumeration, the host determines what bus speed to use, assigns a
Address, and requests additional information. After power-up, whenever a
Device is removed or attached, a hub informs the host of the event, and the host
Enumerates any newly attached device and removes no detached device from
Its list of devices available to applications.
From here you can see the specific division of the host controller and root hub. The root hub simply notifies the host controller that a device is plugged in or disconnected, and host controller is notified to start a
A process called enumeration (enumeration) that determines the rate of communication, the allocation of addresses, and so on. Establish a true communication channel.

2. Control Data Flow (manage)
The host manages traffic on the bus. Multiple devices may want to transfer data
At the same time. The host controller divides the available time into intervals
and gives each transmission a portion of the available time.
During enumeration, a device ' s driver requests bandwidth for transfers
Must have guaranteed timing. If the bandwidth isn ' t available, the driver can
Request a smaller portion of the bandwidth or wait until the requested band-
The width is available. Transfers that have no guaranteed timing use the remaining
Bandwidth and must wait if the bus is busy.
In the data transmission aspect, the USB uses the time-sharing strategy. The transmission bandwidth is defined and guaranteed at the time of enumeration.

3. Bugcheck (Error checking)
When transferring data, the host adds error-checking bits. On receiving data,
The device performs calculations on the data and compares the
Received error-checking bits. If the results don ' t match, the device doesn ' t
Acknowledge receiving the data and the host knows it should retransmit.
In a similar way, the host Error-checks data received from devices.
USB also Supportsa Transfer type without acknowledgments for use and data such as real-time audio that tolerates errors T o Enable a constant transfer rate.
Error checking is easy to understand when transmitting data, the sender adds error-checking bits to the data, and the receiver receives the data and calculates the checksum with the data received.
The sender's check code is consistent, inconsistent will not respond to the sender, the sender did not receive a response to resend the data. USB also supports transmissions with no error checking.

4. Power supply and power management
In addition to data wires, a USB cable has wires for a +5v supply and ground.
Some devices draw all of their power from the bus. The host provides power to
All devices on/attachment and works with the devices to conserve
Power when possible. A High-power USB 2.0 device can draw up to MA
From the bus. A high-power SuperSpeed device can draw up to 900 MA from a
USB 3.0 Bus. Ports on some battery-powered hosts and hubs support only
Low-power devices, which are limited to MA (USB 2.0) or the MA (super-
Speed). To conserve the ' idle ', a host can require devices to
Enter a low-power state and reduce their with the bus current.

5. Exchange of data
All of the above tasks support the host ' s main job, which are to exchange data
With devices. In some cases, a device driver requests the host to attempt to send
or receive data at defined intervals, while in others the host communicates only
When the application or other software component requests a transfer.



What to do at device end:
Device end to do things in two categories, a class is the corresponding to the host, host request, device must give a response. To make a class is to device the end of their own things.

1. Response Host
On/When a device attaches to a powered system, a device must
Respond to standard requests sent by the host computer during.
The host may also send requests any time after enumeration completes.
All devices must respond to requests, which query the capabilities and sta-
Tus of the device or request the device to take other action. On receiving a
Request, the device places data or status information in a buffer to send to the
Host. For some requests, such as selecting a configuration, the device takes
Action in addition to responding to the host computer.
The USB specification defines requests, and a class or vendor may define addi-
tional requests. On receiving a request the device doesn ' t support, the device
Responds with a status code.

2. Error checking
Similar to host side

3. Data transmission
For most transfers where the host sends data to the
Device, the device responds to all transfer attempt by sending a-code that indicates whether the device the data Or is too busy to accept it.
For most transfers where the device sends data to the host, the device must
To all attempt by returning data or a code indicating the device has no data to
Send.
Data transmission is divided into two types, host to the device transmission data and host request device to send information. Both have responsive response mechanisms (a code).
Device can not actively send data to the host, only when the host requests it to send data to send. (in USB3.0 device can send code to host requests)