Archive for the ‘USB’ Category
The Solution Is Split Transactions
Posted by Parkzone Corsair in USB on December 18th, 2009
A USB 2.0 hub communicates with a USB 2.0 host at high speed unless a USB 1.x hub is between the host and hub. When a low- or full-speed device is attached to a USB 2.0 hub, the hub converts between speeds as needed. But speed conversion isn’t all a hub does to manage multiple speeds. High speed is 40× faster than full speed and 320× faster than low speed. It doesn’t make sense for the entire bus to wait while a hub exchanges low- or full-speed data with a device.
The solution is split transactions. A USB 2.0 host uses split transactions when
communicating with a low- or full-speed device on a high-speed bus. What would be a single transaction at low or full speed usually requires two types of split transactions: one or more start-split transactions to send information to the device and one or more complete-split transactions to receive information from the device. The exception is isochronous OUT transactions, which don’t use complete-split transactions because the device has nothing to send.
Split transactions require more transactions to complete a transfer but make better use of bus time because they minimize the time spent waiting for a lowor full-speed device to transfer data. The components responsible for performing split transactions are the USB 2.0 host controller and a USB 2.0 hub that has an upstream connection to a high-speed bus segment and a downstream connection to a low/full-speed bus segment. The transactions at the device are identical whether the host is using split transactions or not. At the host, device drivers and application software don’t have to know or care whether the host is using split transactions because the protocol is handled at a lower level. Chapter 15 has more about how the host and hubs manage split transactions.
Read Other Articles :
USB 2.0 Transaction Are Very Short
Posted by Parkzone Corsair in USB on December 18th, 2009
The allowed delays between the token, data, and handshake packets of a USB 2.0 transaction are very short, intended to allow only for cable delays and switching times plus a brief time to allow hardware (not firmware) to determine a response, such as data or a status code, in response to a received packet.
A common mistake in writing firmware is to assume that the firmware should
wait for an interrupt before providing data to send to the host. Instead, before the host requests the data, the firmware must copy the data to send into the endpoint’s buffer and arm the endpoint to send the data on receiving an IN token packet. The interrupt occurs when the transaction completes. After a successful transaction, the interrupt informs the firmware that the endpoint’s buffer is ready to store data for the next transaction. If the firmware waits for an interrupt before providing the initial data, the interrupt never happens and data doesn’t transfer.
A single transaction can carry data bytes up to the maximum packet size the device specifies for the endpoint. A data packet with fewer than the maximum packet size’s number of bytes is a short packet. A transfer with multiple transactions can take place over multiple frames or microframes, which don’t have to be contiguous. For example, in a full-speed bulk transfer of 512 bytes, the maximum number of bytes in a single transaction is 64, so transferring all of the data requires at least eight transactions, which may occur in one or more frames.
Connecting Endpoints To The Host
Posted by Parkzone Corsair in USB on December 16th, 2009
Before data can transfer, the host and device must establish a pipe. A pipe is an association between a device’s endpoint and the host controller’s software. Host software establishes a pipe with each endpoint address the host wants to communicate with.The host establishes pipes during enumeration. If a user detaches a device from the bus, the host removes the no longer needed pipes. The host can also request new pipes or remove unneeded pipes by using control transfers to request an alternate configuration or interface for a device.
Every device has a default control pipe that uses endpoint zero. The configuration information received by the host includes an endpoint descriptor for each endpoint that the device wants to use. Each endpoint descriptor contains an endpoint address, the type of transfer the endpoint supports, the maximum size of data packets, and, when appropriate, the desired interval for transfers.
