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 :-)

Read more! Post this to a friend!

Windows Embedded CE 6.0 Stream Interface Driver Wizard

Hi folks,

David Jones has written a wizard to simplify stream interface device driver development under Windows Embedded CE 6.0. This wizard works with the Visual Studio IDE and helps you set up an initial subproject to develop your stream interface device driver.

Find it here on the open source community CodePlex.

Thanks a lot David!

Have fun!
Read more! Post this to a friend!

Webcast: Windows Embedded Compact – Driver Development: Best Practice

Hi folks,

In this webcast I will shares tips & tricks as well as best practices about the driver development process under Windows Embedded Compact and Windows Embedded CE 6.0 (R3):



Have fun!
Read more! Post this to a friend!

Kernel-Mode and User-Mode DLLs

The new memory architecture in Windows CE 6.0 leads us to two types of DLLs: Kernel-Mode DLLs and User-Mode DLLs. We put a Kernel-Mode DLL in the MODULES section of our BIB-File and mark it with a K:

MODULES

MyDll.dll $(_FLATRELEASEDIR)\MyDll.dll NK SK

If we want to use the DLL in both Kernel- and User-Mode we replace the K with a Q:

MODULES

MyDll.dll $(_FLATRELEASEDIR)\MyDll.dll NK SQ

MakeImg creates a copy of our DLL named K.MyDll.dll. Each version of the DLL will relocated to the corresponding XIP section in User-Space and in Kernel-Space.

Up to this point the facts are easy and every BSP developer should know about it.

Now it starts to be tricky:

What about LoadLibrary()? What happens if I try to call LoadLibrary(L”MyDll.dll”); from a driver in the Kernel context?

The answer is: LoadLibrary() loads K.MyDll.dll, you don’t have to add a “K.”!

But what if the DLL needs another DLL, e.g. My2ndDll.dll?

It is obvious that My2ndDll.dll must be also a Kernel-Mode DLL, but the name mustn’t be K.My2ndDll.dll.

Alternatively you may move My2ndDll.dll from the MODULES section to the FILES section. Remember to remove any K or Q!

MakeImg cannot resolve all dependencies in this situation:

Warning: Unable to do imports from K.MyDll.dll to My2ndDll.dll - will late bind

But if My2ndDll.dll is on your target, K.MyDll.dll will be loaded successfully.

It’s a good idea to review all DLL dependencies and think about the special functionalities of your DLLs. Some DLLs do kernel-specific things and cannot run in User-Mode, e.g. read from KSeg1 addresses. Some DLLs use application interfaces you won’t move to the Kernel, e.g. MFC or OleAut32.

Tschüß Holger

Read more! Post this to a friend!

Don't know how to make 'TargetCompilePass'

It's another "Klassiker":

BUILD: [01:0000000016:ERRORE] NMAKE : U1073: don't know how to make 'TargetCompilePass'
BUILD: [01:0000000018:ERRORE] NMAKE.EXE TargetCompilePass -i -c BUILDMSG=Stop. ...

This error means there is no makefile in your code directory. And it has nothing to do with the TargetCompilePass or NMake.
Each directory with your code (e.g. a driver) must contain at least a sources and a makefile file. Just copy it from any other driver and modify the sources file. But never change the makefile!

Tschüß Holger
Read more! Post this to a friend!

Omg, my image is too large!

Limitted recources on Windows CE devices cause a lot of trouble.
I want to give you some hints to find out why your image is twice the expected size.
It's not so easy to find out what OS components can be removed for a specific project.

• NK.nb0 vs. NK.bin: The BIN-File is roughly the size you need on Flash and additionally on RAM. If you use a NB0-File and your BIN-File is much smaller, just review your config.bib and check the ROMSIZE value. And set AUTOSIZE=ON if possible.

• Catalog View: Review the Catalog Items under "Core OS". The Platform Builder adds Catalog Items to your project if it depends on another item. Select the filter "User-selected Cataloge Items and Dependencies" and review the small green squares. Select "Reasons for Inclusion of Item" from the context menu.

• SYSGEN_*: In the properties of the Catalog Items you can see the corresponding SYSGEN variable. The build process "translates" the SYSGEN variables to a list of OS components in CE_MODULES, IE_MODULES ... You find these "rules" in the batch files under Public/CeBase/Oak/Misc. In the most cases each OS component corresponds with a DLL or EXE file in your release directory.

• CeConfig.h: In each release directory and on each device you find a CeConfig.h file with the complete list of OS components in your image. Review this file to find obsolete components.

• DLL-Size: Sort your DLLs and EXE files in your release directory by size and try to remove the largest files.

• ViewBin: With the tool "ViewBin -t nk.bin" you see a list of MODULES and FILES and it's sizes.

Large files are Internet Explorer components, VBScript, JScript and fonts. Sometimes there are MFC DLLs in an image but no MFC applications. Standard SDK compatibility is deprecated and it adds a lot of dependent components.
But don't try to remove each unknown 20kByte file, it will make your image very special.
After changing your OS extend you have to rebuild your Platform SDK.
I hope my hints are helpful to make your OS image smaller.

Tschüß Holger
Read more! Post this to a friend!

Enabling more USB printer devices under Windows CE

Hello guys,

take a look at this possible scenario: you have a USB (PCL) printer and want to use it under Windows CE. You have included the USB printer class driver in your run time image, built it and then attached the USB printer to the device. In some cases you will get a message that the device wasn't recognized.

This is caused by the "IEEE-1284" device ID string. USB printers report their capabilities via the class-specific command GET_DEVICE_ID which returns a device ID string that is compatible with IEEE-1284.

This device ID string is fetched from USB printer devices by calling the GetDeviceID function (implemented here: .\public\common\oak\drivers\usb\class\printer\usbprn.c).
The received device ID is then handled in the function RegisterPrinterSettings ( .\public\common\oak\drivers\usb\class\printer\lpt.c).
The device ID has to at least match one of the following tags: "DESCRIPTION:", "DES:" or "MODEL" otherwise the RegisterPrinterSettings funtction will fail and you will get the message box with "Unrecognized USB device" as a result.

Unfortunately some USB printer manufacturers implement the "MDL" tag, which is currently not implemented in the Windows CE Versions 4.2 or 5.0

You can avoid this problem and increase the amount of supported USB (PCL) printer devices by modifying the RegisterPrinterSettings function (.\public\common\oak\drivers\usb\class\lpt.c) so it accepts a "MDL:" tag as a valid description field, e.g.:


//
// parse for a Description string
//
if ((p = strstr(buf, "DESCRIPTION:"))!=NULL)
p += sizeof("DESCRIPTION:") - 1;

else if ((p = strstr(buf, "DES:"))!=NULL)

p += sizeof("DES:") - 1;
else if ((p = strstr(buf, "MODEL:"))!=NULL)

p += sizeof("MODEL:") - 1;

else if ((p = strstr(buf, "MDL:"))!=NULL)

p += sizeof("MDL:") - 1;

Thanks
Read more! Post this to a friend!

Holger's Search Pattern

My workspace is perfectly prepared for CE driver development tasks.
There are a number of tools, e.g. my favorite text editor, diff tool and a powerful grep.
And one of the convenient things on my workspace is a good search pattern for "Find-In-Files".
I want to share this pattern with our readers:

*.c;*.cpp;*.cxx;*.h;*.hpp;*.hxx;
sources;dirs;*.cmn;*.def;
*.bib;*.reg;*.s;*.inc;*.mac;*.blt

Tschüß Holger
Read more! Post this to a friend!