Research and design of power management based on WinCE driver

The two models of WinCE are the local device driver and the stream interface driver. For common embedded electronic devices, especially those that cannot be connected to AC power for a long time, reducing the power consumption of display devices has always been the main task of power management. At present, there are many types of display devices, but most modern products use reflective thin film transistor (TFT) display plus backlight as the display device. Although the content on the screen can be seen clearly under sufficient light, the backlight still needs to be turned on for reading comfort. Embedded system terminals based on Windows CE are usually powered by batteries. Therefore, the role of backlight driver power management is particularly critical. How to reduce unnecessary power consumption of the target system and extend its standby time has become an important part of the design and development of Windows CE operating system power management.

Starting from the stream interface device driver of WinCE, this paper introduces in detail the power management strategy and basic principles based on the Windows CE operating system, and realizes the design and development of power management in WinCE backlight driver.

1 Window CE Driver Architecture

At present, WinCE provides four device models, two of which are specifically used for WinCE, and the other two models come from other operating systems. The two models based on WinCE are the local device driver and the stream interface driver. The two external models are used for the Universal Serial Bus (USB) and Network Driver Interface Standard (NDIS) drivers. Among them, the stream interface driver is designed for connecting to peripheral devices based on the WinCE platform. These peripheral devices include SD cards, cameras, printers, etc. Its driver model is shown in Figure 1. This article is based on the backlight control stream interface driver of the LCD display on the ARM9 development board of S3C2440A, and analyzes in detail the power management development and implementation process of the backlight driver under WinCE.

Figure 1 Windows CE stream interface driver model

As can be seen from Figure 1, peripheral devices are managed by device drivers, and user applications access external physical devices by calling the file system. The stream interface driver represents the peripheral device as a special file in the file system, making it as easy for applications to use the peripheral device as opening and closing a file.

2 Windows CE Power Management

2.1 Power Management Architecture and Power Manager

The overall structure of power management is shown in Figure 2. The power manager interacts with applications and drivers directly or indirectly. The power manager interacts with drivers mainly through driver interfaces, and interacts with applications through APIs and reminder interfaces. Among them, the power manager is specifically responsible for managing the power state of the device, thereby improving the overall power efficiency of the operating system, and is compatible with drivers that do not support power management. The software entity of the power manager in the operating system is the dynamic link library pm.dll, which is loaded into the kernel process of Windows CE by the device manager device.dll to run.

Figure 2 Schematic diagram of power management architecture

Using the power manager, devices receive notifications of power state changes in the form of I/O control codes (IOCT L). Using IOCT L to manage power distinguishes the power state of the device from the power state of the entire operating system. In this way, some devices can turn off their power when the operating system is running, while other devices can remain in their original state when the operating system is suspended.

2.2 Windows CE device power state and system power state

The power manager expects all managed devices to support one or more device power states. Devices must report their power consumption characteristics to the power manager. Device power states typically require a compromise between performance and power consumption.

The power state includes the system power state and the device power state. The device manager manages the device power state within the range of the system power state defined by the OEM, and the system power state imposes an upper limit on the device power state.

The device power states of Windows CE are static predefined power states of the operating system. The peripheral driver receives the request to change the device power state from the power manager, converts it into a power state that the peripheral can support, and is responsible for finally implementing the power state change on the physical peripheral.

Windows CE provides 5 predefined device power states. They also have corresponding keys in the registry. If Dn represents D0~D4, the smaller the number n, the greater the power consumption of the peripheral under the power state level, as listed in Table 1.

Table 1 Device power status

The system power state of Windows CE operating system is completely different from the device power state. It is not statically defined, but customized by OEM users according to their needs. OEM users define the system power state by configuring the system registry. The name of the system power state is defined as the name of the registry entry. Figure 3 describes the conversion of the four most typical system power states supported by Windows CE. 

Figure 3 System power state transition

3 Backlight driver power management

3.1 LCD Backlight Power Management Strategy

The backlight driver starts a monitoring thread, which keeps waiting for three events:

3.1.1 BackLight Chang eEv ent

Waiting for the clock in the registry to be updated, always turning on the backlight after the clock in the registry is updated.

dw Resul t = WaitForMul tipleObject s( NUM _EVENT S, & g_evtSignal[ 0] , FALSE, dw Tim eout );

if ( WAIT _OBJECT_0 = = dw Result ) {

BL_ReadRegist ry( & g_BLInf o) ;

BL_On( TRUE ) ;

}

3.1.2 PowerChangedEvent

The monitoring thread gets this event when the power supply changes, such as plugging in a power supply. If the power supply is used, the m_dwACTimeout value can be used as the timeout value, otherwise, the m_dwBatteryTimeout value can be used as the timeout value.

if (dw Result = = WAIT_OBJECT _0+ BL_POWERE VT) {

if ( IsACOn() ) {

dw Timeout = g_BLInf o. m_dw ACTimeout * 1000;

}

else {

dw Timeout = g_BLInf o. m_dw Batt eryT imeout * 1000;

}

}

3.1.3 PowerManager/ActivityTimer/UserActivity

Waiting for user input events. If the user presses a key, the backlight driver will be turned on regardless of whether the power is plugged in or not. Otherwise, waiting for a timeout event to occur will turn off the backlight driver.

if ( dw Result == WAIT_OBJECT _0+ 1 | | dwResult == WAIT _OBJECT _0 + BL_BUT TONEVT )

{

if ( IsACOn() ) {

if ( g_BLIn fo. m_bAC Au to) {

BL_On( TRUE ) ; }

}

else {

if ( g_BLIn fo. m_bBat t eryAut o) {

BL_On( TRUE ) ; }

}

}

else if ( dw Result == WAIT_T IMEOUT ) {

BL_On( FALSE ) ;

}

The timeout value in the registry determines the working time of the backlight. Set the timeout value as follows in the registry:

[H KEY_CURRE NT_USER/ControlPanel/Backlight]

"AC Timeout" = dword: 3c // hexadecimal, decimal is 60

"Bat t eryT imeout " = dw ord: 1e // hexadecimal, decimal is 30 3.2 Create a backlight driver that supports power management

To obtain the functional support of power management, the power manager must first be able to identify the backlight driver. To do this, the backlight driver needs to declare a special GUID representing the device type of power management to the device manager. The specific operation is to add a GUID to the IClass table item of the Active registry key. Add the following to the Platform.reg file:

"IClass "= "{ A32942B7- 920C- 486b - B0E6 - 92A702A99B35} "; Power-manageable generi c

3.3 Add support for I/O control code (IOCTL) in backlight driver

After the backlight driver is notified as a power management-supported driver, it only needs to handle the DeviceIoControl call from the power manager. The power manager uses the IOCTL codes shown in Table 2 to communicate with the backlight.

Table 2 IOCTL opcodes for power management

Among them, IOCTL_POWER_CAPABILITIES must be implemented to support any stream interface driver that supports power management.

3.4 Implementation of IOCTL Code

At the initial stage when the driver is loaded into the system, the backlight driver first puts the device power state into D0 state, and then the power manager calls its IOControl function through the IOCTL _POWER _ CAPABILITIES operation code.

When sending a query to the device, the backlight driver reports the power management capabilities of the device in detail so that it can be included in the system's power management strategy. If the query for power management support fails, the power manager will assume that the device driver does not support the other four power management IOCTL opcodes. The specific code is as follows:

cas eIOCT L_POWER_CAPABILITIES:

{

PPOWER_CAPABILITIES ppc;

if ( ! pdw ActualOu t | | ! pBufOut | | ( dw LenOut < sizeof

( POWE R_CAPABILITIES ) ) )

{

RetVal = FALSE ;

dw Er r = ERROR_INVALID_PARAMET ER;

break;

}

ppc = (PPOWER_C APABILITIES) pBufOut;

m ems et ( ppc, 0, sizeof ( POWER_CAPABILIT IE S) ) ;

ppc->DeviceDx = 0x11; //Supports two device power states: D0 and D4

ppc->Pow er[D0] = 25000; // 25 m = 25000 uA

* pdw ActualOut = siz eof (POWE R_CAPABILITIES);

} break;

After the initial stage is completed, the power manager can call IOCTL_POWER_SET to adjust the power state of the device according to the power management policy. When implementing support for IOCTL_POWER_SET, the backlight driver developer needs to pay attention to the fact that the device does not necessarily have all five device power states, but at least works in D0 and D4.

3.5 Sleep and wakeup processing

Power sleep wakeup is an important technology to extend the system power working time. When the system enters sleep state, the driver should turn off the power of the device, even if the device is not in D4 state due to the application's request. The backlight driver receives system sleep and wakeup notifications through BAK_PowerDown and BAK_PowerUp, which are issued before the kernel calls OEMPowerOff and are in the interrupt context.

4 Backlight driver test

Package the backlight driver into the kernel image file, download it to the development platform, open the system display properties, and when powered by battery, if the user has no activity within 30 seconds, the LCD backlight will enter the idle state; when powered by external power, if the user has no activity within 1 minute, the LCD backlight will also enter the idle state.

5 Conclusion

This paper designs a power management system for the backlight driver of an embedded terminal based on the Windows CE operating system. Based on the analysis of the stream interface driver and the power management of the WinCE operating system, combined with the IOCT L operation code of the power management, the design of the backlight driver power management system is completed, and the key code for the implementation of the power management part of the backlight driver is given. After testing, the backlight driver can effectively control the power consumption of the LCD backlight, and can also coordinate with the power state of the entire system. The system's control of the backlight meets the design requirements. Finally, this paper's research on the backlight driver power management strategy under the WinCE operating system also has important guiding significance and reference value for the design of power management systems for other similar embedded terminal product drivers.