Digital Power Management: Analysis and Implementation of Windows Mobile Power Management

Nowadays, in the field of embedded systems represented by digital consumer products, most systems are powered by batteries. Due to the limited battery capacity, it has become an important issue to achieve low power consumption and extend standby time of products. When the power consumption of hardware circuits has been determined, improving the efficiency of battery power is an important task to achieve low power consumption. The basic idea is to put the system in the lowest possible energy state when there are no tasks waiting to run in the system, and then wake it up quickly when there are tasks to be executed, so as to use power consumption as effectively as possible.

1 Power Management in Windows Mobile

The power management module in the WinCE series operating system was created for the latter consideration. Figure 1 shows the operating mechanism of the power manager. Based on the actual operation of the system, the module manages the power consumption status of devices and peripherals with the CPU as the center, and realizes the conversion of the system between different power states, thereby reducing power consumption while ensuring system performance. The Windows Mobile system has further customized the power management part to make it more effective and further improve the power efficiency of the system, in view of its characteristics of being dedicated to mobile communication platforms.

The implementation of Power Manager requires the collaboration of the OS kernel, driver layer, and application layer in software. For pre-defined system power states, Power Manager maps these states to specific CPU power states and device power states. When the system power state is switched, the corresponding CPU and peripheral power state switching operations will be executed.

1.1 Interaction between power management and other parts of the system

In Windows Mobile, Power Manager is loaded by the device manager Device.exe at startup in the form of a dynamic link library named PM.dll, as shown in Figure 2.

Applications can apply to put the system power into a certain state through the API, and can also apply to set a specified device to a specific power state. Applications can also apply for power state notifications so that they can receive messages when the system power state is switched to perform corresponding operations. When the system power state needs to be switched, the power management module communicates with the power-managed devices and then calls the power-related functions of these devices to implement power management for these devices. At the same time, if an application or device driver applies for power state notifications, the power management module will send messages to the message queue.

1.2 Power states and switching between states in Windows Mobile

There are two versions of Windows Mobile, SmartPhone and Pocket PC. The PocketPC of Windows Mobile 6 is used here, which defines the following power states (the power state of Windows Mobile cannot be customized like WinCE):

ON: The state when the user interacts with the system;

Backlight OFF: If there is no user operation within a period of time (15 seconds by default), the backlight will be turned off, and no other devices will change;

Screen OFF: This state is usually entered by certain programs. For example, in a music player program, when you are listening to music, you can press a certain key to turn off the screen.

Suspend: The sleep mode of the Pocket PC, in which almost all devices are turned off until a hardware device triggers an interrupt to wake up the system. This is the state with the lowest power consumption in the Pocket PC system, and the implementation of this state directly affects the standby time;

Resuming: The state of the Pocket PC after it is awakened. The screen is off and a 15-second timer is started to decide which state to enter next. If the timer times out, the Pocket PC returns to the sleeping state.

Unattended: This state is only used in Pocket PC and the user will not be aware of it, that is, the program is executed in the background.

Here we can use the system power state machine to simply describe the Windows Mobile power management strategy. Taking Pocket PC as an example, the system power state machine is shown in Figure 3.

The power manager inside the system is responsible for coordinating the transition of power states, which are mainly triggered by timer timeouts, power button events (ON/OFF Events), user operations (User Activities), etc.

2 Implementation of Power Management on PXA270 Platform

The implementation of power management involves the coordination of software and hardware in the system. For software, it involves various levels, including the Windows Mobile kernel and device drivers, which are mainly responsible for the implementation of power management on hardware such as processors and physical peripherals. In addition, some applications will also be involved, which is mainly the coordination between the system power state and specific application requirements. The platform used here is the Windows Mobile smartphone platform based on PXA270, which is equipped with NXP's baseband processor and its peripheral circuits . To achieve GSM communication. In addition, there are functional modules such as Bluetooth and camera, so it is very necessary to optimize the power management of this platform.

2.1 Implementation of Kernel Power Management

2.1.1 Suspend/Restlume Model

For SmartPhone, the AlwaysOn model is adopted, which only turns off the backlight and screen after working for a period of time, but the system is still running. This platform implements Pocket PC and adopts the Suspend/Resume model. When the system is idle, the system can be placed in the Stasper state, at which time the system is in the lowest power consumption state, and it can be awakened when necessary. There is a trade-off between the two models. Although Always On does not have a sleep mode, the switching between Suspend/Resume and Suspend also consumes a lot of energy. The switching of the system power state will eventually lead to the call of the OEM function in the kernel. The following focuses on the implementation of power management in the kernel. In the sample BSP of Windows Mobile, there are sample code frameworks in Off.c and Xllp_SuspendAndResume.c for reference.

2.1.2 Suspend Process

In the platform implementation, the OEMPowerOff function is called when switching to the Suspend state. At this time, the peripherals are turned off and the PXA270 processor is put into sleep mode. The specific process of Suspend in OEMPowerOff, that is, the Xllp_SuspendAndResume function is as follows:

(1) Set the I bit and F bit of the current program status register CPSR to disable IR Q and F1Q interrupts;

(2) According to the address obtained in the first step, the hardware platform and OS-related registers such as Power, Interrupt, GPIO, CLOCK are saved in the global variables of the Xllp_SuspendAndResume function, that is, the values ​​of these registers are saved in SDRAM;

(3) Save the relevant register values ​​of the processor mode under the ARM architecture. In addition to the 6 processor modes of the User mode, the values ​​that need to be saved are SP, LR, and SPSR. In addition, the FIQ mode also needs to save R8~R12. In order to use the stmdb batch copy instruction, a "pseudo stack" is used here, that is, the physical space in SDRAM is used to simulate the stack;

(4) Configure the MDREFR register and set the SDRAM self-refresh frequency. In sleep mode, the SDRAM will be in self-refresh state to maintain the previously maintained state data so that it can be restored to the state before sus-pend when the system wakes up;

(5) Use the PSPR register to save the physical address of the Resume parameter, such as the restart reason, sleep mode, etc. The data of the PSPR will not be lost during sleep;

(6) Configure the PWER, PRER or PFER register to enable a specific wake-up source, here set the RTC, incoming call RING interrupt and power button wake-up;

(7) Save the status register of the current processor mode, save the MMU register, save the return address XllpRes-umePhase3 of Restlme, write back the cache, configure the CP14 register CR7, and let the processor enter the sleep mode. At this point, PXA270 enters the sleep mode and the system is in the Suspend power state.

2.1.3 Resume Process

In general, the Resume process is the opposite of Suspend. After the processor is initialized, it will load various state parameters saved in SDRAM before Suspend and restore the previous state. The process is briefly described as follows:

(1) When an enabled wake-up event occurs, the processor will start from the BootLoader and perform basic hardware initialization. It will determine whether it is a reset or sleep resume. If it is the latter, it will jump to Xllp_ResumePhase2A;

(2) In Xllp_ResumePhase2A, the parameters stored in PSPR are first retrieved, checked for errors, the MMU is reconfigured, the processor status register and stack are loaded, and the process jumps to XllpRe-sumePhase3;

(3) In XllpResumePhase3, the processor status register of the environment is loaded, and then the process returns to the OEMPowerOff function step by step. In the OEMPowerOff function, the wakeup source is obtained and then the process exits.

(4) At this time, the system is placed in the Resuming state by the Power Manager. The Power Manager determines whether to turn the system ON or continue to Suspend based on the wake-up source.

At this point, the system state has been restored to the state before sleep, the Re-sume process is ended, and the system wake-up is completed.

2.2 Device driver Power management Implementation

In addition to processor power management, Power Manager also has another major task, which is power management of devices on the platform. For devices that only have two power states, ON and OFF, Power Manager uses DeviceIOControl to call the PowerUp and PowerDown functions implemented in each device driver during Suspend and Resuming to turn the device on and off. Most devices on this platform are managed in this way, including LCD, Aladio Codec, etc. These tasks mainly involve performing some operations to turn on or off the processor I/O power in IOControl of the Wince stream driver.

For more complex devices such as GSM and Bluetooth, they need to be able to wake up in time. For example, when a call comes in while the system is in Suspend mode, the GSM module needs to wake up quickly and respond. Therefore, these devices also support sleep and other modes. When entering Suspend mode, the sleep function of these device drivers will be called accordingly to enter the power saving mode of the device. When resuming, the corresponding exit sleep function will also be called to achieve fast wakeup.

2.3 Implementation of Application Power Management

Here, I will take a DirectDraw-based camera program that I wrote as an example to illustrate the implementation of power management in an application.

First, when the camera program is turned on, after a period of preview without operation, it is not desired to enter Suspend according to the timer value. At this time, the SuspendTimeout needs to be modified regularly to prevent the system from entering the sleep state. The specific method is: start a 30 s timer and call the SystemIdleTimerReset function every 30 s. In addition, since the camera program is an Overlay display effect, after entering the camera program, if you press the power button to enter the Suspend state, the system is still in the camera program when it wakes up again, but because the LCDController of PXA270 does not create the Overlay layer again, the program cannot display the image. From the user's perspective, the camera program should be able to return to normal after the system Reume. The method is as follows: create a thread in the program, create a message queue with CreateMsgQueue, call RequestPowerNotifications to apply for power management messages, and then call WaitForSingleObject to wait for notifications. When receiving the Suspend message, send a message to reinitialize the Overlay to the program window. After Resume, the program will immediately execute the reinitialization process and the camera program will return to normal.

3 Data Analysis

The current values ​​of several typical power supply states when the system is running were measured, and the data are shown in Table 1.

For a 1200 mA/h battery, the smartphone platform can achieve a theoretical standby time of about 160 hours and a talk time of about 3 hours. In addition, the response time for sleep and wake-up is also about 1 second, indicating that Power Manager has achieved the goal of improving battery power efficiency and basically meets the needs of practical applications.