Windows CE Drivers

Windows CE: Data Synchronization using Interlocked Functions

Bruce Eitman — Thu, 04 Sep 2008 00:42:05 GMT

Windows CE provides several ways to synchronize threads and access to data by multiple threads. These include the synchronization objects that are typical for a multithreaded operating system: mutex, semaphores, events and critical sections. These synchronization objects may be overkill for protecting access to a single variable. The Interlocked functions can be used to control access to a single 32 bit variable.

The interlocked functions are:

Function Name	Action
InterlockedCompareExchange	Compares two values and writes a third value if they are equal
InterlockedCompareExchangePointer	Compares two values and writes a third value if they are equal
InterlockedDecrement	Decrements a value
InterlockedExchange	Writes a new value to a location
InterlockedExchangeAdd	Adds a value to a location
InterlockedExhangePointer	Writes a new value to a location
InterlockedIncrement	Increments a value
IntelockedTestExchange	Compares two values and writes a third value if they are equal

These functions all perform atomic actions on the data, meaning that they perform the action without a context switch during the function handling. The functions work by calling into the kernel which then causes an exception. The action is then handled within the exception handler. The functions change a value that is pointed to by a pointer that is passed in. The pointer must point to a 32 bit value that is 32 bit aligned except for x86 processors (for a discussion on what happens if the pointer is not 32 bit aligned see: Platform Builder: Data Misalignment).

A few examples:

// Global data

DWORD Data = 0;

void Foo()

{

DWORD Result;

Result = InterlockedIncrement( &Data ); // Result will contain the original value of Data

Result = InterlockedCompareExchange( &Data, 3, 1 ); // if Data == 1 then Result will be 1 and Data will be set to 3

Result = InterlockedExhangeAdd( &Data, 6 ); // Result contains the original value of Data and Data will contain Data += 6
}

The Interlocked functions provide a safe and convenient way to write to a variable from multiple threads. I say convenient because these functions don’t require the overhead of other synchronization methods when managing small amounts of data. If on the other hand, you need to manage changing multiple values, the other synchronization methods may be a better choice.

Platform Builder: Cloning an MDD Lib

Bruce Eitman — Thu, 21 Aug 2008 04:10:04 GMT

I have written about cloning code from the Public tree to a platform in the past, but someone recently asked about cloning an MDD lib build directory. More specifically the question was about cloning ufnmdd.lib in Windows CE 5.0, which is actually created by linking three separate libs together. In this article, I will walk through the process by cloning one of those libs.

Ufnmdd.lib is created by linking ufnmddbase.lib, ceosutil.lib and defbuslib.lib. I suspect that most people don’t really need to clone ceosutils.lib and defbuslib.lib, but instead really need to just clone ufnmddbase.lib for debugging purposes. So I will clone ufnmddbase.lib and show two different ways to then link the new lib with a USB function driver.

Cloning UFNMDDDBase.LIB

Because this is a statically linked library, the easiest way to clone it is to simply copy the folder to the platform and then make some changes to the sources file. For this example, I will clone ufnmddbase.lib into the MainstoneII platform. I point this out because you can refer to the MainstoneII platform in the WINCE500 build tree. The USB function driver in MainstoneII is a single directory that builds some source code and links with ufnmdd.lib among other libs.

The steps to add ufnmddbase.lib to the MainstoneII:

1. Move the current code down a folder from Drivers\USBFN to Drivers\USBFN\DLL (or any name you choose.) This makes way for us to add a new folder under USBFN for ufnmddbase.lib to build in.

2. Create a Dirs file in Drivers\USBFN and add the following to it:
DIRS =DLL

3. Test building the driver just to be sure that this didn’t break it already

4. Copy PUBLIC\COMMON\OAK\DRIVERS\USBFN\CONTROLLER\MDD to Drivers\USBFN\MDD

5. Add MDD to the Drivers\USBFN\Dirs before DLL:
DIRS=MDD DLL

6. Add RELEASETYPE=PLATFORM to the Drivers\USBFN\MDD\sources file

7. Test build again and check that ufnmddbase.lib is in MainstoneII\Lib sub folders

Now that ufnmddbase.lib has been cloned to the platform, there are two choices for using it within the USB function driver; link directly with the three libs in ufnmdd.lib or create a new folder to link the libs and create a new ufnmdd.lib.

Link Directly with UFNMDDBase.lib

For this option, edit Drivers\USBFN\DLL\sources to change the from linking with ufnmdd.lib to linking with the three separate libraries. Change the SOURCELIBS from:

SOURCELIBS= \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\pxa27x_usbfn.lib \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\ufnmdd.lib

To:

SOURCELIBS= \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\pxa27x_usbfn.lib \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\ceosutil.lib \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\defbuslib.lib \

$(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\ufnmddbase.lib

Then rebuild the driver.

Create a New UFNMDD.LIB

For this option, create a new folder to link the three libraries to create a new ufnmdd.lib. The steps are:

1. Create a new folder: Drivers\USBFN\UFNMDD

2. Create a sources file in the new folder and include:

TARGETNAME=UFNMDD

TARGETTYPE=LIBRARY

RELEASETYPE=PLATFORM

SOURCELIBS= \

$(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\ufnmddbase.lib \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\ceosutil.lib \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\defbuslib.lib

SOURCES=

3. Change the SOURCELIBS from:

SOURCELIBS= \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\pxa27x_usbfn.lib \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\ufnmdd.lib

To:

SOURCELIBS= \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\pxa27x_usbfn.lib \

$(_TARGETPLATROOT)\lib\$(_CPUINDPATH)\ufnmdd.lib

4. Add UFNMDD to Drivers\USBFN\Dirs after MDD and before DLL:
DIRS=MDD UFNMDD DLL

This should give the bases for cloning an MDD lib file for a driver. If you wanted to also clone the other libraries, the technique is the same.

Tags: Build.exe

Windows CE: Device Driver Summary

Bruce Eitman — Thu, 14 Aug 2008 02:02:34 GMT

Posts About Stream Interface Drivers

Windows CE: A Stream Interface Driver Shell

This post contains all of the code necessary to create a driver which will actually be loaded by the device manager. It gives a simple starting point for developing a Stream Interface driver.

Windows CE: Stream Interface Driver, DllEntry()

A short post about what the DllEntry() function does in a device driver.

Windows CE: Stream Interface Driver, XXX_Init()

A discussion of what can and should be done by the driver XXX_Init() function.

Windows CE: Stream Interface Driver Power Management

A discussion and sample code for adding support for the power manager in a stream interface driver. And as a side note, a discussion of testing the power management using the Device Emulator is in Platform Builder: Getting the Emulator to Resume.

Posts About Managing Drivers

Windows CE: Listing Running Drivers

This post uses the ToolHelpAPI to list running drivers.

Windows CE: Loading a Driver with ActivateDeviceEx

Drivers can be loaded using the registry or an application can request that a driver be loaded by using ActivateDeviceEx(). This post includes sample code to load the DriverShell driver.

Windows CE: Device Driver Index Greater than 9

A discussion of and sample code for loading drivers with an index greater than 9.

When Things Go Wrong

Platform Builder: My Stream Interface Driver Does Not Load

A discussion of some of the reasons that the device manager will not load a driver.

Windows CE: Why is reading from the driver so slow?

A discussion of how an application can affect the performance of a driver.

Windows CE 6.0: VMProcessPageFault Error: Page Fault during Resume

A discussion of causes of page faults during resume in Windows CE 6.0.

Tags: Drivers