Posts Tagged ‘Bus’
Transaction Packet includes a device address
Posted by Parkzone Corsair in USB on December 16th, 2009
The host schedules the transfers on the bus. A USB 2.0 host controller manages traffic by dividing time into 1-ms frames at low and full speeds and 125-µs microframes at high speed. The host allocates a portion of each (micro)frame to each transfer. Each (micro)frame begins with a Start-of-Frame (SOF) timing reference. The SuperSpeed bus doesn’t use SOFs, but a USB 3.0 host schedules SuperSpeed transfers within 125-µs bus intervals. A USB 3.0 host also sends timstamp packets once every bus interval to all SuperSpeed ports that aren’t in a low-power state.
Each transfer consists of one or more transactions. Control transfers always have multiple transactions because they have multiple stages, each consisting of one or more transactions. Other transfer types use multiple transactions when they have more data than will fit in a single transaction. Depending on how the host schedules the transactions and the speed of a device’s response, the transac tions in a transfer may all be in a single (micro)frame or bus interval, or the transactions may be spread over multiple (micro)frames or bus intervals.
Every device has a unique address assigned by the host, and all data travels to or from the host. Except for remote wakeup signaling, everything a USB 2.0 device sends is in response to receiving a packet sent by the host. Because multiple devices can share a data path on the bus, each USB 2.0 transaction includes a device address that identifies the transaction’s destination.SuperSpeed devices can send status and control information to the host without waiting for the host to request the information. Every SuperSpeed Data Packet and Transaction Packet includes a device address. SuperSpeed also uses Link Management Packets packets that travel only between a device and the nearest hub and thus don’t need addressing information.
The Host Manages Traffic on The Bus
Posted by Parkzone Corsair in USB on December 16th, 2009
This chapter looks at the elements that make up a USB transfer. You don’t need to know every detail about USB transfers to get a project up and running, but understanding something about how the transfers work can help in deciding which transfer types a device should use, writing device firmware, and debugging.
To send or receive data, a host initiates a USB transfer. Each transfer uses a defined format to send data, addressing information, error-detecting bits, and status and control information. The format varies with the transfer type and direction.
Every USB communication (with one exception in USB 3.0) is between a host and a device. The host manages traffic on the bus, and the device responds to communications from the host. An endpoint is a device buffer that stores received data or data to transmit. Each endpoint has a number, a direction, and a maximum number of data bytes the endpoint can send or receive in a transaction.
Each USB transfer consists of one or more transactions that can carry data to or from an endpoint. A USB 2.0 transaction begins when the host sends a token packet on the bus. The token packet contains the target endpoint number and direction. An IN token packet requests a data packet from the endpoint. An OUT token packet precedes a data packet from the host. In addition to data, each data packet contains error-checking bits and a Packet ID (PID) with a data-sequencing value. Many transactions also have a handshake packet where the receiver of the data reports success or failure of the transaction. For USB 3.0 transactions, the packet types and protocols differ, but the transactions contain similar addressing, error-checking, and data-sequencing values along with the data.
