Many Windows CE-based platforms must connect to desktop computers in order to exchange information through the Microsoft ActiveSync software. USB, with its high bandwidth, has the potential to be a much better option for desktop connectivity than the standard serial ports that ActiveSync historically relies on. The problem is that the USB architecture is fundamentally asymmetric with respect to the roles played by devices on either end of a USB cable. USB mandates that one device be the controlling host computer while all other devices are simple producers or consumers of data. The USB system software for both Windows CE and for the desktop versions of windows, Microsoft Windows© 95, Windows© 98, Windows© NT, and Windows© 2000, implements the host side of USB's client/host architecture. And as USB is architected, two hosts cannot directly connect in a meaningful way. This is a particular concern for some users since desktop computers that conform to the PC99 standard are "legacy free," and do not contain any standard serial or parallel ports, in favor of USB and other newer data exchange methods. Without a USB connectivity solution, Windows CE-based platforms are much less attractive to owners of PC99-compliant systems.

Windows CE versions 2.12 and earlier provided desktop connectivity through a standard serial port connection. In Windows CE 3.0, Windows CE-based platforms can also connect to desktop systems through a USB connection. In addition to providing for PC99-compliant systems, USB offers much higher bandwidth than a standard serial port connection. A special device driver permits connectivity between a desktop computer and a Windows CE based platform. This driver, called a USB function controller driver, uses the low level USB APIs to implement a virtual serial port, but a much faster one than standard serial ports. The desktop computer needs a similar driver, the USB Serial Host Driverto make its USB hardware appear as a virtual serial port. With both systems so configured, the ActiveSync software can operate through these virtual serial ports, and achieve connectivity over USB. This strategy is only possible for Windows CE-based platforms that include USB function controller hardware in addition to their usual USB host controller hardware (an OHCI or UHCI chip).

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. Unlike the situation for USB host controller hardware, in which there are two predominant standards (OHCI and UHCI), there is no prevailing standard for USB function controllers. The sample USB function controller driver supports the Scanlogic SL11 chip because of that chip's immediate availability in the marketplace. Scanlogic provides an evaluation board that can assist OEMs in adding USB function controller circuitry to their Windows CE-based platforms. OEMs should contact the Scanlogic corporation directly to obtain this hardware and support for it. Note that the SL11 chip does not provide a sense pin for detecting USB cable disconnect and reconnect events; this prevents the sample USB Function Controller Driver from properly responding to those events, which can cause Microsoft ActiveSync to improperly identify a Windows CE-based platform when the platform is disconnected and then quickly reconnected to a desktop computer.

OEMs are not required to use the SL11 chip in order to implement connectivity over USB simply because of that chip's market availability. OEMs can modify the sample driver to support any USB function controller that provides the following endpoints:

Microsoft strongly encourages OEMs to implement the optional interrupt transfer endpoint. The sample driver will work without it, but the desktop computer's response may be degraded while the Windows CE-based platform is connected to the bus, regardless of the level of data transfer between the desktop computer and the Windows CE-based platform. If endpoint 3 is available, the Windows CE-based platform can notify the desktop computer when there is data available, as opposed to the desktop computer needing to poll the Windows CE-based platform.

Ideally, the USB function controller driver would be able to present a fixed device class ID to the desktop computer so that the correct USB device driver would be loaded on the desktop computer when users connect their Windows CE-based platforms to the bus. However, the USB working group has not defined a device class ID for serial devices; a combination of vendor ID (VID) and product ID (PID) must be used instead. OEMs must obtain a VID from the USB working group. Procedures on obtaining a VID are available from the USB Web site. OEMs must also assign their Windows CE-based platforms unique PIDs. Note that PIDs are distinct from serial numbers; PIDs correspond to OEMs specific model numbers and not to individual devices. OEMs must also communicate their products' VID/PID pairs to Microsoft so that Microsoft can include these pairs in an . INFfile as part of the ActiveSync software. Then, when a user connects a USB function controller-enabled device to their desktop computer's USB port, the proper USB function controller driver will be loaded on the desktop computer, thus enabling ActiveSync to work over the USB link. In the absence of this method, OEMs must develop another method of delivering an .INFfile to the end user with their Windows CE-based platforms.

The sample USB function controller driver is very similar to the sample serial port driver, and so it exposes the same DDI and DDSI as the sample serial port driver. The DDI functions are the standard Windows CE communication APIs, and the DDSI functions match those used between the sample serial port driver's MDD and PDD layers. However, many of the DDSI functions are simple stubs, since the only necessary functions are the ones for sending and receiving data. The driver behaves as a typical NULL-modem driver, in that it sends appropriate DTR and RTS information to the desktop computer, and its DCD and DSR state follows the host computer's DTR and CTS state. This information is exchanged in special packets over the control endpoint. Furthermore, because of the nature of USB, the driver does not support the concept of a "baud rate." For legacy reasons, the driver will allow the user to set a baud rate, but that setting has no impact on the driver's operation.

---

 Last updated on Tuesday, July 13, 2004

© 2004 Microsoft Corporation. All rights reserved.