Changes to Device Drivers

Article
06/30/2006

The following sections discuss issues to consider when migrating a device driver to Windows CE .NET 4.2.

IOCTL_HAL_TRANSLATE_IRQ not supported

Effective with version 4.1, the IOCTL_HAL_TRANSLATE_IRQ IOCTL, which the OEMIoControl function used to map interrupt requests to system interrupts (SYSINTR) is no longer supported. Drivers should replace this IOCTL with IOCTL_HAL_REQUEST_SYSINTR.

ActivateDeviceEx

Use ActivateDeviceEx to load all your device drivers. You can use ActivateDevice, but it simply calls ActivateDeviceEx. Do not use RegisterDevice to load drivers.

Audio Driver Migration

Effective with Windows CE .NET version 4.0, a different default size is used for waveform audio buffers than in Windows CE 3.0 and earlier. The new default size is 2 KB. Users may hear distortions if the size of the wave buffers that an application produces does not match the size of the buffers that the driver expects. For more information about how to adjust the driver settings, see Audio Drivers Registry Settings.

New Microsoft DirectSound® and audio mixer extensions are available that offer improved sound quality over the waveform audio drivers.

Note Support for DirectSound hardware abstraction layer (HAL) drivers has been discontinued in Windows CE .NET. The DirectSound driver functionality is now handled by the DirectSound extensions that are part of the Unified Audio Model.

For more information, see Audio Drivers and the Ensoniq sample driver source code located in the %_WINCEROOT%\Public\Common\Oak\Drivers\Wavedev\Unified\Ensoniq directory.

Display Driver Migration

You may receive linker errors while migrating a display driver from Windows CE .NET 4.1 to Windows CE .NET 4.2. As of Windows CE .NET 4.2, Sysgen variables replace the Ctblt.lib and Emul.lib static libraries, as shown in the following table.

Windows CE .NET 4.1 library	Windows CE .NET 4.2 Sysgen variable
Ctblt.lib	SYSGEN_GPE_CLEARTYPE
Emul.lib	SYSGEN_GPE_NOEMUL

To fix a linker error, you may need to set the value of the SYSGEN_GPE_CLEARTYPE or SYSGEN_GPE_NOEMUL variables to 1.

Battery Drivers

Applications can continue to use the battery functions without modification. However, you should be aware of the following:

If you are using a custom Cesysgen.bat file, rather than an Hlbase- or Iabase-based file, set the %COREDLL_COMPONENTS% environment variable to contain the Battery component and set the %CE_MODULES% environment variable to contain the Battdrvr Sysgen target.
The battery functions are ready to use when the SYSTEM/BatteryAPIsReady event is signaled. This event is defined as BATTERY_API_EVENT_NAME in Battery.h.
The battery driver must advertise the {DD176277-CD34-4980-91EE-67DBEF3D8913} GUID, preferably in the driver's IClass subkey. This GUID is defined as BATTERY_DRIVER_CLASS in Battery.h. Drivers that advertise this interface must support the IOCTLs listed in Battery.h.
A sample null battery driver is provided in the %_WINCEROOT%\Public\Common\Oak\Drivers\Battdrvr directory. The Battdrvr Sysgen target automatically links this driver to the platform.
The battery driver is divided into a Model Device Driver (MDD) and a Platform Dependent Driver (PDD). The Battdrvr_lib library implements the MDD and includes a sample PDD. To implement an actual PDD, implement all of the PDD entry points in Sbattif.c in your platform and link with the MDD.
For a sample battery driver, see %_WINCEROOT\Platform\Xsc1bd\Drivers\Battdrvr.

To move an existing battery driver out of the \GWES directory:

Add battdrvr to %_WINCEROOT%\Public\Common\OAK\Drivers\Dirs.
Copy source and header information from \GWES\Battery into %_WINCEROOT%\Public\Common\OAK\Drivers\Battdrvr.
Copy %_WINCEROOT%\Platform\Xsc1bd\Drivers\Battdrvr\Sources along with Makefile and Battdrvr.def to %_WINCEROOT%\Public\Common\OAK\Drivers\Battdrvr.
Edit the Sources file as appropriate for your sources. For example, you should change the file name and include the path.
Edit the battery sources to supply the new APIs required by the MDDs. When the platform's battery driver contains object files that list all of the entry points currently provided by Sbattif.c in the MDD, the linker includes the platform code rather than Sbattif.obj in the final executable. This way, OEMs can link their own PDD with the battery driver library created in public, which serves as both a sample driver and as an MDD.
Add .bib and .reg entries for the new drivers, using any of the sample platforms as a guide. Search for BATTDRVR in Platform.bib and Platform.reg for examples.
If your battery driver shares resources with any other drivers and previously relied on the fact that GWES was loaded later than installable drivers, adjust the driver load order in the registry appropriately. For more information, see Device Driver Loading Model in this topic.

CSP and Common Drivers

Windows CE .NET provides the basic infrastructure to rapidly create a board support package (BSP) by reusing device drivers from a number of driver libraries. These libraries include the following:

CPU support package or CSP drivers for microprocessor-native peripherals and microprocessor-specific OAL functions. These drivers are in %_WINCEROOT%\Public\Common\Oak\Csp.
Common drivers for peripherals not integrated into the microprocessor, such as Ethernet, display, audio, storage, USB class devices, and so on. These drivers are in %_WINCEROOT%\Public\Common\Oak\Drivers and %_WINCEROOT%\Platform\%_TGTPLAT%\Drivers.

When developing a BSP, use these device drivers where applicable to minimize the amount of new source code that you have to write. When writing a device driver for your peripherals, model your driver on one of the samples.

For more information, see How to Create a Board Support Package.

Device Driver Loading Model

The device driver loading model provides a consistent loading architecture for all drivers, as follows:

During platform startup, the Device Manager loads the Registry Enumerator (RegEnum.dll). For more information, see Device Manager.
After enumerating the registry, the Registry Enumerator loads drivers for all built-in devices and all bus drivers it recognizes on the system. For more information, see Registry Enumerator.
Bus drivers are subsequently responsible for loading drivers for the devices on their buses. For example, the PCMCIA host controller driver loads drivers for all PC Card client devices.

Device-specific information such as PCMCIA resides in the appropriate bus driver, not in the Device Manager. This means that the PCMCIA bus driver should load PC Card client drivers, so update the registry entries accordingly.

Update your drivers to load under the new model. For more information, see Driver Loading Model.

Device Driver Threads

Windows CE .NET sets the environment variable IMGNOTALLKMODE=1. Therefore, your code should not assume that driver threads run in kernel mode. When your driver must access restricted space, include code similar to the following:

oldmode = SetKMode(TRUE);
DoSomething();
SetKMode(oldmode);

Device Interface Notifications

In Windows CE .NET, a device driver can send notifications to applications, services, and any other module in the system on the arrival or removal of a device interface. This is the equivalent of Plug and Play functionality. You should update your drivers to advertise their interface and send device notifications to the system. For more information, see Device Interface Notifications.

I/O Resource Manager

When the system boots, the Registry Enumerator enumerates the registry as set up by the OEM or the BSP developer and loads all the built-in devices based on this registry information. The I/O Resource Manager then tracks the current state of resources available in the system and manages all further I/O resource requests and allocations by bus drivers. This means that all bus drivers should request I/O resources from the I/O Resource Manager when they load a client driver for installable or other types of devices. For more information, see I/O Resource Manager.

Installable ISRs

Installable ISRs allow multiple devices to share interrupts. They also extend the ability to process the device in the ISR in addition to the interrupt service thread (IST). You can program an installable ISR in a language other than assembly. You should update the ISRs for your device driver if you want to allow interrupt sharing. If you need an installable ISR to recognize the device generating the input, you can use the Generic Installable ISR (GIISR.dll) sample in most cases.

For more information, see Installable ISRs, Installable ISRs with Drivers, and Shared Interrupts.

NDIS Driver Loading Model

To load NDIS miniports, use the new NDIS Driver Loading Model. For more information, see NDIS Driver Implementation Guide.

PCI Bus Driver

The PCI bus enumerator or the PCI bus driver removes unnecessary PCI specific code from the OAL and device drivers. To read bus address registers and interrupt information from the PCI configuration space header, use the registry information provided by the PCI bus driver instead of using driver code that scans the PCI bus. For information about what PCI code the OAL requires, especially if the debug device is on the PCI bus, see PCI Device Support.

To allow PCI enumeration of all PCI devices, update the registry for your platform. See the ARM Integrator BSP in %_WINCEROOT%\Platform\ARMIntegrator\Files for an example implementation.

Power Management

Implementing peripheral-level power management in your device drivers provides a great deal of flexibility to OEMs in controlling and managing the overall system-level power requirements of a device. Update your device drivers to be managed by the Power Manager by following these recommendations:

Implement the Windows CE stream interface in your driver.
Support as many device power states as possible in your driver to improve overall power management.

For more information, see Power Management.

Video Drivers

Effective with version 4.1, Windows CE .NET no longer supports 2-bits-per-pixel (bpp) video drivers and hardware. The lowest supported resolution is 8 bpp.

Share via