Windows CE Power Management

Power ManagementWindows CE is a typical battery-powered system. This makes the right operating system very critical. applications do not need to pay attention to the power loss of Windows CE devices most of the time, but in some cases, you may need to pay attention to these losses. When a user disables a battery Windows CE device, the power system does not turn off the PC power. In fact, the system is suspended ( Note: Some pocketpc places the power off on the SIM card, and the SIM card is switched off. However, currently, smartphone is included because hardware devices, such as CPUs, cannot access low power consumption. To save power, you need to disable the application processor and power supply for most devices, then wake up with a timer or wireless module. Therefore, it is not absolute that the power supply is not switched off.) When the user powers on the device, the device will not be restarted like a PC, but will be awakened and returned to the same status as before the system hangs. This causes an application to run as before being suspended after being awakened. In fact, the application does not know that it is suspended unless it explicitly requests to notify the system when it is suspended. From the application perspective, there are three ways to manage power: querying Power status, changing power status, and preventing power status changes. Query Power statusTo query the current power status, you must call DWORD getsystempowerstatusex2 (psystem_power_status_ex2 psystempowerstatusex2, DWORD dwlen, bool fupdate). The function includes three parameters: a pointer pointing to the system_power _ status_ex2 structure, the length of the structure, and a Boolean value, indicates whether the operating system should query the battery driver to obtain the final information or directly return the information in the battery cache. The system queries the battery status every five seconds. Therefore, if the third difference is false, the obtained data will not be too old. The structure identifier is defined as typedef struct _ detail {byte aclinestatus; byte identifier; byte reserved1; DWORD batterylifetime; DWORD identifier; byte reserved2; byte identifier; byte reserved3; DWORD backupbatterylifetime; DWORD backupbatteryfulllifetime; Word batteryvoltage; DWORD batterycurrent; DWORD Batt Eryaveragecurrent; DWORD batteryaverageinterval; DWORD temperature; DWORD batterytemperature; DWORD temperature; byte batterychemistry;} system_power_status_ex2; I have to warn you before I describe this huge structure, the data returned by this structure is the same as that returned by the battery drive. The same structure is sent to the battery drive to query its status. Windows CE does not verify the data returned by the battery drive. The data returned by this function depends on the battery drive, so different systems have different changes. For example, many systems do not report accurate power levels when using AC power, while others do. The application uses getsystempowerstatusex2 to automatically prevent and detect whether the system can run applications. The first region, aclinestatus, contains a flag indicating whether the system is connected to the AC power supply. If the value is ac_line_offline, the system does not use the AC power; ac_line_online indicates that the system uses the AC power; ac_line_backup_power and ac_line_unknown indicates the standby power supply and unknown power supply. In the batteryflag area, a general identifier is provided to indicate the battery status of the current system, which can have the following values: Battery_flag_highThe battery is full or close to full. Battery_flag_lowThe battery remains a little left. Battery_flag_criticalThe battery power is in a critical state. Battery_flag_chargingThe battery is currently charging. Battery_flag_no_batteryThe system has no battery. Battery_flag_unknownThe batterylifepercent area contains an estimated percentage of battery power that can be maintained. A value may be between 0 and 100, or 255 indicates that the percentage is unknown. The batterylifetime area indicates the number of seconds that can be maintained before the battery is exhausted. If this value cannot be estimated, enter battery_life_unknown in the region. The batteryfulllifetime area contains the time required to fully fill the battery. If this value cannot be estimated, enter battery_life_unknown. Note that these values may be difficult to measure in many systems. Most OEMs simply enter battery_life_unknown in each region. The fourth region (not the reserved region) repeats the previous statement, except for the system backup battery. Because most of these values are difficult to measure, many systems simply return "unknown" to these regions. The remaining areas describe the power status of the battery and backup battery because many systems lack the ability to measure these values, and these areas are simply defaulted to "unknown ". The last region, batterychemistry, contains a flag indicating the type of battery in the system. Currently, the defined values include battery_chemistry_alkaline · battery_chemistry_nicd · battery_chemistry_nimh · battery_chemistry_lion · battery_chemistry_unknown. Change Power statusApplications can change the power status of the system in a series of ways. In newer Systems Based on Windows CE. net, the preferred approach is to use the power management program, which will be discussed later. However, a large number of systems based on earlier Windows CE versions and Windows CE. Net do not contain the power management program version. The following technologies are very convenient for these systems. Power offApplications can suspend the system by calling a rare gwespoweroffsystem function. This function can be used in most versions of Windows CE, but has recently been made public. In fact, most sdks do not include the prototype of this function. You may need to provide the prototype. This function is defined as void gwespoweroffsystem (void). The use of gwespoweroffsystem is simple: the system suspends after a simple call. If you want to avoid using functions with very little information, you can simply simulate the user to close the system by pressing the close button. You can easily allow your application to suspend the system by using the keybd_event function, as follows: keybd_event (vk_off, 0, keyeventf_silent, 0); keybd_event (vk_off, 0, keyeventf_silent │ keyeventf_keyup, 0); the two keybd_event calls simulate the press and release power button. The virtual key value of the power button is vk_off. Executing the preceding two lines of code suspends the system. Because the execution of the virtual key code is performed by GWES, the two functions may be in some state before the system is suspended ( Note: On the screen, there will be an image such as the close dialog box, which is the same as the image that actually presses the button.). If your program cannot stop working before the keybd_event function, add a sleep call to suspend the application for several milliseconds so that GWES can actually suspend the system. Close ScreenIf the system displays colored backlights, the main power consumption is not CPU but backlight. In some environments, an application needs to run without being displayed on the screen. One example is the music player application. When users listen to music, they do not pay attention to the screen. In these cases, the ability to turn off the backlight will increase battery life. Of course, when users want to view the screen, any shutdown backlight application requires a simple user-friendly way to re-open the screen. Likewise, you may think that the screen is turned off when the screen turns black, so consider this. For example, a user may attempt to power on the system when the system is running, but unexpectedly finds that the power of the device is disabled. Similarly, when the system closes the display in this case, it also closes the touch screen. This means that you cannot tell the user to tap the screen to open it. Instead, you need to use other events, such as setting the time, completing the task, or clicking a button. Finally, the method discussed here is useful for most versions based on Windows CE 3.0 or later and is replaced by the Power Management Program in Windows CE. Net 4.0. For newer systems, first check whether the power management program is available and then use it to control the screen. If it fails, the extescape method may work. In Windows CE, the display control is through the extescape function. This is a backdoor for displaying and printer drivers. The Windows CE display driver supports many device escape codes (Escape codes), which are published in platform builder. For our purpose, only two escape codes are used: setpowermanagement to set the displayed Power status and queryescsupport to check whether setpowermanagement is supported by the driver. The following example shows how to enable or disable the system display through the display driver and supports full escape code:

//

// Defines and structures taken from pwingdi.h in the Platform Builder

//

#define QUERYESCSUPPORT             8

#define SETPOWERMANAGEMENT          6147

#define GETPOWERMANAGEMENT          6148

typedef enum _VIDEO_POWER_STATE {

    VideoPowerOn = 1,

    VideoPowerStandBy,

    VideoPowerSuspend,

    VideoPowerOff

} VIDEO_POWER_STATE, *PVIDEO_POWER_STATE;

typedef struct _VIDEO_POWER_MANAGEMENT {

    ULONG Length;

    ULONG DPMSVersion;

    ULONG PowerState;

} VIDEO_POWER_MANAGEMENT, *PVIDEO_POWER_MANAGEMENT;

//----------------------------------------------------------------------

// SetVideoPower - Turns on or off the display

//

int SetVideoPower (BOOL fOn) {

    VIDEO_POWER_MANAGEMENT vpm;

    int rc, fQueryEsc;

    HDC hdc;

    // Get the display dc.

    hdc = GetDC (NULL);

    // See if supported.

    fQueryEsc = SETPOWERMANAGEMENT;

    rc = ExtEscape (hdc, QUERYESCSUPPORT, sizeof (fQueryEsc), 

                    (LPSTR)&fQueryEsc, 0, 0);   

    if (rc == 0) {

        // No support, fail.

        ReleaseDC (NULL, hdc);

        return -1;

    }

    // Fill in the power management structure.

    vpm.Length = sizeof (vpm);

    vpm.DPMSVersion = 1;

    if (fOn) 

        vpm.PowerState = VideoPowerOn;

    else

        vpm.PowerState = VideoPowerOff;

    // Tell the driver to turn on or off the display.

    rc = ExtEscape (hdc, SETPOWERMANAGEMENT, sizeof (vpm), 

                    (LPSTR)&vpm, 0, 0);   

    // Always release what you get.

    ReleaseDC (NULL, hdc);

    return 0;

}

The preceding Code calls the extescape and queryescsupport commands to check whether code transfer is supported. The queried command is first sent to the input buffer. If the setpowermanagement command is supported, the program fills in the video_power_management structure and calls extescape again to set the power status. Although these escape codes allow applications to turn on or off the display, Windows CE does not have a uniform way to control the brightness of the backlight. Each system has its own OEM-specific method to control the brightness of the backlight. If there is a standard backlight brightness control method in the future, it is likely to be placed in the extescape function. Turn on system powerWhen the system is suspended, the application will no longer run, so when the system wakes up, the application does not seem to be under control. However, there are some ways to wake up a suspended device. First, an application uses the notification API mentioned in Chapter 11 to Schedule System wake-up by giving a time. In general, OEMs allocate some conditions for interruption so that the management system can be powered on or awakened. An example of this method is that a system is awakened when synchronization cradle is prevented. Prevent system power-offOn the contrary, Preventing System suspension is also a problem. Windows CE is usually set to automatically suspend when user input is not input for a period of time. To prevent automatic suspension, an application can call the void winapi systemidletimerreset (void) periodically. This function resets Windows CE to monitor user input timers. If the timer reaches a pre-defined interval without user input, the system automatically suspends. Because the pending timeout value can be changed, an application needs to know the timeout value, so it needs to call systemidletimerreset a little more. The system maintains three timeout values, which can be queried using systemparametersinfo. Different manifestations of constants passed to systemparametersinfo are shown as follows: Spi_getbatteryidletimeoutThe last input time when the system is running on battery power Spi_getexternalidletimeoutThe last input time when the system is running on the AC power supply. Spi_getwakeupidletimeoutTo prevent the power from being automatically suspended when the system is suspended again, you need to query these three values and call systemidletimerreset before returning the result in the shortest time. If the timeout value is set to 0, the timeout value is disabled. Power Management ProgramA new, independent power management component is introduced in Windows CE. Net 4.0. This power management program replaces many functions previously completed by GWES. The power management program defines a series of Power states, such as D0, D1, D2, and D3. These seemingly mysterious names are mapped to some friendly system-level names. For embedded systems, OEMs define the power status of the system. For example, the power status may be on, idle, or suspend ). Other power statuses are also defined, such as screenoff, incradle, and onbattery. From the application's point of view, the new power management program provides the ability to notify the power status change and the ability to change the power status through a series of functions. The system's power status is defined in the registry. The SDK defines pwrmgr_reg_key, so that you have to know the registry string, but when the constant is not defined, the Power Manager registration data is retained in HKEY_LOCAL_MACHINE/system/CurrentControlSet/control/power. The power status is defined as the sub-key, located in the key State. Power supply notificationA very popular feature of the Power Management Program is the ability to notify the application when the system power status changes. This frees applications from manual power detection. An application can send a notification to the application when the power status changes by calling requestpowerconfigurications to request the Power Manager. The power management program sends notifications through a message queue established before the application. The following is a prototype of requestpowerconfigurications. Handle requestpowerconfigurications (handle hmsgq, DWORD flags); the first parameter is the handle of a message queue established by an application. The second parameter is a series of parameters, indicating the notification that the application wants to receive. Pbt_transitionReceive notifications of system power status changes. For example, when the system is from on to suspend. Pbt_resumeReceive notifications when the system resume. Pbt_powerstatuschangeThe system receives notifications when switching between the AC and the battery. Pbt_powerinfochangeReceive notifications when the system battery level changes. Power_policy_allReceive all notifications. The requestpowernotifications function returns a power notification handle, and a failure returns NULL. When a message queue is created, the application must have the read permission because the application will read the power notification from the message queue. To receive notifications, the application must use waitforsingleobject to block the message handle. As discussed in Chapter 10th, when a notification is placed in a queue, the handle is signaled. The actual notifications will be received in the power_broadcast table. Typedef struct _ power_broadcast {DWORD message; DWORD flags; DWORD length; wchar systempowerstate [1];} power_broadcast, * ppower_broadcast; the first note is that the structure length is variable. The last field, systempowerstate, is defined as wchars type, but can be filled with non-string data. The first field is the ID of the notification, which can be filled in with one of the previous PBT _ flag lists. The flags area can contain the following flag, depending on the received notification: power_state_on is in the on status. The power_state_off system is off. The power_state_critical system enters a critical off state. The power_state_boot system is starting. The power_state_idle system enters the idle status. The power_state_suspend system is suspended. The power_state_reset system is reset. The last two fields are correlated. The length field is the Data Length of the systempowerstate field. The data contained in systempowerstate depends on the notification to be sent. For pbt_transition notifications, the systempowerstate field contains an identifier string for the new power status. This string ends with a non-zero value. To end a string, use the length field to specify the length of the string. Note that the length field is in bytes. When the character is a double-byte uncode character, you must use the length field to remove the size of tchar. For pbt_powerinfochange notifications, the systempowerstate field contains a struct structure: typedef struct _ detail {DWORD dwnumlevels; DWORD dwbatterylifetime; DWORD hour; byte baclinestatus; byte bbatteryflag; byte bbatterylifepercent; byte bbackupbatteryflag; byte bbackupbatterylifepercent;} power_broadcast _ Power_info, * ppower_broadcast_power_info; note that the names and functions of some fields are very similar to the system_power_status_ex2 structure discussed earlier. Set Power statusThe function provided by the Power Management Program also allows the application to control the power status. There are two ways to control the power supply. The first way is to give the application a power setting. The second method is that the application requests the power status not lower than the given level. An application can request a specific power status by calling the setsystempowerstate function. The function is prototype as follows.

         DWORD SetSystemPowerState (LPCWSTR psState, DWORD StateFlags,

DWORD options); The Power status can be requested by specifying the first two parameters. If the first parameter is a non-zero value, it points to a string to identify the requested status. This string must match one of the power States listed in the registry. If psstate is null, the second parameter stateflags defines the request Power status. This parameter is one of the statuses from power_state_on to power_state_reset, which are described in the previously mentioned power_broadcast structure. Specifically, the power_state_reset flag. This indicates that the request system is restarted. Using the setsystempowerstate method is better than calling kerneliocontrol by using the ioctl_hal_reboot command directly. Call setsystempowerstate to save any data in the buffer to the file system before the device is restarted. Calling setsystempowerstate is a method that directly changes the power status. The more clever way is to call setpowerrequirement to request the system to maintain the minimum power status required by the application. Setsystempowerstate assumes that the application knows the desired state, and the call to setpowerrequirement allows the system to optimize the power supply settings to meet the needs of the application. One example that makes it easier to use setpowerrequirement is that an application using the serial port needs to maintain the power status during the serial port communication. Setpowerrequirement is defined as follows. Handle setpowerrequirement (pvoid pvdevice, cedevice_power_state devicestate, ulong deviceflags, pvoid pvsystemstate, ulong stateflags); the first parameter specifies the device whose application needs to maintain the power status. The devicestate parameter defines the power status of the device. Cedevice_power_state specifies that the status range is from D0 (meaning that the device is in the maximum power consumption state) to D4 (indicating that the device is disabled )( Note: in fact, the specific performance of D0 to D4 is completely customizable by OEMs. For application developers, for example, whether the LCD backlight is switched on d1 or on d2, they are all uncertain. Microsoft only provides standard definitions, not actual definitions.). The deviceflags parameter is composed of two flags: power_name, indicating that the device name is valid; power_force, indicating that the device should be in the current State or even when the system is suspended. If pvsystemstate is not null, it indicates that it is valid only for power requests named in pvsystemstate. The device may not be able to change the Request status. The application should cancel the request by calling releasepowerrequirement. The prototype is as follows. DWORD releasepowerrequirement (handle hpowerreq); the only parameter here is the handle returned from setpowerrequirement. In the next chapter, I will continue to discuss about the drivers and services of Windows CE streaming devices. Although most application developers may not need to write some device drivers or services, it is inspiring to know how they work with the program. Let's take a look.