Parkzone Corsair » Communications

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.

About Hub Communications

Parkzone Corsair — Wed, 20 Jan 2010 10:45:46 +0000

A hub is an intelligent device that provides attachment points for devices and
manages each device’s connection to the bus. Devices that plug directly into the host computer connect to the system’s root hub. Other devices can connect to external hubs downstream from the root hub.

A hub manages power use, helps initiate communications with newly attached devices, and passes traffic up and down the bus. To manage power, a hub provides current to attached devices and limits current on detecting an over-current condition. To help initiate communications with devices, the hub detects and informs the host of newly attached devices and carries out requests that apply to the devices’ ports.

The hub’s role in passing traffic up and down the bus varies with the speeds of the host, device, and hubs between them. This chapter presents essentials about hub communications. You don’t need to know every detail about hubs in order to design a USB peripheral. But some understanding of what the hub does can help in understanding how devices are detected and communicate on the bus.

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.

Detect Communications Directed to the Chip

Parkzone Corsair — Wed, 16 Dec 2009 03:55:20 +0000

Devices must detect communications directed to the device’s address on the bus. The device stores received data in a buffer and returns a status code or sends requested data from a buffer or a status code. In almost all chips, these functions are built into the hardware and require no support in code beyond preparing the buffers to send or receive data. The firmware doesn’t have to take other action or make decisions until the chip has detected a communication intended for the device’s address.

SuperSpeed devices have less of a burden in detecting communications because the host routes SuperSpeed communications only to the target device.On power up or when a device attaches to a powered system, a device must respond to standard requests sent by the host computer during enumeration. The host may also send requests any time after enumeration completes. All devices must respond to these requests, which query the capabilities and status 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 other action in addition to responding to the host computer.The USB specification defines requests, and a class or vendor may define additional requests. On receiving a request the device doesn’t support, the device responds with a status code.