Writing an HCD Module

To support USB on a Windows CE–based platform, OEMs must customize one of the HCD modules included with the Platform Builder. Microsoft provides sample HCD modules that work with OHCI-compliant and UHCI-compliant USB host controllers. OEMs must port the PDD of the appropriate sample HCD to their platforms as part of their OAL implementations.

To reduce the effort involved in porting the sample HCD to your platform, the HCD is divided into two layers: a platform-independent MDD layer and a small hardware-specific PDD layer, like other native device drivers. As usual, OEMs need to port only the PDD layer. Furthermore, because the specifications for OHCI and UHCI hardware explicitly define the behavior of such hardware, the PDD layer does very little. The PDD layer for most HCD modules merely has to locate the hardware address of the host controller within memory and provide the MDD layer with the hardware address and a pointer to a shared memory area.

However, the MDD and PDD layers in the HCD module interact more than the MDD and PDD layers in most native device drivers. For example, in the majority of native device drivers, the MDD layer calls DDSI functions exposed by the PDD layer. In the HCD module, the MDD layer not only calls the DDSI functions, but also exposes a set of functions that the PDD layer must call at specific times during initialization.

OEMs must create a registry key within HKEY_LOCAL_MACHINE\Drivers\Builtin\ so that the Device Manager loads the HCD module when the platform starts. Device drivers that the Device Manager loads must expose some of the stream interface functions in order to get power management callbacks. Therefore, the PDD layer is required to include some additional functions, such as OhcdPdd_Open and OhcdPdd_IoControl, even though the HCD module is not purely a stream interface driver. The benefit of this approach is that the Device Manager calls the HCD module's OhcdPdd_Init function, which in turn enables the HCD module to call the required MDD functions. The following example shows the registry key for the HCD module; it should contain the same values as other stream interface driver keys.

[HKEY_LOCAL_MACHINE\Drivers\Builtin\OHCI]
  "Prefix"="HCD"
  "Dll"="ohci.dll"
  "Index"=dword:1
  "Order"=dword:1

The following list shows the MDD functions that the PDD layer must call:

The following list shows the DDSI functions exposed by the PDD layer:

OEMs whose platforms contain UHCI–compliant host controllers, instead of OHCI-compliant host controllers, have a similar porting task. OEMs need to include the following registry values under the key HKEY_LOCAL_MACHINE\Drivers\Builtin\UHCI so that the UHCD will be loaded when the system boots:

[HKEY_LOCAL_MACHINE\Drivers\Builtin\UHCI]
  "Prefix"="HCD"
  "Dll"="uhci.dll"
  "Index"=dword:1
  "Order"=dword:1
  "UseExistingSettings"=dword:0
  "Irq"=dword:<platform dependent>
  "MemBase"=dword:<platform dependent>
  "Priority"=dword:<platform dependent>

The UseExistingSettings key controls whether the values for Irq, MemBase, and Priority come from the system's BIOS settings, or whether they come from the registry. A value of 0 causes the BIOS setting to be used. Any other value causes the BIOS settings to be ignored in favor of the values specified in the Irq, MemBase, and Priority keys.

When the UHCD is loaded at boot time, it attempts to detect the presence of a UHCI-compliant USB host controller. The sample UHCD is only capable of detecting the Intel PIIX4 controller because of PCI bus values that are hard-coded into the UHCD. However, the detection function is available as source code to OEMs, who can change the function to detect other UHCI-compliant USB host controllers. The following table lists the values that the sample UHCD uses to identify the Intel PIIX4 controller:

Note   The sample HCD included with Windows CE 3.0 only supports one UHCI chip on a system.

The UseExistingSettings key has no effect on Windows CE 2.11 for the CEPC, for which the HCD module supplied by Microsoft has a pre-defined address hard coded into it for the host controller. In Windows CE 2.12 and later, the HCD module obtains the host controller interface settings dynamically according to the UseExistingSettings key as described above. The default value of the UseExistingSettings key can also be controlled on your development workstation through the environment variable CEPC_USB_USE_EXISTING; if you set this variable to a new value, you do not need to rebuild the HCD module; you only need to run the Makeimg utility to cause the new value to be incorporated into your operating system image. Fundamentally, Windows CE cannot reconfigure PCI devices dynamically; thus, if UseExistingSettings is set to 0, the USB host controller interface settings in the CEPC system's bios must match those in the CEPC system's registry, or else the HCD module will not load. If the two do not match, you can use another operating system on your CEPC, such as Windows 95, to check the BIOS settings, and then update your platform.reg file with the correct addresses and IRQ information. Alternately, you can watch the debug output while the CEPC system boots, which should report an error that contains the BIOS settings, as follows:

!OHCD: Configuration different from registry: IRQ %u, PortBase: 0x%X (reg: %u, 0x%X)

 Last updated on Tuesday, July 13, 2004

© 1992-2000 Microsoft Corporation. All rights reserved.