Parkzone Corsair » USB

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.

The Device Uses USB or Another Interface

Parkzone Corsair — Wed, 16 Dec 2009 03:45:30 +0000

To communicate with USB devices, a computer needs hardware and software that support the USB host function. The hardware consists of a USB host controller and a root hub with one or more USB ports. The software support is typically an operating system that enables device drivers to communicate with lower-level drivers that access the USB hardware.

A typical PC has one or more hardware host controllers that each support multiple ports. The host is in charge of the bus. The host has to know what devices are on the bus and the capabilities of each device. The host must also do its best to ensure that all devices on the bus can send and receive data as needed. A bus may have many devices, each with different requirements, all wanting to transfer data at the same time. The host’s job isn’t trivial.

Fortunately, the host-controller hardware and drivers in Windows and other operating systems do much of the work of managing the bus. Each device attached to the host must have an assigned device driver that enables applications to communicate with the device. System-level software components manage communications between the device driver and the host controller and root hub.

Applications don’t have to know the hardware-specific details of communicating with devices. All the application has to do is send and receive data using standard operating-system functions or other software components. Often the application doesn’t have to know or care whether the device uses USB or another interface. The host performs each of the tasks described below.

Of USB’s Four Transfer Types

Parkzone Corsair — Fri, 20 Nov 2009 07:08:13 +0000

Because all devices share the bus, a device has no guarantee that a particular rate or maximum latency will be available on attachment. If the bus is too busy to allow a requested transfer rate or maximum latency, the host refuses to complete the configuration process that enables the host to schedule transfers. The device’s driver can then request a configuration or interface that requires less bandwidth. To take full advantage of reserved bandwidth, the device driver and application software and device firmware must eliminate retries as much as possible.

The device should have data ready to send when the host requests it and should be ready to accept data when the host sends it.Of USB’s four transfer types, the fastest on an otherwise idle bus are bulk transfers,with theoretical maximums of around 1.2 MB/s at full speed, 53 MB/s at high speed, and 400 MB/s at SuperSpeed. Isochronous transfers can request the most bandwidth (1.023 MB/s at full speed, 24.576 MB/s at high speed, and 393 MB/s at SuperSpeed). Low speed doesn’t support bulk or isochronous transfers, and the maximum guaranteed bandwidth for a single low-speed transfer is 800 bytes per second.

USB supports transfer types

Parkzone Corsair — Fri, 20 Nov 2009 07:01:57 +0000

The data throughput, or rate of transfer of application data, between a device and host is lss than the bus speed and isn’t always predictable. Some of the transmitted bits identify, synchronize, and error-check the data, and the throughput also varies with the transfer type and how busy the bus is.For time-sensitive data, USB supports transfer types that have a guaranteed rate or guaranteed maximum latency. Isochronous transfers have a guaranteed rate,where the host can request a specific number of bytes to transfer at defined intervals. The intervals can be as short as 1 ms at full speed or 125 μs at high speed and SuperSpeed.

Isochronous transfers have no error correcting, however.Interrupt transfers have error correcting and guaranteed maximum latency. The device specifies a maximum interval, and when a driver has requested a data transfer, the host allows no more than the specified interval, or maximum latency, to elapse between transfer attempts. The requested maximum interval can have a range of 10–255 ms at low speed, 1–255 ms at full speed, and 125 μs to 4.096 s at high speed and SuperSpeed.