Tai lieuUSB.doc

USB Architecture
A USB system consists of a host computer, one or more USB devices, and a physical
bus. The host consists of two layers: an upper software layer, which includes USB
device drivers, and a host controller hardware layer, also known as an adapter layer.
The main responsibility of the host computer is to control data transfers to and from
USB devices. USB devices are peripherals that use the USB electrical and data format
specifications to communicate with the host computer. The physical bus is the set of
USB cables that links the controller with the peripherals.
Bus-powered and Self-powered USB Devices
Windows CE 2.10 and later provide full support for bus-powered and self-powered
USB devices. When a user connects a self-powered or bus-powered device to a
Windows CE–based platform, the USB system software automatically accepts or
rejects the device, based on the power requirements of the device. The power model
is the same for both bus-powered and self-powered devices.
When a USB device is attached to a Windows CE–based platform, the HCD module
sets the initial power configuration. During the device attachment processing phase,
the HCD module reads the power requirements of the USB device configurations
from the device configuration descriptor structures. In this way, the HCD module can
choose an appropriate power configuration for the device.
Some devices may provide several configurations with different power requirements.
OEMs who port an HCD module to their hardware can implement policies to choose
the appropriate power configurations from those provided by the USB devices.
For example, Windows CE–based platforms have a registry setting that specifies
the maximum total current draw allowable for USB devices connected to the host
computer. If enabling a device would exceed this power threshold, the device is not
configured unless the device has an alternate configuration with acceptable power
requirements. OEMs can customize the platform-specific portions of the HCD
module to choose dynamically whether to configure devices based on the current
system power level. OEMs can implement a power model suitable for their platforms
because the HCD module calls platform-specific code in its PDD layer for all USB
devices connected to the bus. Therefore, an OEM can implement a power model that

can selectively grant or deny power to individual USB devices according to whatever
criteria the OEM chooses.
Because an HCD module cannot know which configuration might be appropriate for
different uses of a USB device, a USB device driver can change its device
configuration after the device driver is loaded, to the extent that the new
configuration meets overall system power requirements. A USB device driver uses
the SetConfiguration function to change a USB device configuration. In the
unconfigured state, USB devices may not draw more than 100 mA.
Built on Wednesday, October 04, 2000
USB Components Supplied by Microsoft
Microsoft supplies the following USB software components:
• The USB driver (USBD) module, which loads USB device drivers and manages
resources in the USB subsystem.
• The complete set of USBD interface functions listed in the Universal Serial
Bus Specification, Revision 1.1, implemented by the USBD module. The API
set includes transfer functions, pipe functions, device configuration functions,
and miscellaneous functions. This API enables developers to write USB device
drivers to support any USB devices.
• A sample HCD module that works with open host controller interface
(OHCI)–compliant USB host controllers. OEMs must port the PDD portion
of this driver to their hardware if their platform contains an OHCI host
controller.
• A sample HCD module that works with universal host controller driver
(UHCI)–compliant USB host controllers. OEMs must port the PDD portion
of this driver to their hardware if their platform contains a UHCI host
controller. Note that the sample UHCI implementation for the CEPC reference
platform does not support suspend and resume functionality. To add this
support, the sample PDD layer would have to be modified to use the suspend
and resume support present in the MDD layer.
• A sample USB class driver for human interface devices (HID).

Source code for these components is available in
\Wince\Public\Common\Oak\Drivers\USB located in the Windows CE Platform
Builder. Header files are in \Wince\Public\Oak\Inc and \Wince\Public\Ddk\Inc.
Platform sample code is in Platform\Cepc\Drivers\Usb.
Built on Wednesday, October 04, 2000
USB Device Driver Load Process
The USBD module takes the following steps when loading drivers, stopping as soon
as it finds a driver that accepts control of the device. The following rules describe the
algorithm that the USBD module uses to search for USB device drivers. In the
descriptions, GroupX_ID refers to a key with the specified group set to one of the
forms described in Registry Keys for USB Device Drivers and the remaining groups
set to Default. If multiple drivers are registered within the same group, the one that
contains the simplest form is loaded first. For example, a driver specifying a
Group1_ID with device class code only, such as Default\DeviceClass\Default,
loads before a driver specifying a Group1_ID with device class and subclass code,
such as Default\DeviceClass_Subclass\Default. This allows Windows CE to
conserve resources by loading as few drivers as possible. This procedure takes the
following steps:
1. The USBD module searches for a subkey with the name
Default\Default\Default. If present, the module loads the driver listed within
the Default\Default\Default\DriverName\DLL subkey. A driver registered in
this way is loaded for all USB devices that are connected to the system.
2. The USBD module searches for a vendor-specific driver. Vendor-specific
drivers are identified by searching for the most general Group1_ID subkey
that matches the device descriptor information. The most general subkey is the
one that has a matching Group1_ID subkey containing the simplest allowable
form and Default for the Group2_ID and Group3_ID subkeys. If a matching
subkey is found, the module loads the driver that is listed within the subkey’s
DriverName\DLL subkey. For more information on allowable forms, see
Registry Keys for USB Device Drivers.

3. The USBD module searches for a device class-specific driver. Class-specific
drivers are identified by searching for the most general Group2_ID subkey. If
a matching subkey is found, the module loads the driver listed within the
subkey’s DriverName\DLL subkey.
The searches in steps 1 through 3 may not yield a matching USB device driver to
control the device as a whole; that is, the device may have multiple interfaces, but no
driver identified in steps 1 through 3 may match all of the interfaces present on the
device. If so, the USBD module takes the following steps to search for matching
drivers for each interface present on the device, searching for the most general
Group3_ID subkey. If the USBD module finds a matching subkey, it loads the
driver listed within the subkey’s DriverName\DLL subkey.
Finally, if no appropriate USB device driver is located, the USBD module prompts a
user to enter the name of a DLL containing the correct driver. The USBD module
then loads the driver and calls the driver’s USBInstallDriver function.
USBInstallDriver should create an appropriate subkey for the driver by calling the
RegisterClientSettings function so the next time that the USB device is attached, the
USBD module can locate the correct driver without prompting a user.
In some cases it may be necessary to specify the precedence order to a greater level
of detail; for example, combining vendor- and device-class specifiers. In these cases,
the GroupX_ID values may be combined to generate other combinations. The
precedence for such combinations is as follows, in descending order:
1. Group1_ID\Default\Default
2. Group1_ID\Group2_ID\Default
3. Default\Group2_ID\Default
4. Group1_ID\Group2_ID\Group3_ID
5. Group1_ID\Default\Group3_ID
6. Default\Group2_ID\Group3_ID
7. Default\Default\Group3_ID
If multiple drivers are registered at a particular precedence level, the USBD module
loads the one with the most general form.

Built on Wednesday, October 04, 2000
USB Devices
USB peripheral devices consist of one or more physical components that implement
the abilities of the devices. These components are called interfaces. Each interface
typically provides some useful grouping of functionality, but exactly what constitutes
an interface is an implementation detail. For example, a USB mouse device could
present one interface for horizontal and vertical movement information and a
separate interface for left and right button information. As another option, the device
could present a single interface containing all of the information. Both are valid
approaches, but each approach has implications for how the device driver must
operate.
Associated with each interface is a set of endpoints. Endpoints are the ultimate
producers or consumers of data that is transmitted across the bus. All USB devices
have a special endpoint, known as endpoint 0, which supports the generic USB status
and configuration protocol.
USB device drivers establish logical communication channels, called pipes, to the
various endpoints on a USB device. A pipe is a software association between a USB
device driver and an endpoint. Pipes can be thought of as communication channels
that use function calls to the USB system software to communicate with their
associated endpoints. The characteristics of a pipe, such as the direction of
communication and the required bandwidth, are determined by the endpoint
characteristics, which in turn are indicated in the endpoint descriptor structure.
The bus interface hardware on a USB device is responsible for the transmission and
reception of USB-structured data. The logical USB device corresponding to a
physical USB device consists of USB abstraction entities, such as the device
endpoints and their corresponding pipes.
Built on Wednesday, October 04, 2000
Universal Serial Bus Drivers
The universal serial bus (USB) is an external bus architecture for connecting USB-
capable peripheral devices to a host computer. USB is not designed to be used as the

internal bus for connecting CPUs to main memory and to devices that reside on a
motherboard. Instead, USB is a communication protocol that supports serial data
transfers between a host system and USB-capable peripherals. USB technology was
developed as a solution to the increasing user demands on computers and the need
for flexible and easy-to-use peripherals. USB technology directly affects a number of
standard peripherals, such as keyboards, joysticks, mouse devices, digital cameras,
computer telephony integration (CTI), and video-conferencing products.
USB offers the following benefits to system designers and users:
• USB provides a single, well-defined, standard connector type for all USB
devices. This simplifies not only the design of USB devices, but also a user’s
task of determining which plugs correspond to which ports on their computer.
• USB eliminates the need for separate mouse, modem, keyboard, and printer
ports, thus reducing hardware complexity.
• USB supports hot plugging, which means that USB devices can be safely
connected and disconnected while the host is turned on. Other generic
peripheral connection standards, such as the Small Computer System Interface
(SCSI), require that the host be turned off when peripherals are added or
removed.
• USB supports Plug and Play. When a USB device is plugged in, the host
computer identifies the device and configures it by loading the appropriate
driver.
• USB provides flexibility in how devices are powered. USB devices can draw
power directly from the USB cable (bus-powered devices), supply their own
power from batteries or from a wall outlet (self-powered devices), or use a
combination of both types of power.
• USB supports power-saving suspend and resume modes.
• USB offers a high-speed 12-megabits-per-second mode (Mbps) and a low-
speed 1.5-Mbps mode that support a variety of peripherals.
• USB guarantees certain amounts of bandwidth for devices that cannot tolerate
transmission that comes in bursts, such as streaming audio and video devices.

• USB offers four different data transfer types that are suited to the needs of
various types of peripheral.
• USB enables multiple peripherals to communicate simultaneously with the
host.
Consult the following sources for additional information about USB technology that
is important both for OEMs who add USB support to their Windows CE–based
platforms and for independent hardware vendors (IHVs) who build USB peripherals:
• USB Implementers Forum Web site
This site contains the complete USB specification, Universal Serial Bus
Specification, Revision 1.1.
• Intel Corporation Web site
This site contains information on USB hardware and microcontroller chips,
such as the 8x930Ax and 8x931xA series chips.
Note The official Universal Serial Bus Specification, Revision 1 uses the term
function to refer to USB-capable peripheral devices. However, because function
typically refers to callable units of C/C++ code, Windows CE documentation uses
the term USB device to refer to USB peripherals. In addition, the official Universal
Serial Bus Specification, Revision 1, uses the term USB client driver to refer to
device drivers for USB devices, but to avoid confusion with client/server
terminology, this documentation uses the term “USB device driver.”
Built on Wednesday, October 04, 2000
Supported and Unsupported USB Features
Windows CE 2.10 and later support the following USB features:
• Bus enumeration
Windows CE supports enumeration of USB devices on the bus. The bus
enumeration process is a multistep query sequence: the HCD module acquires
information from a connected device, assigns it a unique USB address, and
sets a configuration value. Once enumeration is complete, the device is
configured and ready to conduct, transmit, and receive transactions. At this
point, the USBD module attempts to load one or more USB device 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, a
user is prompted to enter the name of a driver to control the device.
• Power management
Windows CE provides support for bus-powered and self-powered devices. For
both types of device, the USBD module reads the power requirements of the
device from the descriptor information and rejects the device if it exceeds the
maximum power threshold. OEMs can set the current-draw limit, so IHVs
should not rely on any particular amount of available current, except as
detailed in the Universal Serial Bus Specification, Revision 1. Current-draw
limits are enforced by USB hubs, not by the host computer; devices which
draw too much current will be shut down by their hub. Hubs that cannot
control the power level on individual ports may simply shut down all their
ports, or may be forcibly shut down by an upstream hub, when a current over-
draw situation occurs. This can cause multiple USB devices to disconnect from
the bus if a single device draws too much current.
Windows CE does not support complex power saving modes or partial-power
modes for USB devices when the Windows CE device is suspended. Instead,
the entire bus is shut down. Consequently, Windows CE does not support
resuming from suspension in response to the needs of a USB device. Also,
Windows CE does not support the remote wakeup feature as described in the
Universal Serial Bus Specification, Revision 1.
• Transfer types
Windows CE supports all four types of data transfer defined in the Universal
Serial Bus Specification, Revision 1. USB device drivers can use any of the
transfer types that are appropriate for their peripherals.
• Class drivers
The USB architecture implemented in Windows CE supports loading class
drivers. Examples of USB device classes include the human input device
(HID) class and the mass storage class, among others. OEMs or IHVs can

write their own class drivers and load them appropriately, using the registry
mechanism.
Windows CE 2.12 and later supports the following features:
• Support for integrated and external hubs. Windows CE 3.0 and later supports
connecting hub devices up to five levels deep, the maximum allowed by the
Universal Serial Bus Specification, Revision 1.
Windows CE offers limited support for the following features:
• Unknown USB peripherals. Unknown USB peripherals generally cause no
problems in Windows CE systems, but under some circumstances connecting
an unknown USB peripheral to a Windows CE system that uses completely
legacy-free ports and has an OHCI-based host controller can cause the USB
subsystem to stop responding. This is rare, but can happen when the USB
peripheral does not have a driver installed on the Windows CE system, when
an unknown USB peripheral is connected to a running Windows CE system,
and then the system is cold- or warm-booted, or when an unknown USB
peripheral is connected to a Windows CE system that is powered off and the
system is subsequently rebooted. In these cases, other USB peripherals that
have been enumerated will continue to function, but device enumeration
actions will not complete. You may be able to connect and disconnect an
unknown USB peripheral to a running Windows CE system so long as you do
not reboot the system, but if problems occur you must disconnect the unknown
USB peripheral and reboot the Windows CE system.
USB Host Controller
The host controller, or adapter, is a hardware layer that is contained within the host
computer. The host controller converts data between the format that is used by the
host computer and the USB format. Only OEMs who implement Windows CE–
based products that use USB need to write drivers for USB host controllers. For more
information, see Developing Native Device Drivers
USB and WDM Modem Update
The USB Device Working Group has completed work on the Communications

Device Class (CDC) Specification, Version 1.0. It covers analog modems and
telephones. Some IHVs have implemented this specification.
Microsoft has built a class driver for USB modems, called Usbser.sys. It is included
in the beta release of Windows 98 SP1. It is included in Windows 2000 Beta 3.
Usbser.sys is a WDM driver. It is supported by way of the CCPORT mapping layer
on Windows 2000, which is also included in Windows 98 SP1.
WHQL is currently developing a test program for USB modems. They will begin
testing by the time USB modem support is shipping with an operating system, such
as Windows 98 SP1.
Conclusion
Soft modems are appropriate when bundled in some systems, but they require careful
design on the part of the modem designer and the system designer.
Call to action for soft modems:
• All review comments on the soft modem guidelines are welcome. Please send
comments to with Soft Modem in the Subject line.
Please include your name, title, company name, and phone and fax numbers.
-------------------------------------------------------------------------------------------------
Disclaimer for Working Documents
The information contained in this document represents the current view of
Microsoft Corporation of the issues discussed as of the date of publication.
Because Microsoft must respond to changing market conditions, it should not be
interpreted to be a commitment on the part of Microsoft, and Microsoft cannot
guarantee the accuracy of any information presented after the date of publication.
This document is for informational purposes only. MICROSOFT MAKES NO
WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Send feedback to MSDN. Look here for MSDN Online resources.
USB Power Management
Windows CE provides full support for power management of USB devices, as
described in the Universal Serial Bus Specification, Revision 1. Very important for
Windows CE are support for suspending and resuming, because Windows CE–

based platforms have a power-on and startup cycle that differs from the one on
desktop computers. Support for bus-powered and self-powered USB devices is also
important because many Windows CE–based platforms have limited power
resources. For more information about power management, see Developing Native
Device Drivers.
Windows CE supports power cycling USB devices in association with the standard
Windows CE power states. When Windows CE issues a POWER_DOWN
notification, the HCD module resets and halts the USB host controller hardware and
removes power from the bus, but does not suspend any connected USB devices.
When power returns to the platform, Windows CE sends a POWER_UP notification
to the HCD module. When the host controller hardware has been re-initialized, the
USBD module unloads the USB device drivers loaded prior to the POWER_DOWN
notification, identifies all the USB devices that are currently connected to the bus—a
process called bus enumeration—and loads the USB device drivers for those devices.
This power cycle processing is very similar to that performed by the Windows CE
Device Manager for PC Card devices.
This implies that USB device drivers may need to take special action to make a
power cycle transparent to upper-level applications. For example, if a USB device
provides a file system, the device driver should preserve open file handles across a
power cycle. There are several ways to accomplish this. One solution is for the USB
device driver to register itself with the Device Manager as a stream interface driver
by calling the ActivateDevice function. This increments the reference count on the
USB device driver’s dynamic-link library (DLL) so that when the USBD module
unloads the driver, the driver’s code still remains in memory. The USB device driver
could keep any application file handles open and wait for the call to the
USBDeviceAttach function, which occurs after the system resumes and the USB
device is ready to be used. The disadvantage of this approach is that the driver
remains in memory even after the USB device is detached from the system. The
second solution is to separate the USB interface from the upper-level file system
interface; keep the file system driver code which manages file handles separate from

the USB device driver code that actually manages the storage hardware.
Windows CE provides full support for bus-powered and self-powered USB devices.
When a user connects any self-powered or bus-powered device to a Windows CE–
based platform, the USB system software automatically accepts or rejects the device,
based on the device’s power requirements and the system’s overall power load. The
power model is identical for both self-powered and bus-powered devices.
When a USB device is attached to a platform, the HCD module sets the initial power
configuration. During the device attachment processing phase, the HCD module
reads the power requirements of the USB device configurations from the device
configuration descriptor structures. It then calls in to the platform-specific portion of
the HCD module to determine if the host platform can support the USB device’s
power requirements. An OEM can implement code in the platform-specific portion
of the HCD module to test system power status, such as whether the system is
running on batteries or is plugged into a power outlet, to assist in making this
determination. USB device drivers may be able to choose an appropriate
configuration for their devices if that functionality is supported in the OEM’s HCD
module.
Windows CE does not support placing a USB peripheral into suspend mode
programmatically.
USB device drivers that are managed by the USBDI module do not receive the
normal Windows CE POWER_UP and POWER_DOWN notifications—such drivers
are only aware of the USBDI module loading and unloading them at various times. If
such a driver needs to track the power status of the system, it can do so by
implementing a stream interface and calling ActivateDevice or RegisterDevice so
that the driver’s stream interface receives POWER_UP and POWER_DOWN
messages.
Built on Wednesday, October 04, 2000
Suspending and Resuming
Windows CE supports suspending and resuming USB devices in association with the
standard Windows CE power states. When Windows CE issues a POWER_DOWN

notification, the HCD module suspends the USB host controller hardware and all
devices. To achieve this, the MDD layer of the HCD module calls a function in the
PDD layer to enable the HCD module to complete any platform-specific processing
needed to suspend the host controller hardware properly. Suspending power to the
host controller hardware typically causes USB devices connected to a Windows
CE–based platform to enter the suspended state. However, this is not recommended
for all devices; USB devices that can collect and store data while the host computer is
off should not be suspended.
When the Windows CE–based platform is turned on again, Windows CE sends a
POWER_UP notification to the HCD module. Next, the MDD layer of the HCD
module calls a function in the PDD layer. Because the PDD layer is used, OEMs can
customize the HCD module to perform any necessary platform-specific processing.
Following the call to the PDD layer, the HCD module reinitializes the host controller
hardware.
When the host controller hardware has been reinitialized, the USB driver module
unloads the USB device drivers loaded prior to the POWER_DOWN notification,
identifies all the USB devices currently connected to the bus—a process called bus
enumeration—and loads the USB device drivers for those devices. This suspend and
resume processing is very similar to that performed by the Windows CE Device
Manager for PC Card–based devices.
Built on Wednesday, October 04, 2000
USB System Software
USB system software consists of two layers: an upper layer of USB device drivers
and a lower layer of USB functions that are implemented by Windows CE. USB
device drivers use the USB functions to establish connections to the devices they
control and to configure and communicate with the devices. The lower layer of USB
functions performs several interrelated tasks:
• Manage all communication between USB device drivers and the host
computer’s built-in USB root hub
• Load and unload USB device drivers at the appropriate times

• Translate data to and from the USB protocol’s frame and packet formats
• Perform generic configuration and status-related tasks by establishing
communication with the generic endpoint on all USB devices
The lower layer is itself composed of two parts—the upper universal serial bus driver
(USBD) module and the lower host controller driver (HCD) module. The USBD
module implements the high-level USBD interface functions in terms of the
functionality provided by the HCD module. USB device drivers use the USBD
interface functions to communicate with their peripherals.
IHVs and manufacturers of USB devices should make use of the functions that are
provided by the USBD to implement their USB device drivers. OEMs are responsible
for providing an HCD module to their Windows CE–based platforms so that their
hardware properly interfaces with the USBD module.
The following illustration shows the two layers of software in the context of the
host’s USB hardware and a peripheral device.
During a data transfer, the flow of operation typically proceeds in the following
sequence:
1. A USB device driver initiates transfers by using USBD interface functions to
issue requests to the USBD module.
2. The USBD module passes the requests to the HCD module.
3. The HCD module divides requests into individual transactions, based on its
knowledge of the bus and on characteristics of the USB devices that are
connected to the bus, and schedules these transactions over the bus.
4. The host controller hardware performs or completes the transactions.
Note: the USBD module is layered in order to assist OEMs in porting the USBD
module to their USB Host Controller Hardware implementations. Internally, the
USBD module contains a set of USBDI functions, in the same way that layered
drivers contain DDSI functions. USB device drivers are not allowed to invoke the
USBDI functions directly; they should limit themselves to the USBD interface
functions. The USBDI functions are described in the Windows CE Driver
Development Kit reference section for the benefit of OEMs who need to use them in

their USBD module implementations.
All transactions on the bus originate from the host side; the peripherals are totally
dependent.
The following sections on USB system software describe the various components of
USB support in Windows CE. The primary goal of USB support provided by
Microsoft, aside from enabling IHVs to write device drivers for USB devices, is to
help OEMs expand existing USB support on their platforms. Windows CE also has
device-side support, which enables Windows CE–based platforms to serve as USB
peripherals to other USB hosts. The Windows CE Platform Builder contains sample
code implementing device-side support.
Built on Wednesday, October 04, 2000
Send feedback to MSDN. Look here for MSDN Online resources.
Testing USB Device Drivers
There is no extensive USB test suite for Windows CE at this time. The sample USB
HID driver and the USB 8x930Ax peripheral kit and evaluation board from Intel
Corporation can be used to assist in testing USB scenarios. These are the methods
used at Microsoft to test the USB system software for Windows CE. Further details
on testing a USB system and the device drivers on an OEM platform are available in
the Windows CE Platform Builder.
USB Topology
USB is a tree-structured bus, which in the vocabulary of the Universal Serial Bus
Specification, Revision 1 is a star-tier topology. The host computer contains a single
root node, or hub, of the USB tree. This hub mediates between its host computer and
any peripheral devices. Hubs have exactly one connection—called an upstream port—
to higher levels in the USB tree. Hubs can have up to 64 downstream ports for
connecting peripheral devices and other hubs. By connecting hubs together, up to
127 total devices, including hubs, can be attached to the host computer. Peripheral
devices are always leaf nodes within a USB bus. However, as a matter of practical
implementation, many USB peripheral devices have hubs integrated into them, so
users typically do not need to purchase separate USB hubs.

The following illustration shows a USB bus with several common peripherals
connected. This illustration is modeled after the diagram of a typical USB bus
configuration in the Universal Serial Bus Specification, Revision 1, but with the
hubs and peripheral devices represented more explicitly.
The association of the mouse with the keyboard’s internal hub and the speakers with
the monitor’s internal hub is arbitrary. For example, a user could instead connect the
mouse to the monitor’s internal hub, the modem to the keyboard’s internal hub, and
the speakers to the stand-alone hub in Tier 1 without affecting the system’s
functionality and without having to reconfigure any software on the host computer.
USB devices and their corresponding USB device drivers should behave identically
regardless of the specific bus topology.
Built on Wednesday, October 04, 2000
Send feedback to MSDN. Look here for MSDN Online resources.
USB Transfer Types
Windows CE 2.10 and later support all four types of data transfer defined in the
Universal Serial Bus Specification, Revision 1. Device drivers for USB devices can
use any of the following transfer types, as appropriate:
• Control transfers
Control transfers are bidirectional transfers that are used by the USB system
software mainly to query, configure, and issue certain generic commands to
USB devices. Control transfers typically take place between the host computer
and the USB device’s endpoint 0, but vendor-specific control transfers may
use other endpoints.
• Isochronous transfers
Isochronous transfers provide guaranteed amounts of bandwidth and latency.
They are used for streaming data that is time-critical and error-tolerant or for
real-time applications that require a constant data transfer rate. For example,
an Internet telephony application that carries a conversation in real time is a
good candidate for isochronous transfer mode. Isochronous data requires
guaranteed amounts of bandwidth and guaranteed maximum transmission

times. For isochronous transfers, timely data delivery is much more important
than perfectly accurate or complete data transfer.
• Interrupt transfers
Interrupt transfers are used mainly to poll devices to check if they have any
interrupt data to transmit. The device’s endpoint descriptor structure
determines the rate of polling, which can range from 1 through 255
milliseconds. This type of transfer is typically used for devices that provide
small amounts of data at sporadic, unpredictable times. Keyboards, joysticks,
and mouse devices fall into this category.
• Bulk transfers
Bulk transfers are for devices that have large amounts of data to transmit or
receive and that require guaranteed delivery, but do not have any specific
bandwidth or latency requirements. Printers and scanners fall into this
category. Very slow or greatly delayed transfers can be acceptable for these
types of device, as long as all of the data is delivered eventually. However, in
the absence of any other demands for bus bandwidth, Windows CE processes
bulk transfers as quickly as possible.
Note: Windows CE 2.10 and later have limits on the amounts of data per transfer. All
data transfers using USBDI transfer functions are limited to 8K of data per transfer,
due to an internal limitation in Microsoft’s USB implementation. If you are porting
USB client drivers from Microsoft Windows NT, Windows 95 or Windows 98, you
may need to make changes in your code to enforce a limit of 8K per transfer.
Writing USB Device Drivers
This section describes how to write device drivers for USB devices running on
Windows CE. USB device drivers exist to make the services of peripheral devices
available to applications. Although there are no standard mechanisms that USB
devices must use to accomplish this, there are various strategies that USB device
drivers can adopt, depending on the nature of the peripherals that they control:
• Use the stream interface functions
A USB device driver can expose the stream interface functions. Applications

can then treat the peripheral device as a file and use standard file I/O functions
to interact with the device. However, because the Device Manager is not
involved in the loading and unloading of USB device driver s, any driver that
exposes the stream interface functions must register and deregister its special
device file name manually, using the ActivateDevice and DeactivateDevice
functions. These functions should be called when the USB device driver is
loaded and unloaded, respectively.
• Use existing Windows CE application programming interfaces (APIs)
USB device drivers can indirectly expose certain types of peripherals to
applications if Windows CE has an existing API that is appropriate to the
peripheral. For example, USB device drivers for mass storage devices, such as
hard drives and CD-ROM drives, can expose such devices through the
standard installable file system interface. Similarly, a USB mouse device could
use this strategy. The driver would not expose the mouse device directly to
applications; rather, it would interact with existing Windows CE APIs to
submit the correct input events to the system. Thus, the USB nature of the
mouse device is transparent to applications.
• Create a custom API specific to a particular USB device driver
This strategy does not place any restrictions on the way that a USB device
driver exposes a device. It allows you to create an API for the device that best
maps to the ways that applications are likely to use it. However, you must
provide appropriate documentation to application writers so that their
applications can use the driver.
Built on Wednesday, October 04, 2000
Common Driver Problems
The following are descriptions of common driver problems and issues:
• The attach and detach functions should never go into infinite loop—or, hang. If
a function does hang, no more USB device drivers can be loaded and it appears
that the USB cannot enumerate the devices.
• The attach and detach functions should take as little time as possible. If it

takes too long, the UI application may become confused and think that the
device is unplugged during ‘ignition off’ and plugged back in after ‘ignition
on’.
• The device driver should implement external thread entrance/exiting counting.
Since the USB client device driver DLL can be unloaded at any time—‘ignition
off’ can occur at any time—any external thread that is executing inside the
DLL at the time may be terminated and cause an exception in the calling
applications. To avoid this, thread counting must be implemented in most
functions—especially those _Read, _Write and IoControl—that could be called
by other threads. And, the detach function must wait until the thread count
goes to zero before returning.
• When calling USB::IssuexxxTransfer function with a completion callback
function, the callback function simply calls SetEvent and returns.
• In the detach function, the client driver should call
UnregisterNotificationRoutine. The notification is identified by both the
callback address and the parameter. So, you must unregister with the same
parameters you used to register the notification.
• In Windows CE 2.12 or earlier, there is a performance bug related to
manual–reset event. Don’t use a manual–reset event in time–critical
threads.
• The attach/detach function should not call IssuexxxTransfer function.
Built on Thursday, January 25, 2001
Components of USB
The foundation for a test approach requires a basic understanding of functional
dependency and relationships. However, the order in which to go about beginning the
actual approach may differ from the order of logical dependency. A tip in starting is
to approach testing USB from a user point of view, keeping in mind the coverage of
the logical and physical integration and cross–dependencies, in order to affirm
completeness in coverage. The information in the following paragraphs encourage
the creation of a simple test approach.

The following diagram shows the USB architecture for an automotive computing
device:
Transfer Types
USB supports the 4 basic transfer types listed below. For more information, see
Further Reference_apctest_Further_Reference.
• Interrupt (Keyboard, Legacy)
• Bulk (CUE®, Vetronix® Box)
• Isochronous (CD Changer)
• Control (All)
Built on Thursday, January 25, 2001
How WCEfA USB is different from Desktop
PCs
The primary differentiating factor between WCEfA USB and Desktop PC USB is the
type of physical connector. Automotive computing devices use the Hiroshi type
connector. In addition to the data and 5 volt power, this connector provides the 12
volts typically found in the car environment.
In the car environment, the USB chain experiences high frequency power cycles from
the root node. To attach a function, use the USBDeviceAttach function in the USB
client driver. To detach a function, use the USB_CLOSE_DEVICE handler of the
USBDeviceNotifications function in the USB client driver.
The following list describes hardware actions and the expected response for each:
• Warm boot – the attach function is called.
• Hot unplug – the detach function is called.
• Hot plug in– – the attach function is called if the device driver is already
registered.
• Ignition Off/Faceplate Detached – nothing is called.
• Unplug and Plug during Ignition Off – nothing is called.
• Ignition On/Faceplate Attached – the USB host controller enumerates all the
USB devices connected. A thread—with the highest priority—will call the detach
function of each loaded device driver, one by one. The same thread will call

the attach function for all the currently connected device drivers, one by one,
if the device driver is registered.
Built on Thursday, January 25, 2001
Send
USB Configurations
A USB network is composed of a master host computer that is connected to slave
USB devices. These devices may have a single function, such as a cell phone, or may
contain a hub connection that allows other USB devices to be chained to them. This
creates a tiered-star architecture that may be expanded to multiple levels. Examples
include the following:
A USB network may support up to 127 devices. This limit is due to the device
address field being limited to 7 bits.
The Auto PC is limited to four tiers and only one hub below the host hub. This
counts the Auto PC as the first tier with three layers below it.
Built on Thursday, January 25, 2001
Send feedback to MSDN. Look here for MSDN Online
USB Connectivity
USB offers a reliable, high-speed alternative to a standard serial port for connecting a
Windows CE-based platform to a desktop computer. Windows CE 2.10 and 2.12,
however, could not support USB connectivity to desktop systems, unless an OEM
implemented that functionality.
Windows CE 3.0 and later, however, do offer connectivity through USB. Windows
CE 3.0 and later provide a USB Function controller driver for Windows CE-based
platforms that include the appropriate USB Function controller hardware. By means
of this driver, the USB Function controller hardware appears to Windows CE as a
virtual serial port. Similarly, the desktop computer must have a similar host-side USB
serial driver. With the Windows CE-based platform and the desktop computer so
configured, the standard serial-port based mechanisms for connectivity can be used
over a USB connection. OEMs can find the files necessary for implementing USB
connectivity in the platform\cepc\drivers\serial_sl11\ directory of their Microsoft

Windows CE Platform Builder installations. These files support the Scanlogic
Corporation’s SL11 USB Function controller chipset. For complete information on
implementing a virtual serial port via USB on a Windows CE-based platform, see
Sample USB Function Controller Driver.
There is, however, still no support for making a Windows CE–based platform itself
appear as a USB peripheral to other host computers. This is because Windows CE
only implements the host side of the USB client/host architecture. That is, the HCD
and USBD modules supplied in Windows CE do not provide facilities to connect a
Windows CE–based platform to a desktop computer that is running as a USB host.
An OEM could implement this functionality if desired, although, as with the above
connectivity scenarios, the Windows CE-based platform would still require USB
Function controller hardware.
Built on Wednesday, October 04, 2000
Send feedback to MSDN. Look here for MSDN Online resources.
USB Connector
The connectors on the reference platforms are the standard 4-pin USB type intended
for the desktop environment and are only used during development and testing.
The Auto PC reference hardware documentation refers to an eight-pin connector
designed by Hirose (part number GT17-8DP-DS) and meant for a car’s high-
vibration and wide-temperature-range environment. The pinout is as follows:
Pin Number Pin Function
1 +5V
2 Data -
3 Data +
4 GND
5 GND
6 Wakeup2
7 Remote Power
8 +12V Main battery
Two wires are used for the USB standard serial data bus. This data bus is shared by

the Auto PC and its USB slave devices. The data rate is typically 12 megabits per
second (Mbps), but there is an optional 1.5 Mbps mode. In accordance to the USB
standard, the data is differentially driven to improve noise immunity.
The USB connector can also supply power to the hubs and devices on the USB
network. While some devices are self-powered from their own power supplies, others
pull power from the USB connector. The Auto PC USB connector supplies two power
sources of +5V and +12V.
The +5V supply is specified by the USB standard and is required to provide a
maximum of 600 mA continuous.
The +12V line is added by the Auto PC design and continuously supplies a
maximum of 3 A.
The Auto PC USB connector also adds two signal lines for use in wakeup modes
(labeled Wakeup2 and Remote Battery). The OEM system designer can use these
signal lines to allow USB peripherals to signal the Power Management System to
trigger a power event. This allows the Auto PC to transition from a powered-down
state to a partial-power state to process information from the USB peripheral; for
example, to store a page message. See the Power Management specification for
more information.
Built on Thursday, January 25, 2001
Requirements for the Generic Bus Driver
Model
Microsoft Corporation
December 1998
This article is intended for hardware device designers for all operating systems, not
just the Microsoft® Windows® 98 and Windows 2000 operating systems. It describes
a generic model for device enumeration that can be performed by any operating
system to discover and enable the hardware devices it finds on a platform. This
generic model imposes design requirements for hardware devices that run on the
platform: devices must be discoverable, self-describing, and multiplexable.
Universal Serial Bus (USB) devices are examined in this article to determine how

well they correspond to this generic model and meet these device design
requirements. However, these ideas are not specific to USB; they can be applied to
other buses.
In general, all operating system designers strive to meet these goals:
• Provide an enhanced user experience. An operating system is successful
from the users' point of view if the system is easy to use and easy to upgrade.
• Enable multiple devices from multiple Independent Hardware Vendors
(IHVs) to run transparently. An operating system is successful from the
hardware vendors' point of view if the operating system treats equally all
devices running on the platform. The operating system must allow a device to
run on a platform regardless of the device class, device manufacturer, and
presence or absence of any other particular device on the platform.
• Facilitate development of IHVs software. Ideally, IHVs would not have to
write a device driver for their device to run on the platform. If a driver is
required, it should consist of a small amount of code with the simplest logic
possible.
This article describes two types of operating systems, arbitrarily called "Type 1" and
"Type 2," and compares how well they meet the three goals in relation to hardware
configuration.
How a Type 1 Operating System Searches for Hardware
Devices
A Type 1 operating system loads drivers on speculation and expects the driver code
to search for its own hardware. The loaded driver searches for its hardware using a
device-specific method that typically touches all the devices already installed on the
platform. Problems with this method are:
• Detection methods used by drivers might conflict with hardware already
installed on the platform. For example, if a platform has a drill press installed,
the detection method used by a newly installed driver could inadvertently start
up the drill press, causing material damage.
• Detection methods can inadvertently detect a device other than the one the

loaded driver controls.
• This method requires the operating system to load all possible drivers.
• When loaded, the driver must assume its hardware is present; however, drivers
are loaded whose hardware is not present.
• Hot plugging and unplugging of devices is not quick or easy.
This list shows that a Type 1 operating system does not promote the two higher
priority operating system design goals: enhanced user experience and interoperability
of devices.
A Type 1 operating system might promote the lowest priority goal: it can be easier
for IHVs to write drivers for their devices because the driver logic assumes the IHV's
device is present whenever the driver is invoked, and the driver simply begins using a
device. However, this simplifying assumption can lead to some of the problems listed
that do not promote the higher priority goals of a good user experience and
interoperability of devices.
How a Type 2 Operating System Searches for Hardware
Devices
A Type 2 (Plug and Play) operating system uses components called "bus drivers"
each time the system boots to discover and enable the hardware devices currently
installed on the platform. If the bus supports it, bus drivers can also handle hot
plugging and hot unplugging of devices between boot events.
A Type 2 operating system promotes the higher priority operating system design
goals.
• The user experience is enhanced because the operating system automatically
adjusts to hardware configuration changes and can easily handle hot swapping
of devices.
• Interoperability of devices on the bus is promoted because functions on the
bus can come from multiple IHVs and generic extensions are possible at any
time.
Generic Bus Driver Model
Each bus driver sees its bus in a simple, general way: some number of "functions" is

currently attached to the bus, which the bus driver owns. All functions look alike to a
bus driver. See Figure 1.
Figure 1. Generic bus driver model
In this model, the bus driver discovers hardware functions first, then loads drivers
only as they are needed. The bus driver can even prompt the user when it discovers a
device and finds no driver is installed for that device. To keep it simple, the bus
driver maps each function to one driver (there is a one-to-one mapping of a hardware
function to a loaded device driver). To select the driver to load, the bus driver
requires no device-specific information and no information about what other
functions are currently attached to the bus.
The generic bus driver that enables a Type 2 operating system has the following
characteristics:
• A bus driver sees its bus in a simple, general way. For a bus driver, there
are no device class dependencies. The membership of an attached function in
one device class or another (for example, storage, audio, input, and so on) is
transparent to the bus driver.
• A bus driver discovers all functions using the same method. Specifically,
and most importantly, the bus driver requires no knowledge of what functions
are already on the bus, or their state, to discover another function. A simple
example of this is shown in Figure 2, where functions "X" and "Y" are shown
enclosed in one hardware device container; however, the bus driver does not
need to know anything about "X" to discover "Y" and vice versa.
• A bus driver creates an abstraction (in the form of a data structure) for
each function it discovers. The driver that the bus driver loads to control the
discovered function uses this abstraction to access its function.
• A bus driver does not load a driver for a function not currently attached
to the bus.
Figure 2. Generic bus driver model when two functions are contained in one
device
Bus Driver and Device Requirements for a Generic Driver

Model
Bus driver code does the following:
• Discovers ("enumerates") all functions on the bus.
• Determines the capabilities of each function. For example, what resources,
such as I/O ports, memory ranges, IRQ ranges, power, and/or bandwidth, can
the function use? What driver(s) can control the device?
• Loads a driver for each function it discovers.
• Gives each function a unique structure or handle (provides an abstraction that
allows the loaded driver to access its function).
For a device, or function, to participate in the generic bus driver model, it must be:
• Discoverable - When the function is attached to the bus, it can be found by the
bus driver.
• Self-describing - The function must describe itself to the bus driver so the bus
driver can find a driver to load.
• Multiplexable - Each function must be individually controllable with no cross-
dependencies between functions (access to one function does not require
knowledge of another function's state or access to another function).
Applying the Requirements to USB Devices and Interfaces
Some USB device designs fit the generic bus driver model by meeting the
requirements of discoverability, self-description, and multiplexability. Other USB
device designs do not fit the model, with consequences described in the following
section.
Note USB hardware functions are described either at the device level (in the device
descriptor) or at the interface level (in an interface descriptor).
Simple USB devices meet all three requirements for participating in the generic bus
driver model:
• Discoverable - Each device plugs into one USB port.
• Self-describing - The device descriptor in ROM describes the device.
• Multiplexable - Each device has a unique USB address.
Most USB devices can be further enumerated by functional interface, beyond the

simple device itself. USB devices of this type may not meet the requirements of
discoverability and multiplexability.
• Discoverable - If special information is required in descriptors to group
interfaces into functions, this is a problem for a generic bus driver.
• Self-describing - The interface descriptor in ROM describes the function to a
generic bus driver, so there is no problem.
• Multiplexable - If a function cannot be controlled independently of other
functions, this is a problem for a generic bus driver.
Examples of Problems with Some USB Devices
The USB Audio class specification requires multiple, interacting interfaces to
perform a single function. This means the USB bus driver must "discover the
function" by lumping together some predetermined set of interfaces, requiring Audio
class-specific information in the descriptors and Audio class-specific (special-case)
code in the USB bus driver. This special-case code means that not every function
looks the same to the USB bus driver.
The USB Communications class specification requires two interacting interfaces to
perform the single function of "legacy modem." The USB bus driver must contain
code that uses Communications class-specific information in the device descriptor to
recognize yet another special case. (See to obtain
current versions of USB Class Definition for Communications Devices, USB Device
Class Definition for Audio Devices, and USB Specification.)