Southern Electronics Show

Just a quick note to invite you to come visit me on the ByteSnap Design stand at next week's Southern Electronics show in Farnborough from the 10 - 11 February 2010.

We will be demonstrating a number of customer projects including one from Rotalink, a designer and manufacturer of miniature motors, transmission and controls. This demo hooks up a DC motor speed detector to a mini-fairground wheel to show rotation and angle information via a display using our SnapUI product.

We'll also be showcasing other bespoke embedded electronics designs, embedded firmware and board design services. Come down to have a talk about services we can provide you from PCB design, through Firmware/BSP design to application development.

See you there!

CE6.0 CETK using ActiveSync failes on ARM devices

One of the guys here was having problems getting his CE6.0 CETK connected using activeSync to the target device. It sounded like something on the platform or his PC was just not setup correctly as the Platform Builder connection test just wouldn't work... very bizzare.

We're all running Vista 64 or Windows 7 64 so we were thinking it was a 64 bit issue (as there are other problems using these OS's for day to day development work but no it seems that the Platman folders on the PC that are used to store the target binaries for the CETK and remote tools is being checked incorrectly. If you look in this directory:

C:\Program Files\Common Files\Microsoft Shared\Windows CE Tools\Platman\target\wce600\

You'll see the ARMv4i directory but not an ARMv4 one like in previous versions of the Windows CE OS releases. It seems that the PC side application to push these target executables is looking (incorrectly) for an ARMV4 not ARMV4i directory.

To work around this simply copy the ARMV4i folder to create an ARMV4 directory and it should now all connect up.

Calling Kernel IO routines from Apps in CE 6.0

In Windows CE 6.0 applications are unable to call kernel IO many routines including new OEM functions in the kernel using KernelIoControl. There are a few exceptions to this rule, these are:

IOCTL_HAL_GET_CACHE_INFO

IOCTL_HAL_GET_DEVICE_INFO

IOCTL_HAL_GET_DEVICEID

IOCTL_HAL_GET_UUID

IOCTL_PROCESSOR_INFORMATION:

What is not commonly known is that this list can be extended by adding any new (or existing) IOCTLs to the following public library and sysgen (or copy this to your platform and update the links to build the OALIOCTL.DLL:

%_WINCEROOT%\PUBLIC\COMMON\OAK\OALIOCTL

If your CE5.0 platform had a lot of support for platform specific operations using KernelIOControl these can continue to be called from CE6.0 applications if you wish now!

Active Sync problems using RNDIS

I use a number of machine on a day to day basis, one of my development machines refuses to connect using Vista's Active Sync (Windows Mobile Device Center) to any devices using RNDIS as the connection type. The RNDIS connection is made but the device center refuses to attempt any connection... ger!

Connecting using USB serial works without any problems, so here is my work around until I find a fix:

If you are using Windows Mobile Standard (Smartphone) then you can switch to using USB Serial from the default that is RNDIS by going to settings->connections->USB to PC and un-selecting the "Enable advanced network functionality". This resorts to using the old fashioned USB serial. There should be a similar setting on Windows Mobile Professional (PocketPC).

Lightweight XML User interface for Windows CE

ByteSnap Design have just launched their user interface SnapUI, this UI engine uses XML to separate the graphics engine from the user interface configuration.

The XML file describes the whole screen menu structure and icon layout, any text placement, language and interaction, whilst the engine is responsible for rendering this configuration to the user and interfacing with any propriety hardware on the embedded system

The tool is aimed at embedded devices using Windows CE but can be run using the same graphics files on a Desktop PC for quick development, testing, demos etc, read more from the article on WindowsForDevices SnapUI

Bytesnap Design Ltd are a UK based company near Birmingham, read more about the SnapUI and design services at www.bytesnap.co.uk

Using WinCE APIs From Kernel OEM Routines

There are many occasions where you want to implement some functionality in a Kernel IOCTL or OEM kernel callback but you can't call the normal Windows CE API because you're in kernel space. So tasks such as setting or reading registry entries, creating events and signalling processes etc can't be done... or can they..?

Some of the basic API functions for this support are available but the functions have a prefix NK or K, for instance:

NKSleep()

NKRegCloseKey()

NKRegCreateKeyExW()

NKRegOpenKeyExW()

etc

Note that not all of these are documented, so for more information see:

\WINCE600\PUBLIC\COMMON\OAK\INC\nkexport.h

More advanced functions are available in:

\WINCE600\PRIVATE\WINCEOS\COREOS\NK\INC\syncobj.h

This is the publicly available Windows CE private kernel code, and includes event, Semaphores and even message queues!:

NKSetEvent

NKPulseEvent

NKResetEvent

NKCreateMsgQueue

etc!

So don't use flags and share memory, do it properly with some thread and process intercommunication! :)

Negating the need to run MakeImage when developing device drivers on WinCE

Debugging of drivers on Windows CE can be painful when downloading large images, NK.bin's of 10-30mb are typical and having to download the whole of this just for a driver modification can mean long times between compilation and testing. Here are my three methods for quicker development without having to push the full nk.bin down each time.

The firstly two methods have pretty much the same outcome but from a different approach:

1 - Remove the driver from the platform.bib file.

This means that the driver isn't embedded in the OS image (nk.bin), then run this image when on KITL enabled (the debug transport typically used to connect the target device to the development PC). This will result in the DLL being pulled from the desktop release directory over the KITL transport and being ran as if it were in the image.

2 - Tell Platform builder to force loading of modules over KITL

In Platform Builder go to

Target -> Release Directory Modules

Then include the DLL's that you want to force loading over the KITL connection, this tells the OS on start-up to ignore any DLLs included in the image. The benefit of this is that you don't even have to build the NK.BIN again.

3 - Load the drivers at runtime using ActiveDevice

This method is handy if you don't have a KITL connection, here we populate the registry with the driver entries, but instead of putting them under HKLM\Drivers\Builtin\ put the registry entry under HKLM\Drivers\Test\ to ensure that the system doesn't load the driver on start-up.

Then create a simple application that will tell device.exe to load the driver when you run it:

HANDLE device = ActivateDevice(L"Drivers\\Test\\myDriver", 0);

Using the handle returned, you can also force it to unload the driver. This means you can start (and stop) the driver without a KITL connection but allowing you to copy new versions of your driver on from an SDCard or ActiveSync, you'll need to rely on serial debug prints probably to debug here but it’s a quick easy mechanism if you don't have a debug transport.