Microsoft Windows Embedded CE 6.0 Exam Preparation Kit

Developing Bus-Agnostic Drivers

Similar to settings for installable ISRs, memory-mapped windows, and PCI device instance information, you can maintain any GPIO numbers or timing configurations in the registry and achieve in this way a bus-agnostic driver design. The underlying idea of a bus-agnostic driver is the support of multiple bus implementations for the same hardware chipset, such as PCI or PCMCIA, without requiring code modifications.

To implement a bus-agnostic driver, use the following approach:

1. Maintain all necessary configuration parameters in the driver's registry subkey, and use the Windows Embedded CE registry helper functions DDKReg_GetIsrInfo, DDKReg_GetWindowInfo, and DDKReg_GetPciInfo to retrieve these settings during driver initialization.

2. Call HalTranslateBusAddress to translate bus-specific addresses to system physical addresses and then call MmMapIoSpace to map the physical addresses to virtual addresses.

3. Reset the hardware, mask the interrupt, and load an installable ISR by calling the LoadIntChainHandler function with information obtained from DDKReg_GetIsrInfo.

4. Load any initialization settings for the installable ISR from the registry by using RegQueryValueEx and pass the values to the installable ISR in a call to KernelLibIoControl with a user-defined IOCTL. For example, the Generic Installable Interrupt Service Routine (GIISR) included in Windows Embedded CE uses an IOCTL_GIISR_INFO handler to initialize instance information that enables GIISR to recognize when the device's interrupt bit is set and return the corresponding SYSINTR value. You can find the source code in the C: Wince600PublicCommonOakDriversGiisr folder.

5. Begin the IST by calling the CreateThread function and unmask the interrupt.

Lesson Summary

To increase the portability of a device driver, you can configure the registry entries in the driver's registry subkey. Windows Embedded CE provides several registry helper functions that you can then use to retrieve these settings, such as DDKReg_GetIsrInfo, DDKReg_GetWindowInfo, and DDKReg_GetPciInfo. These helper functions query specific information for installable ISRs, memory-mapped windows, and PCI device instance information, yet you can also call RegQueryValueEx to retrieve values from other registry entries. However, to use any of these registry functions, you must first obtain a handle to the driver's registry subkey by calling OpenDeviceKey. OpenDeviceKey expects a registry path, which Device Manager passes to the driver in the XXX_Init function call. Do not forget to close the registry handle when it is no longer needed.

Lab 6: Developing Device Drivers

In this lab, you implement a stream driver that stores and retrieves a string of 128 Unicode characters in memory. A base version of this driver is available in the companion material for this book. You only need to add the code as a subproject to an OS design. You then configure .bib file and registry settings to load this driver automatically during boot time and create a WCE Console Application to test the driver's functionality. In a last step, you add power management support to the string driver.

NOTE

Detailed step-by-step instructions

To help you successfully master the procedures presented in this Lab, see the document 'Detailed Step- by-Step Instructions for Lab 6' in the companion material for this book.

> Add a Stream Interface Driver to a Run-Time Image

1. Clone the Device Emulator BSP and create an OS design based on this BSP as outlined in Lab 2, 'Building and Deploying a Run-Time Image.'

2. Copy the string driver source code that you can find on the companion CD in the LabsStringDriverString folder into your BSP folder in the path %_WINCEROOT%Platform<BSPName>Src Drivers. This should result in a folder named String in your platform in the Drivers folder, and immediately inside this folder you should have the files from the driver on the companion CD, such as sources, string.c, string.def. It's possible to write a driver from scratch, but starting from a working example such as this is much quicker.

3. Add an entry to the Dirs file in the Drivers folder above your new String folder to include the string driver into the build process.

CAUTION

Include In Build option

Do not use the Include In Build option in Solution Explorer to include the string driver into the build process. Solution Explorer removes important CESYSGEN directives from the Dirs file.

4. Add an entry to Platform.bib to add the built string driver, contained in $(_FLATRELEASEDIR) , to the run-time image. Mark the driver module as a hidden system file.

5. Add the following line to Platform.reg to include the string driver's .reg file into the run-time image's registry:

#include '$(_TARGETPLATROOT)SRCDRIVERSStringstring.reg'

6. Build the string driver by right clicking it in Solution Explorer and selecting Build.

7. Make a new run-time image in Debug mode.

NOTE

Building the run-time image in Release mode

If you want to work with the Release version of the run-time image, you must change the DEBUGMSG statements in the driver code to RETAILMSG statements to output the driver messages.

8. Open the generated Nk.bin in the flat release directory to verify that it contains String.dll and registry entries in the HKEY_LOCAL_MACHINEDriversBuiltInString subkey to load the driver at startup.

9. Load the generated image on the Device Emulator.

10. Open the Modules window after the image starts by pressing CTRL+ALT+U, or open the Debug menu in Visual Studio, point to Windows, and then select Modules. Verify that the system has loaded string.dll, as illustrated in Figure 6-11.

Figure 6-11 Modules window with loaded string driver

> Access the Driver from an Application

1. Create a new WCE Console Application subproject as part of your OS design by using the Windows