Tài liệu USB Architecture pptx

z













USB
Architecture

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, Group
X
_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 Group
X
_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.

The image cann ot be displayed . Your c omputer may not have en ough memor y to op en the image, or the image may hav e been cor rupted. Restart y our co mputer, and then open the file ag ain. If the red x still appears, you may h ave to delete th e image and then insert it again.

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
Devic
A Type
each tim
installed
pluggin
A Type
goals.
•
T
a
s
w

• I
n
b

ti
Gener
Each bu
is curren
to a bus

Figure
1
In this m
only as
a devic
e
driver m
hardwar
driver re
function
The gen
characte
• A
n
o
tr

a Type
ces
e 2 (Plug a
me the sys
d on the p
ng and hot u
e 2 operati

The user ex
djusts to
wapping
nteroperab
bus can com
ime.
ric Bus D
us driver se
ntly attach
s driver. Se
1. Generic
model, the
they are n
e and finds
maps each
re function
equires no
ns are curre
neric bus d
eristics:
A bus drive
no device c
one device
ransparent
e 2 Ope
and Play) o
tem boots
platform. I
unplugging
ng system

xperience i
hardware
bility of de
me from m
Driver M
ees its bus
hed to the b
ee Figure 1
bus drive
r
e bus drive
needed. The
s no driver
h function
n to a load
o device-sp
ently attach
driver that
er sees its b
class depen
class or an
erating
operating s
to discove
If the bus
g of device
m promotes
s enhance
d
configura

vices on th
multiple IHV
Model
s in a simp
bus, which
.
r model
er discover
e bus drive
r is installe
to one d
ded device
ecific inf
o
hed to the
t enables a
bus in a sim
ndencies.
nother (for
to
System
system use
er and ena
supports i
es between
the highe
d because
ation chan
of
he bus is p

Vs and gen
le, general
the bus dr
s hardware
er can even
ed for that
driver (the
driver).
T
ormation an
bus.
a Type 2 o
mple, gene
The memb
r example,
the
Search
es compon
able the har
it, bus driv
n boot even
er priority
the operat
i
nges and
promoted b
neric exten
l way: som
river owns
e functions

n prompt th
t device. To
re is a on
To select th
nd no infor
operating s
eral way. F
bership of
storage, a
u
hes for
ents called
rdware dev
vers can a
nts.
operating
ing system
can easil
because fu
nsions are p
me number
. All funct
s first, then
he user wh
o keep it s
ne-to-one
he driver to
rmation ab
system has
For a bus d

f an attach
udio, input
bus
Hardw
d "bus driv
vices curre
lso handle
system de
m automatic
ly handle
de
v
unctions on
possible at
of "functi
ions look a
n loads dri
hen it disco
simple, the
mapping
o load, the
bout what o
s the follow
driver, there
hed functio
t, and so o
dr
ware
vers"
ently

e hot
esign
cally
hot
vices.
n the
t any
ions"
alike
ivers
overs
e bus
of a
e bus
other
wing
e are
on in
on) is
river.
• A
m
a
e
s
h
d

•
A

fu
d

•
A
th

Figure
2
Bus D
Mode
Bus driv
• D

•
D
su
th

•
L

•
G
th
For a de
• D
th

•

S
b

A bus drive
most impor
lready on
xample o
f
hown encl
does not ne
A bus drive
unction it
discovered
A bus drive
he bus.
2. Generic
Driver a
el
ver code do
Discovers
Determines
uch as I/O
he funct
Loads
Gives each
hat allows
evice, or fu
Discoverabl
he
Self-describ

bus d
er discover
rtantly, the
the bus,
o
f this is sh
losed in on
eed to kno
er creates a
discovers
function
er does no
bus driver
and Dev
oes the foll
("enum
s the capab
ports, mem
tion use?
a driv
function
the loade
d
unction, to
le - When
bing - The
river
s all functi
bus driver
or their st

hown in F
ne hardwar
ow anythin
an abstract
. The driv
uses th
ot load a dr
r model wh
vice Req
lowing:
merates")
bilities of e
mory range
? What
ver for
a unique
d driver to a
participate
the functi
e function
can
ions using
r requires n
tate, to dis
Figure 2, w
re device
ng about "X
tion (in the
ver that th
his abstra

river for a
hen two fun
quireme
all
each funct
es, IRQ ran
driver(s
r each
structure
o
access its f
e in the gen
ion is attac
bus
must des
c
find
the same m
no knowled
scover ano
where fun
container;
X" to disco
e form of a
he bus driv
action to
a function n
nctions are
ents for
functions

tion. For e
nges, powe
) can
funct
i
or handle
function).
neric bus d
ched to the
cribe itself
a
d
method. Sp
dge of wha
other funct
nctions "X"
however,
over "Y" a
a data struc
ver loads
access
not curren
e contained
a Gene
on
example, w
er, and/or b
control
ion it
(provides

driver mode
e bus, it ca
to the bus
driver
pecifically,
at function
tion. A sim
" and "Y"
the bus dr
and vice ve
cture) for
to contro
l
its func
ntly attache
d in one de
eric Dri
the
what resour
bandwidth,
the dev
discov
an abstrac
el, it must
an be foun
d
r
s driver so
to l
, and

s are
mple
" are
river
ersa.
each
l the
tion.
ed to
vice
iver
bus.
rces,
, can
vice?
vers.
ction
be:
d by
river.
o the
load.