Monday, 2 April 2012

How to reduce driver development turn around time

Do you think that driver development under Windows CE is a time-consuming challenge? Ok, not all coders like twiddling with registers and interrupts - that's why we are here.
Under CE - and similar to other embedded operating systems - a 'normal' and therefore sometimes boring driver development cycle looks like that:

    1. Compile and link the driver dll from driver source

    2. Download and boot the modified image

    3. The OS loads the driver and you start debugging

    4. Go to 1 (Do not pass Go, do not collect $200)

Fortunately, there are some shortcuts in this cycle that saves you lots of time.

The first, simple and well known means is to exclude the driver binary from the CE image. Let the OS load the driver from the release file system (Relfsd). With that there is no need to perform a 'makeimg' after each driver modification. Note: This requires a working KITL connection.

The next shortcut requires some initial work but mosly there's no need to download and boot the OS image in each cycle.

I'm sure you will re-use this driver development pattern in future.
For that you have to rename the driver registry entries. Instead of "Drivers\BuiltIn\MyDriver" use for example "Drivers\BuildInTest\MyDriver". With that the driver is not loaded during boot. Then write a simple driver test tool that performs the following steps:

    1. Create a named event. If the event already exists signal the event and goto step 6; otherwise continue with the next step.

    2. Copy the registry data from "Drivers\BuiltInTest\MyDriver" to "Drivers\BuildIn\MyDriver".

    3. Let the OS load and start the driver via ActivateDeviceEx() API function.

    4. Wait for the named event to be signalled by a second instance of the edriver test tool.

    5.As the event gets signalled unload the driver by calling DeactivateDevice() API function.

    6. Free the event so with the next start of your test tool it again loads the driver.

    7. Simply exit :-)

With all that stuff prepared you load your driver by starting the test tool the first time (e.g. via CE shell "s loaddriver.exe". Now you can test/investigate your driver as in former times. The big difference is that you can unload the driver by starting the test tool a second times, modify your driver and start over without the need to reboot the OS again.

This little development pattern accompanies my since I started CE development about 10 years ago. So it's high time to share :-)

1 comment:

xico2kx said...


I'm a software programmer (mainly C) and a gadget enthusiast!

But unfortunately I have no knowledge in embedded devices or driver development.

But I would like to ask you something...
Is it possible to install "Windows Embedded Compact 7" in those new MK802 Mini-PCs / HDMI-sticks that are becoming very popular?

Does this version of Windows come with drivers that support the "Allwinner A10" (Cortex-A8) ARM processor?

Thank you very much for your attention!