Developing USB Device Drivers [WinCE]

Developing USB Device Drivers

- communications protocol that supports serial data transfers between a host system and USB-capable peripherals.

- USB device drivers communicate with USB devices through logical communication channels called pipes.

- USB system software implements APIs that USB device drivers use to open and close pipes, configure them, read and write to them, and so on.

- Pipes are connected to endpoints on the USB device, which are logical producers or consumers of data.

- USB devices generally have several endpoints, each with a specific purpose.

- All USB devices have a special endpoint, endpoint number 0, which is used as a high-level control channel.

- Internally, the USB system software and hardware in Windows CE handles the task of marshalling the data from all pipes going to and from the endpoints on all USB devices connected to the Windows CE-based platform onto a single USB cable.

Structure of the USB implementation in Windows CE

- Windows CE supports the host side of the USB architecture, which enables developers to write USB device drivers for any USB peripheral devices.

- Windows CE provides limited support for the device side of the USB architecture, which allows a Windows CE-based platform to appear as a USB peripheral to other computers.

-host side exists to support the use of USB peripherals,

- device side exists mainly to facilitate USB connectivity to desktop computers.

- USB architecture implemented in Windows CE supports both device-specific USB drivers, and more generic USB drivers known as class drivers, which can control a whole class of similar devices.

- Microsoft supplies one sample USB driver: a class driver for human interface-class (HID class) devices.

- OEMs who wish to support USB on their Windows CE-based platforms must port Microsoft's sample HCD module implementations to their hardware.

- Microsoft supplies sample HCD modules for OHCI- and UHCI-compliant host controller chips.

- Writing USB device drivers is generally easy because the USB infrastructure itself provides a rich set of services for accessing USB peripheral devices.

- USB device drivers can use high-level data transfer functions to send data to and read data from USB peripherals,

- developer can concentrate on writing the code that exposes the USB device to applications

- Windows CE supports all four types of data transfer defined in the Universal Serial Bus Specification

- USB device drivers can use any of the transfer types that are appropriate for their peripherals.

- Windows CE 3.0 also provides some support for the device side of the USB device/host architecture.

- This allows Windows CE-based platforms to communicate to other USB hosts, such as desktop PCs, through a USB connection.

-  Microsoft provides a sample USB function controller driver that works with the Scanlogic SL11 USB function controller chip.

- USB client drivers exist to make the services of peripheral devices available to applications.

- OEMs and IHVs can choose among the following three strategies to make the services of peripheral devices available to applications:

- Using the stream interface functions.

USB device drivers can expose the stream interface functions like any other device driver. Applications can then treat the peripheral device as a file and use standard file I/O functions to interact with the device.

- Using an existing Windows CE API.

USB device drivers can indirectly expose certain types of peripherals to applications by interacting with a Windows CE API if Windows CE has an existing API appropriate to the peripheral. For example, USB drivers for mass storage devices, such as hard drives and CD-ROM drives, can expose devices through the standard installable file system interface. The sample HID-class driver included in the DDK also uses this strategy. The driver does not expose devices directly to applications; rather, it interacts with existing Windows CE APIs in order to submit the correct input events to the system. Thus, the USB nature of HID-class devices is transparent to applications.

- Creating a native device driver.

This strategy does not place any restrictions on the way a USB driver exposes a device. It allows you to create whatever API best maps to the ways in which applications are likely to use your USB device. However, you must provide appropriate documentation for application writers who will be writing applications that use the driver because application writers cannot otherwise know what APIs your driver exposes.