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 pc99@microsoft.com 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
Không có nhận xét nào:
Đăng nhận xét