Jan Axelson, USB Complete

Подождите немного. Документ загружается.

Chapter 7

206

because every PC has a USB port, some applications might want to use the

interface to communicate between PCs.

If both PCs have Ethernet ports, the cheapest solution is to forget about USB

and use Ethernet. Use a crossover cable to connect the PCs directly or connect

the PCs via a hub or router.

If Ethernet ports aren’t an option, a USB host-to-host bridge cable can do the

job. The cable incorporates two USB device controllers (which may reside in a

single chip). Each controller represents a USB device. Each device attaches to a

different PC, and the devices exchange data via a shared buffer (Figure 7-7).

When a PC sends data to its attached device, the device writes the data to the

shared buffer. The other device in the bridge retrieves the data from the buffer

and sends it on to its attached PC.

Prolific Technology’s PL-2501 Hi-Speed USB Host to Host Bridge Controller

is a single chip designed for this type of host-to-host application. The chip con-

tains an 8032 microcontroller and two USB SIEs that access a common buffer.

Typically, the drivers for bridge cables cause each PC to see the other as a net-

work-connected computer.

Another way to achieve a network connection via USB is to use USB/Ethernet

adapters.

Figure 7-7. To enable two USB hosts to communicate with each other, two USB

serial interface engines can share a buffer. Each SIE copies received USB data

into the shared buffer, and the other device retrieves the data from the buffer

and sends the data to the other host.

Device Classes

207

An alternate approach for host-to-host communications is to use two FTDI

FT232R USB UARTs and cross-connect the asynchronous interfaces in a

null-modem configuration. Each PC then has a COM port that communicates

with a COM port on the other PC.

The exception to the host-and-device rule is the USB 3.0 Standard-A to USB

3.0 Standard-A cable. With host driver support, SuperSpeed devices will be able

to use this cable to communicate with each other. Chapter 19 has more about

the cable.

209



*QYVJG*QUV

%QOOWPKECVGU

This chapter explains how a Windows PC manages communications with USB

devices. The driver architecture described applies to Windows XP and Win-

dows Vista, but much of the information also applies to other Windows edi-

tions.

&GXKEG&TKXGTU

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 cir-

cuits 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.

6JG.C[GTGF&TKXGT/QFGN

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

Chapter 8

210

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 com-

municates 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.

7UGTCPF-GTPGN/QFGU

Under Windows, program code runs in either user mode or kernel mode. Each

mode allows a different level of privilege in accessing memory and other system

resources. Figure 8-1 shows the major components of user and kernel modes in

USB communications. Applications run in user mode. A USB device must have

a kernel-mode client driver, which can have a supplementary user-mode driver.

User mode has limited access to memory and other system resources. Applica-

tions and user-mode client drivers can’t access memory that the operating sys-

tem has designated as protected. Limiting access to memory in this way enables

the PC to run multiple applications at the same time. If an application crashes,

other applications shouldn’t be affected.

Kernel-mode code has unrestricted access to system resources, including the

ability to execute memory-management instructions and control access to I/O

ports. A kernel-mode driver can allow any application to use a device or allow a

single application to have exclusive use. Other abilities that Windows reserves

for kernel-mode drivers include DMA transfers and responding to hardware

interrupts.

The specifics vary with the driver, but in general, ways that applications may

communicate with kernel-mode drivers include Windows API functions, other

functions exposed by a user-mode driver, and the properties, methods, and

events of classes defined by the .NET Framework. To communicate with a USB

device, an application often doesn’t have to know anything about the USB pro-

tocol or whether a device uses USB at all.

Kernel-mode drivers communicate using structures called I/O request packets

(IRPs) supported by the operating system. Each IRP requests a single input or

How the Host Communicates

211

output action. A kernel-mode client driver for a USB device uses IRPs to com-

municate with the bus drivers that handle USB communications.

Drivers create device objects to handle I/O requests. A DEVICE_OBJECT

structure represents the device object. A physical device object (PDO) repre-

sents a device to a bus driver. A functional device object (FDO) represents a

device to a client driver. A filter device object (filter DO) represents a device to

a filter driver.

The Windows PnP manager requests the bus driver to create a PDO for each

device on a bus. For each PDO, the PnP manager may load and call client and

filter drivers that in turn create FDOs and filter DOs.

+PUKFGVJG.C[GTU

The components involved in accessing USB devices include applications,

user-mode client drivers, kernel-mode client drivers, and bus drivers.

Figure 8-1. USB uses a layered driver model under Windows, with separate

drivers for devices and the buses they connect to.

Chapter 8

212

#RRNKECVKQPU

Before an application can communicate with a device, several things must hap-

pen. On power up or device attachment, the operating system enumerates the

device as described in Chapter 4. To identify which driver to use, Windows

compares the retrieved descriptors with the information in the system’s INF

files. Chapter 9 has more about INF files. When enumeration is complete and

the driver is loaded, applications can access the device.

Some drivers cause the host to continuously request data from a device whether

or not an application has requested data. For example, a host requests keypress

data at intervals from a keyboard.

6JG9KPFQYU#2+

Applications written in Visual Basic, C and its variants, Delphi, and other lan-

guages can access many devices by calling Windows API functions. The sup-

ported functions vary with the driver, but an application typically opens

communications with CreateFile, exchanges data using a combination of Read-

File or ReadFileEx, WriteFile or WriteFileEx, and DeviceIoControl, and closes

communications with CloseHandle. Microsoft’s Windows Software Develop-

ment Kit (SDK) documents these functions.

Although the names suggest that the functions are for use with files, ReadFile

and WriteFile (and their variants ReadFileEx and WriteFileEx) can communi-

cate with drivers that access many device types via handle-based operations.

The function calls pass pointers to buffers to store data being read or data to be

written. Depending on the driver, a call to ReadFile might request data from a

device or return data that a driver has already requested and stored in the

driver’s buffer.

DeviceIoControl offers another way to transfer data. Included in each Device-

IoControl request is a control code that identifies a specific command. For

example, IOCTL_STORAGE_GET_MEDIA_TYPES requests the types of

media a mass-storage device supports. Because a function call sends codes to a

specific driver, multiple drivers can use the same codes.

7UKPI0'6ŏU%NCUUGU

For easier and safer programming, Microsoft’s .NET Framework provides

classes that eliminate the need to call many API functions from application

code. Instead, applications communicate with a Common Language Runtime

(CLR) component that in turn may call API functions. The CLR simplifies

How the Host Communicates

213

application programming by handling memory management and other

low-level tasks. For example, instead of using ReadFile and WriteFile to access

files on drives, applications can use methods in .NET’s Directory and File

classes. The CLR works with other components in the .NET Framework to

translate the application code to API calls that access the files.

The .NET classes don’t implement every API function, however. For example,

.NET doesn’t provide methods for detecting device attachment and removal via

WM_DEVICECHANGE messages.

7UGTOQFG%NKGPV&TKXGTU

A user-mode client driver can define a driver-specific API that applications can

use to access devices. The driver is in a dynamic link library (DLL). An example

of a user-mode USB driver is winusb.dll, which exposes routines for accessing

devices that use the WinUSB kernel-mode driver. These routines make up the

WinUSB API. In a similar way, hid.dll is a user-mode driver that exposes HID

API routines for accessing devices that use the HID kernel-mode class driver.

A user-mode driver translates between the driver-defined functions and the

Windows API. For example, when an application calls the Hid_GetFeature API

function, the user-mode HID driver calls the DeviceIoControl API function,

which causes the kernel-mode HID driver to request a HID Feature report

from a device.

-GTPGNOQFG%NKGPV&TKXGTU

A kernel-mode client driver manages communications between user-mode code

and lower-level USB drivers. Kernel-mode client drivers must conform to the

Windows Driver Model (WDM) defined by Microsoft for use under Windows

98 and later. These drivers have the extension .sys. (Other driver types may also

use this extension.) Examples of kernel-mode client drivers are winusb.sys

(WinUSB) and hidclass.sys (HID).

A kernel-mode client driver can be a class driver included with Windows or a

vendor-provided driver. The driver manages communications that are specific

to a device or a class of devices. A class driver may also communicate with a

miniclass driver that manages communications with a subset of devices in a

class.

A client driver or miniclass driver can have one or more upper and lower filter

drivers (Figure 8-2). An upper-level filter driver can monitor and modify com-

munications between applications and a client driver. A lower-level filter driver

Chapter 8

214

can monitor and modify communications between a client driver and the bus

drivers.

For some composite devices, Windows loads a USB common-class generic par-

ent driver (usbccgp.sys) between the bus drivers and the client drivers for the

device’s interfaces. The generic parent driver handles synchronization,

Plug-and-Play (PnP), and power-management functions for the device as a

whole and manages communications between the lower-level USB drivers and

client drivers for the composite device’s interfaces.

User-mode programmers have a choice of programming languages, including

Visual Basic, Delphi, and C/C++/C#. For kernel-mode drivers, C has the

needed capabilities, including portability to multiple Windows platforms. The

WDK provides C header files that define data types and constants for drivers to

use. While C++ is feasible for some kernel-mode drivers, Microsoft documents

problems and risks with using C++.

USB communications use IRPs that contain structures called USB Request

Blocks (URBs). The URBs enable a driver to configure devices and transfer

data. The WDK documents the URBs. A kernel-mode client driver requests a

transfer by creating an URB and submitting it in an IRP to a lower-level driver.

The bus and host-controller drivers handle the details of scheduling transac-

tions on the bus. For interrupt and isochronous transfers, if there is no out-

Figure 8-2. A client driver can have one or more filter drivers that monitor or

modify communications with devices.

How the Host Communicates

215

standing IRP for an endpoint when its scheduled time comes up, the host

controller skips the transaction.

In USB communications, an URB requests a USB transfer that can consist of

one or more transactions. The lower-level drivers schedule the transfer’s transac-

tions without requiring further communications with the client driver.

If you’re using an existing client driver (rather than writing your own), you need

to understand how to access the driver’s application-level interface, but you

don’t have to concern yourself with IRPs and URBs. If you’re writing a client

driver, you need to provide the IRPs that communicate with the system’s USB

drivers.

$WUCPF*QUV%QPVTQNNGT&TKXGTU

The lower-level USB drivers consist of the hub, or bus, driver, the host-control-

ler driver, and one or more miniport drivers (Figure 8-3). The hub driver (usb-

hub.sys) identifies devices on the bus, creates device objects for the devices, and

acts as a client driver for the bus as a whole. The host-controller driver consists

of a port driver (usbport.sys) that manages tasks that are common to all host

controllers plus one or more miniport drivers that each manage communica-

tions with a specific type of host-controller hardware.

Windows provides the hub and host-controller drivers. Application and

device-driver writers don’t have to know the details about how they work, and

Microsoft provides little documentation for these drivers. If you want to know

Figure 8-3. USB communications under Windows involve a hub, or bus, driver, a

host controller driver, and a driver for each host-controller type.