Running Windows Mobile 6.1 on your PC

Microsoft provides a way to test the last release of its operating system for Windows Mobile devices. The Windows Mobile 6.1 Runtime images provided can be loaded in a VirtualPC 2007 instance.



A good way to test the compatibility of your applications with the next release of the OS for a time to market as short as possible.
Get the WM 6.1 Images on the Device Emulator with MDM here.

Enjoy.

- Nicolas

Accessing native API from C#

The .Net Compact Framework, in his CLR (Common Language Runtime), contains a fixed set of API, and when working on an embedded device running Windows Embedded CE, most of the time, the managed code developers require access to some native APIs like custom DLL provided by a third party company. In this case the required APIs cannot be directly accessed in C# by the application and developer have to use the P/Invoke mechanism for the marshalling of the data from the managed to the native environment.

[DllImport ("coredll.dll")]
private static extern int CreateFile(
string lpFileName, int dwDesiredAccess,
int dwShareMode, int lpSecurityAttributes,
int dwCreationDisposition, int dwFlagsAndAttributes,
int hTemplateFile);

The DllImport macro is used to specify to the CLR that the next function declared is located inside a native dll, coredll.dll for instance. The tricky operation when defining Marshalling operation is the way to define the native types into managed types. Because if the wrong type definition is used, the CLR is going to Marshall the data in a way that is not expected by the native functions, and can be the reason of a crash or memory leaks on the system (null pointer, bad type conversion, …).

Accessing Device Drivers from C#

You have the same issue when trying to access device drivers from a C# application as the .Net Compact Framework do not contain any classes that allow developer to load a open driver and access it. Under Windows Embedded CE, device drivers are managed by the device manager, and in any case you do not access a driver directly through its Dll. You always have to use file system API to do so. For this reason, the CreateFile, CloseHandle, WriteFile, ReadFile, SetFilePojnter and DeviceIoControl functions should be redefined in C# to specify the Marshalling of the various functions’ parameters.

[DllImport ("coredll.dll")]
private static extern int CreateFile(
string lpFileName,
int dwDesiredAccess,
int dwShareMode,
int lpSecurityAttributes,
int dwCreationDisposition,
int dwFlagsAndAttributes,
int hTemplateFile);

[DllImport ("coredll.dll")]
private static extern int CloseHandle(int hObject);

[DllImport ("coredll.dll")]
private static extern int ReadFile(
int hFile,
byte[] lpBuffer,
int nNumberOfBytesToRead,
ref int lpNumberOfBytesRead,
ref OVERLAPPED lpOverlapped);

[DllImport ("coredll.dll")]
private static extern int WriteFile(
int hFile,
byte[] lpBuffer,
int nNumberOfBytesToWrite,
ref int lpNumberOfBytesWritten,
ref OVERLAPPED lpOverlapped);

[DllImport ("coredll.dll")]
private static extern int SetFilePointer(
int hFile,
int nDistanceToMove,
ref int lpDistanceToMoveHigh,
uint nMoveMethod);


[DllImport ("coredll.dll")]
private static extern int DeviceIoControl(
int hFile,
uint dwIoControlCode,
byte[] lpInBuffer,
uint nInBufferSize,
byte[] lpOutBuffer,
uint nOutBufferSize,
ref uint lpBytesReturned,
ref OVERLAPPED lpOverlapped);

The OVERLAPPED parameter, used by ReadFile, WriteFile and DeviceIoControl, should also be re-defined as this type is unknown in C#. In native code this object is a structure of basic types and will be defined like this in C#:

private class OVERLAPPED
{
public int Internal; // Reserved for operating system use.
public int InternalHigh; // Reserved for operating system use.
public int Offset; // Specifies a file position at which to start the transfer.
public int OffsetHigh; // Specifies the high word of the byte offset at which to start the transfer.
public int hEvent; // Handle to an event set to the signaled state when the operation has been completed.
}

To have a nice way to use those different native functions, the DllImport definition should be wrapped inside a standard C# class and public function with managed types parameters can be provided to the developer.
For example the Open function published by a device driver wrapper class could be write like this :

int m_intHandle = INVALID_HANDLE_VALUE;

public bool Open(String strDriverName)
{
m_intHandle = CreateFile(strDriverName, GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0);
return m_intHandle != INVALID_HANDLE_VALUE;
}

Avoid Memory Leaks

Unlike managed code when allocating memory in native, do not forget to explicitly destroy those objects to avoid memory leaks. Even if you are accessing the native code from a managed application, the Garbage Collector is not able to detect those memory objects and freed them for you.

- Nicolas

ESC Silicon Valley (San Jose, CA)

The Embedded System Conference (ESC) runs this week at San Jose, and Kevin Dallas general manager of the Windows Embedded Business at Microsoft, helped by Nick McCarty from Adeneo, did a very cool presentation of Windows Embedded CE 6.0 R2 to a large audience.

Mike Hall, who appreciates this monkey demo, talks about it on his blog.

- Nicolas

MVP Global Summit 2008

All the worldwide MVPs (Most Valuable Professional) met this week at the Microsoft Headquarter for a yearly information and feedback discussion. Most of the information provided during this week are under NDA and cannot be shared with you but the thing that I can say is that the next version of Windows CE, the version 7.0 will have a lot of new cool features for the graphical interface development, connectivity, … And the name of Windows CE 7.0 will be 'Windows Embedded Compact 2009' according to the new marketing naming scheme for the Microsoft Embedded operating systems.

This 4 days event has been closed by Steve Ballmer, who as usual, did his show and received few gift from the Canadian MVPs and an US MVP (the Simpson tie).

- Nicolas

Power Management under Windows CE [part 3/3]

Applications can also interact with the power manager to change the current power state of the system or to be notified on power state transitions.

Application System Interaction

Using the Power Manager, applications can request system power state using the SetSystemPowerState. This is true for the system but applications can also interact with drivers. Imagine that a device driver is powered off after being used, this for power consumption reason, when applications requires an access to this driver, the driver must be turned on again. Using SetPowerRequirement, applications can ask drivers through the Power Manager, to switch to a specific power state. Then using ReleasePowerRequirement, the power requirement will be release and the driver will switch back to his original power state.

Request power notification

Using message queue, applications can be notified of power transition occurring on the system. When system is entering suspend, this is transparent for applications, and the only way for applications to be notified of resuming from suspend is to register to this message queue using the RequestPowerNotification function. The messages read from the message queue provide information on the status of the system.

Modify the Power Manager

The source code of the power manager is provided with Windows Embedded CE and can be located in %_WINCEROOT% \PUBLIC\COMMON\OAK\DRIVERS\PM . This gives you a chance to adapt the behavior of the Power Manager to your requirements. Most of the time, you do not have to make any modification in the code; instead use the registry to change the default behavior.

In conclusion the power management is straightforward for Windows Embedded CE when the power requirement of your device is simple, but can start to be tricky when more complicated. In any case, the system can be fully customized through the registry or for advanced usage by modifying the behavior of the Power Manager by directly modifying the source code. Applications can be notified of power transition and act if required, but it can also interact with the system to change the power state of drivers or the system. On their side device drivers can implement power management to support 5 different levels, and optimize the power consumption of your device. The Power Manager is the only one on the system to manage the power, applications and drivers always have to send request to the Power Manager that will relay the requests to the correct system component according to his internal state machine.

-Nicolas

Power Management under Windows CE [part 2/3]

In the last article we saw that the Power Manager is in charge of the management of the power on a Windows CE device, and interact with the system to change the system power consumption according to the user and system activity. Each driver can support 5 different levels of power states that can be setup from the registry.

Device Drivers Interface

The Power Manager is using IoControls to communicate with the drivers, to set, get the current power state of the driver. So drivers have to implement the support of those IoControl codes if they can manage the power of the managed device. The command codes are the following:

• IOCTL_POWER_CAPABILITIES: used by the Power Manager to identify the power capabilities of the device driver. This command is called once when Power Manager enumerates the device on the system.
  
• IOCTL_POWER_GET: used to get the current power state of the device.
  
• IOCTL_POWER_SET: used to request a power transition.
  
• IOCTL_POWER_QUERY: used to validate that the driver will support a power transition from its current state to the specified state.
  

Power Manager interface for device drivers

The device drivers cannot change their power state by themselves, without notifying the power manager; otherwise the power manager is not aware of state modification and cannot optimize the power on the device. When drivers require power level modification, they should request the power manager for that by calling DevicePowerNotify from the driver. Then the power manager will use the IoControls to request user to change is power state.

Next time we will identify how the applications can request system power transition.

[Updated] : Access to part 3/3

- Nicolas

Power Management under Windows CE [part 1/3]

Embedded devices are usually powered by batteries and the power have to be correctly managed to improve the device autonomy and by the way the user experience. Windows Embedded CE is provided with a Power Manager that will interact with the different drivers of the system to reduce power consumption when required.

System Power States

The OS have 4 different power states that will be the four states of the internal power manager state machine. The state transition will be linked to system conditions : user activities, system activities, application requests and timers.

The four states are :

• On : in this state the device is full active and user can use all the different peripherals, and by consequence the current consumption is maximum

• User Idle : this state is reach when user is not using the device after a time out, the power consumption can be reduced by, for example, decreasing the display backlight intensity and disabling peripherals.

• System Idle : after application inactivity, the power manager switch to this state.

• Suspend : in this state the device is consuming the less power as possible, but the device cannot be used, the processor clock is decreased (or turned in a suspend state if supported), the peripherals are usually turned off and the SDRAM is still refreshed.

The transition from On to User Idle and User Idle to Suspend is done after timers expirations, those timers value can be setup through the registry to customize your device. You can managed timers when device is powered by a battery and/or by AC, to optimize your device current consumption depending on the power source.

[HKLM\SYSTEM\CurrentControlSet\Control\Power\Timeouts]
"ACUserIdle"=dword:5 ; in seconds

This will set a timeout of 5 seconds to enter the User Idle state when the device is powered by AC. The status of the power source is not identified by the Power Manager, itself, it will require the development of a battery driver. The battery driver will provide power source transition notifications to the power manager.

Drivers Power States

On the system drivers can support 5 different levels of power according to the peripheral capabilities:

• D0 : Full on, the peripheral is fully functional

• D1 : Low On, fully functional the device consumption is reduce comparing to D0 state

• D2 : Standby, device is partially powered, and able to wake up on request

• D3 : Sleep, the device is consuming as less power as possible and can be used to wake up the system

• D4 : Off, the device is off an do no consume any power

Each state is optional and a driver can support only few of them. The power manager will request to the driver the different supported power state at initialization.

System Power States vs Drivers Power States

The Power Manager is fully configurable through the registry, so default configuration is provided to at least manage power by its own without any pre-requisite. Each power state of the drivers will be associated to a system power state as follow :

• On -> D0

• User Idle -> D1

• System Idle -> D2

• Suspend -> D3

The Power Manager will request device driver to change their power state at system power state transitions, according to this list. As explained before, those values can be overridden using the registry by creating new entries like this :

[HKLM\SYSTEM\CurrentControlSet\Control\Power\State\UserIdle]
"bkl1:"=dword:4 ; backlight off

[HKLM\SYSTEM\CurrentControlSet\Control\Power\State\SystemIdle]
"bkl1:"=dword:4 ; backlight off

[HKLM\SYSTEM\CurrentControlSet\Control\Power\State\Suspend]
"bkl1:"=dword:4 ; backlight off

In this example, the driver named bkl1: will be turned off when the system power state will switch to User Idle, System Idle and Suspend states. You can either define power state for drivers individually in the registry or group them into IClass definition. When defining a driver in the registry you can specify which class of driver this driver is associated to.

[HKLM\SYSTEM\CurrentControlSet\Control\Power\State\SystemIdle\{ A32942B7-920C-486b-B0E6-92A702A99B35 }]
"Default"=dword:4 ; D4

This configuration will turn off all the device from the Iclass (A32942B7-920C-486b-B0E6-92A702A99B35). This IClass value is the GUID used by the power manageable devices.

That’s all for today, but two additional articles are following in the next few days. I will talk about the device driver interface requirements, and application interface used to communicate with the Power Manager and receive notification from him.

[Updated] : Access to part 2/3

- Nicolas

NXP LH7A404 ARM-9 based processor runs Windows CE 6.0

Adeneo has announced a Windows CE 6.0 board support package (BSP) for NXP's ARM9-based LH7A404 SoC (system-on-chip). The BSP supports the 200MHz SoC's display, touchscreen, audio, and USB functionality, along with peripherals found on a separately available Logic Product Development development board.

- Nicolas

Windows Embedded CE Webcast

Few weeks ago I did a live web cast session for the device drivers development under Windows Embedded CE 6.0 R2. All the webcast sessions recorded at this time are available now from the Microsoft Embedded Seminars website. For the Device Driver development session use this link.

Enjoy the nice French accent of your host.

- Nicolas