Parkzone Corsair » USB

In The Data Stage of a USB 2.0 Control Read Transfer

Parkzone Corsair — Sun, 21 Feb 2010 09:25:14 +0000

USB 2.0 device doesn’t return an expected handshake packet during a control transfer, the host retries. On receiving no response after a (typical) total of three tries, the host notifies the software that requested the transfer and stops communicating with the endpoint until the problem is resolved.

The two retries include only those sent in response to no handshake at all. A NAK triggers a retry but doesn’t increment the error count.Control transfers use data toggles (USB 2.0) or Sequence Numbers (Super- Speed) to protect against lost data. In the Data stage of a USB 2.0 Control read transfer, on receiving the data from the device, the host normally returns ACK and then sends an OUT token packet to begin the Status stage. If the device for any reason doesn’t see the ACK returned after the transfer’s final data packet, the device must interpret a received OUT token packet as evidence that the Status stage has begun.

Devices must accept all error-free Setup packets. If a new Setup packet arrives before a previous control transfer completes, the device must abandon the previous transfer and start the new one.

A USB 2.0 device has these responsibilities for transfers on a control endpoint:

Send ACK in response to every Setup packet received without error.
For supported control write requests, send ACK in response to received data in the Data stage (if present) and return a ZLP in the Status stage.
For supported control read requests, send data in response to IN token packets in the Data stage and ACK the received ZLP in the Status stage.
For unsupported requests, return STALL in the Data or Status stage.

The Flow Control Condition on Responding

Parkzone Corsair — Sat, 06 Feb 2010 10:06:41 +0000

To conserve bandwidth and to enable inactive links to transition to low-power states, USB 3.0 hosts stop requesting to send or receive data from SuperSpeed endpoints that are in the flow control condition. This condition indicates that the endpoint temporarily can’t send or receive data. To request to resume communications, the endpoint sends an ERDY Transaction Packet. A device can send the ERDY at any time without waiting for the host to request a packet.

On receiving the ERDY, the host resumes communications with the endpoint. An IN endpoint is in the flow control condition after responding to an ACK Transaction Packet with either of the following A NRDY Transaction Packet. A Data Packet with the End of Burst (EOB) field set to 1, indicating that the packet is the last in a burst. The device sets EOB if the data payload is equal to the endpoint’s maximum packet size and the endpoint is returning fewer than the number of packets requested in the previous ACK Transaction Packet.

An OUT endpoint is in the flow control condition on responding to a Data Packet with either of the following A NRDY Transaction Packet. An ACK Transaction Packet with the NumP field set to zero, indicating that the endpoint can’t accept any Data Packets. Hosts retain the option to attempt communications with bulk endpoints in the flow-control condition before receiving ERDY.

USB Classes Included With Windows XP

Parkzone Corsair — Mon, 01 Feb 2010 18:06:17 +0000

Not every device requires its own INF file. Many devices that use the system’s class drivers can use the INF file that Windows provides for the class. These are some INF files for USB classes included with Windows XP.Because Windows XP and later prefer signed drivers, if you provide an unsigned driver for a device in a supported class, Windows XP and later won’t
use your driver and instead will select a compatible ID from the class’s INF file.

An INF file is considered part of the driver package, so Windows XP and later prefer a system-provided INF file for a system driver over an unsigned, vendor provided INF file for the same driver even if the vendor’s INF file contains a matching hardware ID. When the best match is an unsigned driver, operating-system settings can affect whether Windows blocks installation, installs the driver with a warning, or installs with no warning. To change the setting, in Windows Control Panel, select System > Hardware > Driver Signing.

A device that uses a class driver can have a custom, signed INF file with vendor specific strings that display in the Device Manager. For example, the entry for a HID can be a vendor-specific string instead of the default USB Human Interface Device. Many INF files provided with Windows contain sections with manufacturer specific information. When a device passes WHQL tests, Microsoft can add the device’s sections to an existing INF file or add a manufacturer-specific INF file to the files distributed with Windows.

Receive Communications From the Hub

Parkzone Corsair — Sun, 24 Jan 2010 10:13:07 +0000

The hub repeater in a USB 1.x hub handles low- and full-speed traffic. A USB 2.0 hub also uses this type of repeater when its upstream port connects to a full-speed bus. In this case, the USB 2.0 hub doesn’t send or receive high-speed traffic but instead functions identically to a USB 1.x hub.

A low- and full-speed repeater re-transmits all low- and full-speed packets received from the host, including data that has passed through one or more additional hubs, to all enabled, full-speed, downstream ports. Enabled ports include all ports with attached devices that are ready to receive communications from the hub. Devices with ports that aren’t enabled include devices that the host controller has stopped communicating with due to errors or other problems, devices in the Suspend state, and devices that aren’t yet ready to communicate because they have just been attached or are in the process of exiting the Suspend state.

The hub repeater doesn’t translate, examine the contents of, or process the traffic to or from full-speed ports. The repeater just regenerates the edges of the signal transitions and passes the traffic on.

USB Communications Under Windows

Parkzone Corsair — Tue, 12 Jan 2010 12:02:39 +0000

This chapter explains how a Windows PC manages communications with USB devices. The driver architecture described applies to Windows XP and Windows Vista, but much of the information also applies to other Windows editions.

A device driver is a software component that enables applications to access a
hardware device. The hardware device may be a printer, modem, keyboard, video display, data-acquisition unit, or just about anything controlled by circuits the CPU can access. Most USB devices are external devices that connect via cables (or wireless links). Some USB devices, such as fingerprint scanners, are in the box with the CPU.

USB communications under Windows use a layered driver model where each
driver in a series, or stack, performs a portion of the communication task. At the top of the stack is a client driver that the operating system has assigned to
the device. Another term for client driver is function driver. USB class drivers and vendor-specific device drivers are client drivers. Applications access a USB device by communicating with the client driver. The client driver in turn communicates with lower-level bus and port drivers that access the hardware. One or more filter drivers can supplement a client driver or bus driver. Dividing communications into layers is efficient because devices that have tasks in common can use the same driver for those tasks. For example, it makes sense to have one set of drivers that handle tasks common to all USB devices. An operating system can provide these drivers so device vendors don’t have to do so with much duplication of effort.

Define Protocols for Data or Messaging

Parkzone Corsair — Tue, 12 Jan 2010 10:53:13 +0000

The personal healthcare device class encompasses devices that help to maintain health and wellness, manage disease, and enable independent living for the elderly.Devices in the class include heart-rate and blood-pressure monitors, glucose meters, pulse oximeters, motion sensors, and pill monitors.

The class doesn’t define protocols for data or messaging. Devices may use data and messaging standards defined in the ISO/IEEE 11073-20601 Base Exchange Protocol. A device may send data that is episodic (at irregular or infrequent intervals) or continuous. A device may collect and store data before transmitting the data to the host, and a device may collect data when detached from the host. For example, a jogger might wear a monitor while out for a run and upload the data on returning home. Devices may support host-to-device communications to receive configuration data and other episodic data from a host.

The preferred location for the class code is in the interface descriptor, but declaring the class in the device descriptor is allowed. The function must have at least one bulk endpoint in each direction. An interrupt IN endpoint and additional endpoints are optional.

Several class-specific descriptors provide class-specific information. A PHDC
Class Function descriptor specifies the device’s data and messaging protocols. If needed, a Function Extension descriptor follows the PHDC Class Function descriptor. Following each endpoint descriptor is a PHDC QoS descriptor with attributes that describe the latency and reliability of the data channel. If needed, a PHDC MetaData descriptor follows the PHDC QoS descriptor to provide application-specific information.

Incoming search terms:

11073 20601 example

The Solution Is Split Transactions

Parkzone Corsair — Fri, 18 Dec 2009 09:25:56 +0000

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

Parkzone Corsair — Fri, 18 Dec 2009 09:22:59 +0000

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

Parkzone Corsair — Wed, 16 Dec 2009 23:15:21 +0000

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.

Endpoint Zero Configured

Parkzone Corsair — Wed, 16 Dec 2009 23:05:12 +0000

Every USB transfer consists of one or more transactions, and each transaction in turn contains packets of information. To understand transactions, packets, and their contents, you also need to understand endpoints and pipes. So that’s where we’ll begin.All bus traffic travels to or from a device endpoint. The endpoint is a buffer that typically stores multiple bytes and consists of a block of data memory or a register in the device-controller chip. The data stored at an endpoint may be received data or data waiting to transmit.

The host also has buffers that hold received data and data waiting to transmit, but the host doesn’t have endpoints.Instead, the host serves as the source and destination for communications with device endpoints.An endpoint address consists of an endpoint number and direction. The number is a value in the range 0–15. The direction is defined from the host’s perspective: an IN endpoint provides data to send to the host and an OUT endpoint stores data received from the host. An endpoint configured for control transfers must transfer data in both directions, so a control endpoint consists of a pair of IN and OUT endpoint addresses that share an endpoint number.

Every device must have endpoint zero configured as a control endpoint. There’s rarely if ever a need for additional control endpoints.