Supported USB Features (Windows CE 5.0)
The Windows CE USB implementation supports bus enumeration, transfer types, client drivers, integrated and external hubs, desktop connectivity, unknown universal serial bus (USB) peripherals, and power management.
Bus Enumeration
The bus enumeration process proceeds in the following sequence:
The HCD module acquires information from a connected device, and then assigns it a unique USB address.
The HCD module sets a configuration value to enumerate the device.
At this point, the device is configured and ready to conduct, transmit, and receive transactions.
The USB driver 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.
Transfer Types
All four types of data transfer defined in the Universal Serial Bus Specification are supported. USB device drivers can use any of the transfer types that are appropriate for the endpoints of their peripherals. For more information, see USB Transfer Types.
Client Drivers
The USB architecture implemented for Windows CE supports loading client drivers. Examples of USB device classes include the human input device (HID) class and the mass storage class. You can write your own client drivers and load them appropriately. For more information, see USB Host Client Drivers.
Integrated and External Hubs
Windows CE supports integrated and external hubs up to five levels deep. This is the maximum allowed by the Universal Serial Bus Specification.
Unknown Peripherals
Unknown USB peripherals generally cause no problems in Windows CE.
Desktop Connectivity
Windows CE provides a USB function controller driver for Windows CE-based devices and desktop computers that includes the appropriate USB function controller hardware. When you use this driver, the USB function controller hardware sees the USB port on the device or the desktop computer as a virtual serial port. To use this driver on a desktop computer, you must have a host-side USB serial driver. With the device and the desktop computer configured this way, standard serial ports can be used over a USB connection.
Windows CE provides no support for a device to appear as a USB peripheral to other host computers. This is because only the host side of the USB client and host architecture is implemented. That is, the host controller driver (HCD) and USB driver modules that Microsoft supplies do not allow you to connect a device to a desktop computer that is running as a USB host. You could implement this functionality, but the hardware platform would still require USB function controller hardware. For more information, see USB Serial Host Driver and USB Function Controller Drivers.
Power Management
Windows CE provides support for bus-powered and self-powered devices. For both types of device, the USB driver module reads the power requirements of the device from the descriptor information and rejects the device if it exceeds the maximum power threshold. Because you can set the current-draw limit, you should not rely on any particular amount of available current, except as detailed in the Universal Serial Bus Specification.
USB hubs enforce current-draw limits, not the host computer. The hub shuts down devices that draw too much current. Hubs that cannot control the power level on individual ports might shut down all their ports or might be forcibly shut down by an upstream hub when a current over-draw situation occurs. Shutting down can cause multiple USB devices to disconnect from the bus if a single device draws too much current.
Complex power saving modes or partial-power modes are not supported for USB devices when the host hardware platform is suspended. Instead, the entire bus shuts down. During the suspend and resume power states, you can choose whether USB controllers should stay powered up or not. If an you choose to have remote wakeup on a USB device and the controller has this functionality, the controller will work in the suspend and resume states. Otherwise, the entire bus shuts down.
USB device drivers might 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. One solution is for the USB device driver to register itself with the Device Manager by exposing the stream interface and calling the ActivateDeviceEx function. This increments the reference count on the USB device driver's dynamic-link library (DLL) so that when the USB driver module unloads the driver, the driver's code remains in memory. The USB device driver can 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 and keep the file system driver code which manages file handles separate from the USB device driver code that actually manages the storage hardware.
The platform dependent driver (PDD) for the USB host controller can either shut down or go into suspend mode during system shut down. When in suspend mode, the host controller is capable of waking the system up using USB devices that support remote wake-up.
See Also
Power Management | USB System Software | USB Host Controller Driver Architecture
Send Feedback on this topic to the authors