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

Enable Bluetooth support in Windows Embedded CE

The Bluetooth stack is natively supported by Windows Embedded CE, and can be integrated to your runtime image. This required of course a Bluetooth controller that can be either a Serial, USB,… dongle. Based on this stack you can enable Bluetooth capabilities to your device and applications, using the Bluetooth API. Enabling Bluetooth in your applications is not straightforward, as it requires to implement mechanism for at least the discovery and pairing with other devices (paired devices are trusted devices).
A Windows Embedded CE device can either connect to services provided by other devices or host service for other devices.

Profiles:
On a Bluetooth device, the different remote or local services provided by the Bluetooth stack are called profiles. The Bluetooth specifications provides a complete definition of the different Bluetooth profiles that can be enabled on a Bluetooth device. Unfortunately Microsoft do not provide all the profiles listed in this specifications, but only a subset is accessible like:

• Service Discovery Protocol (SDP) used to discover the other Bluetooth enabled devices in the range of your device

• Serial Server Profile (SPP) providing a serial interface for communication between two devices

• Object Push (OPP) to send files to other devices, can be used to send business card

• File Transfer Protocol (FTP) to provide an access (push or get) to a remote file system

• Personal Area Networking (PAN) to enable IP support to communicate through the bluetooth connection

• Dial Up Networking (DUN) to perform network connection to remote servers

• …

As evocated previously those profiles required development to manage the access to the Bluetooth stack and handle communication errors and requests.

Existing Bluetooth Manager:
When using Bluetooth, you need a Bluetooth Manager that will allow user (or applications) to support the discovery of the in range Bluetooth devices and provide access to the remote and local Bluetooth profiles.

• Microsoft provides by default a very basic Bluetooth manager for the discovery and pairing to remote devices.

• Adeneo provides a Bluetooth Manager with an interesting layered architecture that provide a way to easily integrate in your applications the Bluetooth support. A GUI illustrates how their Bluetooth engine works. More details on their product is available here. They also provide a version compatible and certified for Windows Mobile 5.0 (Product Reference).

Required System Components:
To enable the Bluetooth on your platform, it will requires the following components in your OSDesign:

• USB Host Support (or Serial Port Support)

• Bluetooth Stack with Integrated CSR Chipset Driver

• Bluetooth Stack with Integrated USB Driver (or UART-Only Driver)

Sample source code:
You can find some sample source code for the Bluetooth handling :
_WINCEROOT\PUBLIC\COMMON\OAK\DRIVERS\BLUETOOTH\SAMPLE

- Nicolas

.Net Compact Framework 3.5

The January Windows CE 4.x, 5.0 and 6.0 QFEs (Quick Fix Engineering) enable the .Net CF 3.5 for Windows CE. Now this feature can be directly integrated inside a runtime image by selecting the associated component in the platform builder catalog. The .Net CF 3.5 introduce new graphical components and fix some well know issues of the framework.





Windows Embedded CE QFEs are accessible here

- Nicolas

Business Solution Accelerator 2008

Need help to implement features in your .NET Compact Framework 3.5 application, Microsoft just released the Business Solution Accelerator 2008 for Windows Mobile, providing free and reusable source code and associated documentation.
In the mean time, the Windows Mobile blog will in the future discuss of the best practices in .Net CF development (blog link).

[Updated] Microsoft's Reed and Steve wrote a complete article on this LOB Solution Accelerator.
[Updated] See also Fabien's blog article for details about it.

The complete package and detail are accessible from the Microsoft Web site.
- Nicolas

Who want to be an MCP

Microsoft is currently working on a Microsoft Certification Professional (MCP) Exam for the Windows Embedded CE technology. Few months ago some eMVP has been consulted to create a set of questions on the different technical aspects that must be masterized to generate, debug and use Windows Embedded Runtime binary images.
The exam 70-571, actually in beta test, should be accessible by every body in April time frame.

- Nicolas