USB Support in Windows CE 2-0

USB Support in Windows CE 2-10
This section describes the different components of USB support for Windows CE
2.10. Note that the primary focus of USB support in Windows CE has been to enable
the technology such that OEMs can expand on this support. To this end, Windows
CE supports only the host side of USB, since that was the area that would benefit
most from Microsoft® defining the interfaces and enabling the USB technology in
Windows CE. In essence, Microsoft provides the USB system software and a sample
mouse driver that uses it.
Microsoft-Supplied Components
Microsoft supplies the following USB software components:
1* The USBD module that is responsible for loading USB device drivers and
managing resources in the USB subsystem.
2* The complete set of USBD Interface (USBDI) functions listed in the Universal
Serial Bus Specification, Revision 1.0, that is exposed by the USBD module.
The API set includes Transfer Functions, Pipe Functions, Device
Configuration Functions, and Miscellaneous Functions. Full documentation on
these functions is in the Windows CE Device Driver Kit. This API set allows
OEMs and IHVs to write USB device drivers to support any USB-compliant
devices.
3* A sample Open Host Controller Driver (OHCD) that works with OHCI-
compliant USB Host controllers. Note that the sample OHCD is only provided
for the CE/PC platform. OEMs will have to port the sample OHCD to their
platform as part of their OAL implementation. To ease this effort, the OHCD is
divided into two parts: a platform independent "model device driver" (MDD)
and a small "platform-dependent driver" (PDD). This follows the MDD/PDD
device driver model used by other Windows CE native drivers. Thus, OEMs
only need to port the platform-dependent driver (PDD) part.
In addition, if an OEM platform contains a UHCI-compliant Host Controller,
then the OEM could write its own Universal Host Controller Driver (UHCD)
to support UHCI controllers as long as its UHCD exposes the appropriate HCD
interface to the USBD module. The OHCD sample is an appropriate model to

use as a reference while developing a UHCD.
4* A sample MOUSE client device driver that is loaded by the USBD module and
works with most generic USB mice. This is only provided as a sample for
OEMs and IHVs to use as a reference while developing USB device drivers for
their own USB devices.
Source code for these components is available in the
\wince\public\common\oak\drivers\usb directory in the Windows CE Embedded
Toolkit. Header files are in the public\oak\inc and public\ddk\inc directory, and
platform sample code is in the platform\cepc\drivers\usb directory.
System Software Support
Bus Enumeration: Windows CE supports enumeration of USB devices on the bus.
The bus enumeration process consists of an interrogation sequence through which
the HCD module acquires information from a connected device, assigns it a unique
USB address, and sets a configuration value. This is a multi-step process. Once the
enumeration is completed, the device is configured and ready to conduct, transmit,
and receive transactions. At this point, the USBD module will attempt to load one or
more client drivers to control the device, based on the information contained in the
device and interface descriptors. If no suitable driver has been registered for the
device, the user is prompted to enter the name of a driver to control the device.
Power Management: When Windows CE issues a POWER_DOWN notification,
the USB host controller hardware and all devices are suspended by the system. At the
following POWER_UP notification, the USB host controller hardware is reinitialized
and the USBD module unloads the client drivers for all the devices, enumerates the
USB devices connected to the bus, and loads the drivers for those devices. Windows
CE also provides support for bus-powered and self-powered devices. For both types
of devices, the USBD module reads the power requirements of the device from the
descriptor information and rejects the device if the maximum power threshold is
exceeded. OEMs can set this current-draw limit through a registry entry.
Hub Support: Windows CE supports connecting hub devices up to one level deep.
Thus, referring back to the earlier diagram of a typical USB configuration, hubs can

only be connected in Tier 1, and peripheral devices can only be connected in Tiers 1
and 2.
Support for Transfer Types
Windows CE 2.10 supports all four types of data transfers as required by the
Universal Serial Bus Specification, Revision 1.0, to support a variety of devices.
Device drivers for USB devices can use any of these transfer types that may be
appropriate for the device:
5* Control Transfers. Control Transfers are bidirectional transfers that are mainly
used by the USB system software to query, configure, and issue certain generic
commands to USB devices. Control transfers can contain 8, 16, 32, or 64 bytes
of data depending on the device and transfer speed. Control transfers typically
take place between the host computer and the USB device's endpoint 0, but
may use other endpoints in the case of vendor specific control transfers.
6* Isochronous Transfers. Isochronous Transfers are used for streaming data that
is time critical and error tolerant or in real-time applications that require a
constant data transfer rate, for example, an internet telephony application
carrying a conversation in real time. Isochronous data requires guaranteed
amounts of bandwidth and guaranteed maximum transmission times. For
isochronous transfers, timely data delivery is valued much more than accurate
or complete data transfer.
7* Interrupt-Driven Transfers. Interrupt-Driven Transfers are mainly used to poll
devices to see if they have any interrupt data to transmit. The rate of polling is
determined by the device, as indicated in the endpoint descriptor structure, and
may be from 1 to 255 milliseconds. This type of transfer is typically used for
devices that provide small amounts of data at sporadic, unpredictable times.
Keyboards, mice, and joysticks fall into this category.
8* Bulk Transfers. Bulk Transfers are used for devices that have large amounts of
data to transmit or receive and need guaranteed delivery, but do not have any
particular bandwidth or latency requirements. Printers and scanners fall into
this category. Even very slow or greatly delayed transfers are acceptable for

these types of devices, so long as the data is all eventually delivered.
Unsupported Features
There is no support in Windows CE 2.10 for making the Windows CE platform itself
appear as an USB peripheral to other host computers. That is, we do not provide any
Function Drivers on the host or device side to connect a Windows CE platform (such
as an HPC) to a desktop computer running a USB host.
Windows CE 2.10 does not provide any Class Drivers for classes of devices.
Examples of class devices include the Human Input Device (HID) class, Stream
Class, and so on. However, class drivers are supported by the USB system software,
so OEMs can write their own HID class drivers to support HID class devices and
load them appropriately using the registry mechanism.
Microsoft will not provide a wide range of drivers for USB devices in Windows CE
2.10. If an OEM wishes to support a particular USB device, then they will be
responsible for writing a USB device driver to interface with the USBD module.
A UHCI driver will not be included with Windows CE 2.10, but OEMs can write
their own UHCI driver that uses and conforms to the USBD-to-HCD interface.
Device Drivers for USB Devices
This section describes the sequence of actions that takes place when USB drivers are
loaded and the required entry points for all USB drivers, and briefly discusses the
sample USB mouse driver included with Windows CE 2.10. Note that this section
does not provided details on writing USB device drivers; that information is beyond
the scope of this article and can be found in the Windows CE Device Driver Kit.
USB Driver load process
Similar to PCMCIA drivers, USB drivers are loaded via the registry mechanism. The
USBD module is responsible for loading USB client drivers when a USB device is
attached. The USBD module uses the
HKEY_LOCAL_MACHINE\Drivers\LoadClients portion of the registry on the
platform to identify the appropriate USB driver for a given device.
The algorithm used by the USBD module to identify the appropriate USB device
driver from the information in the registry is complex; full details are documented in

the Windows CE Device Driver Kit. Note that the LoadClients registry key must be
set up correctly so that your USB device driver will be loaded for your USB device;
each installed USB device driver must have such a key in order to be recognized and
loaded by the USBD module.
The load strategy used by the USBD module provides a flexible framework that
allows USB device drivers to be registered in different ways, depending on the scope
of devices that they wish to control. For example:
9* USB device drivers can be loaded based on a vendor-specific ID.
10* USB device drivers can be loaded to control devices of a specific device
class
11* USB device drivers can be loaded to control each interface on a device.
12* Complex devices that require more than one device driver can also be
loaded.
Required entry points for USB device Ddrivers
All USB device drivers must expose a certain number of the following entry points in
their DLL. These entry points will allow them to configure and set up the device
connected on the bus or set up the registry.
USBDeviceAttach
This entry point is called when the USB device for some USB device driver is
connected to the USB bus. The driver's implementation of this function can decline to
control the device, in which case Windows CE will attempt to find another driver to
handle the device.
USBInstallDriver
This entry point is called the first time that the USB device driver is loaded, and gives
the driver a chance to create any registry keys that it needs.
USBUnInstallDriver
This entry point is called when the user removes the driver from his or her Windows
CE platform. It is responsible for removing all registry keys created by the driver's
USBInstallDriver function and releasing any other resources held by the driver.
Full details about the syntax of these entry points can be found in the Windows CE

Device Driver Kit.
Sample USB mouse driver
The Embedded Toolkit for Windows CE 2.10 contains source code for a sample
driver for USB mouse devices. This driver uses interrupt-driven transfers. OEMs and
IHVs are encouraged to use the mouse sample driver source code as the basis for
other USB device drivers. Note that the registry is already set up correctly for the
sample CE/PC platform to load the mouse driver, so that plugging in a mouse should
load the driver.
Testing USB Device Drivers
There is no extensive USB test suite for Windows CE at this time. The sample USB
mouse driver, the USB CD-Changer device driver for the Auto PC, and the USB
8x930Ax peripheral kit and evaluation board from Intel® Corporation can be used to
assist in testing USB scenarios. These are the same methods that were used at
Microsoft to test the USB system software for Windows CE 2.10. Further details on
testing a USB system and the device drivers on an OEM platform are available in the
Windows CE Embedded Toolkit.
For More Information
USB Implementers Forum home page. This site contains the
complete USB specification, Universal Serial Bus Specification, Revision 1.0.
Anyone considering building a USB compatible device or designing a hardware
platform that supports USB should read this specification.
on USB hardware and microcontroller chips, such
as the 8x930Ax and 8x931xA series chips.
Windows CE Device Driver Kit—complete information on writing device drivers for
Windows CE.
Windows CE Embedded Toolkit—complete information for building hardware
platforms based on Windows CE.
Send feedback to MSDN. Look here for MSDN Online resources.
USB Speakers
With the advent of USB, several companies have created speakers that connect

directly to the computer through USB. A true USB speaker system has no analog