Implementing Power Management Features on the Nucleus Rtos

IMPLEMENTING POWER MANAGEMENT FEATURES ON THE NUCLEUS RTOS ADAM KAISER, NUCLEUS RTOS ARCHITECT EMBEDDED SOFTWARE WHITEPAPER www.mentor.com Implementing Power Management Features on the Nucleus RTOS INTRODUCTION Power management on embedded devices boils down to an amazingly simple principle “turn-off anything you don’t use.” Though this sounds fairly simple, the actual implementation can be quite complex. The Nucleus® real-time operating system attempts to minimize the complexity by taking care of as many of the nitty-gritty details as possible, allowing the software developer to make high-level decisions, but also giving the developer the option of full control if desired. This paper covers a few of the power management techniques that define device static power consumption. Dynamic CPU power savings utilizing CPU_Idle functionality and the automatic tick suppression feature available in Nucleus will also be discussed. Lastly, the concept of Dynamic Voltage and Frequency Scaling (DVFS) will be covered as it applies to both static and dynamic power savings. All of the discussed techniques are analyzed when applied to the Atmel reference platform AT91SAM9M10-EKES. (IMPORTANT NOTE ON POWER MANAGEMENT USING EVALUATION BOARDS) In this document we are using the AT91SAM9M10-EKES development board. It is important to note that only relative power measurements are meaningful on most evaluation boards. You can compare two different software approaches on the same board, even figure out the power savings (total mA but not percentage of total power), the total power measured will likely be very different on optimized hardware vs. the evaluation board. Evaluation boards are often not at all optimized for power, they often have debug circuitry, LEDs/light, include inefficient voltage converters (linear regulators), and lack the ability to properly disable and/or power down external peripherals, etc. Hard wiring on an evaluation hardware makes it easier for the evaluation board since the user can use the peripheral without writing code to turn it on. It may make the evaluation board simpler and less expensive, but it also makes it not possible to save power by turning off the peripheral. In our measurements using the AT91SAM9M10-EKES development board there was a constant current of ~130mA, which in optimized hardware could be significantly reduced. STATIC POWER CONSUMPTION Static power dissipation for a specific device refers to the constant rate at which power is consumed by the device regardless of the device activity. The main factor1 that determines the static power consumption is the number of modules and peripherals that are powered on. Embedded hardware designed for power management and optimizations should allow the CPU to independently control power to as many different blocks, modules, or peripherals of the design as possible. PERIPHERAL (DRIVER) POWER STATES Within the Nucleus OS, each peripheral typically has a driver that exposes the peripheral functionality to the OS and the applications. Each such peripheral driver registers with the OS informing the OS of its capabilities. One such capability in Nucleus is the support of peripheral power states. A Peripheral Power State is a power consumption limit that is set by the operating system. Up to 256 states can be defined for each driver with minimum requirement to support 2 states – OFF and ON. Such states impose the “minimum power consumption possible, no functionality required” and “no power consumption limit, full functionality” respectively. Each driver must initialize in the OFF state which means the lowest possible power consumption without any functionality enabled. SYSTEM POWER STATES To aid the optimization of static power consumption, Nucleus OS defines a concept of a System Power State. A System Power State comprises a set of states for each peripheral in the system. An example definition of system power states for a simple MP3 player is shown in Figure 1 on the following page. 1 The other big factor is the DVFS operating point also discussed in this paper. www.mentor.com 2 Implementing Power Management Features on the Nucleus RTOS System State Audio Display Backlight SD/MMC Amplifier OFF OFF OFF OFF OFF STANDBY OFF OFF OFF OFF PLAYBACK ON OFF OFF ON USER_IDLE ON ON DIM ON USER_ACTIVE ON ON BRIGHT ON Figure 1: Example System Power States definition. It’s always a good rule of thumb to prioritize system states in order of their functionality and power consumption. The higher the state, the higher the functionality and the higher the power consumption. This type of organization allows applications to request minimum system power states required for their proper operation. For example, in our hypothetical MP3 player scenario, the task responsible for playback of music would call NU_PM_Request_Min_System_State (PLAYBACK); whenever audio files are being played. Conversely, when playback is stopped, the playback task would call NU_PM_Release_Min_System_State(handle); to inform the system that the requirement is no longer needed. Other tasks/applications can also make such requests. For example, a GUI application may request the USER_ACTIVE state while the user is interacting with the device, then relinquish that request once the user has gone idle2. Once an application makes a request for a minimum system power state, the OS will not allow the system power state to drop below the requested state. When multiple requests are in effect, the highest requested state becomes the lowest possible system power state. Such a system allows each task to request what it needs from the system without any awareness from other tasks in the system. For example, if the playback task requests a minimum system state of PLAYBACK and then the GUI task requests USER_ACTIVE, the system will be in USER_ACTIVE state until the GUI releases the request at which point the system state will drop to PLAYBACK. All this will happen without the playback task having any need to know about the GUI application. 2 Nucleus OS power services includes ‘Watchdog services’ to assist with implementation of timeouts based on user inactivity. See the Reference Power Controller provided with Nucleus for more details. www.mentor.com 3 Implementing Power Management Features on the Nucleus RTOS EXAMPLE IMPLEMENTATION To illustrate the static power consumption savings let’s take a look at an example implementation using the AT91SAM9M10-EKES platform. In this example, we have defined four system power states and wrote a simple application that transitions between the states every second. The resulting power consumption graph is shown in figure 2. The code to define the states and the test application is shown in Figure 3. To define the system power states NU_PM_Map_System_Power_State API was used (not shown here). Power Values Maximum Calculated Average Minimum Figure 2: Static power consumption in four different system power states. static VOID PMF_Task_Entry(UNSIGNED argc, VOID *argv) { PM_STATUS pm_status; while (1) { pm_status = NU_PM_Set_System_State(eLCD_ON_USBH_ON); NU_Sleep(1*NU_PLUS_TICKS_PER_SEC); SS3 pm_status = NU_PM_Set_System_State(eLCD_DIM_USBH_ON); NU_Sleep(1*NU_PLUS_TICKS_PER_SEC); SS2 pm_status = NU_PM_Set_System_State(eLCD_OFF_USBH_ON); NU_Sleep(1*NU_PLUS_TICKS_PER_SEC); SS1 pm_status = NU_PM_Set_System_State(eLCD_OFF_USBH_OFF); NU_Sleep(1*NU_PLUS_TICKS_PER_SEC); } SS0 } Figure 3: Changing system states application example. www.mentor.com 4 Implementing Power Management Features on the Nucleus RTOS DRIVER POWER MANAGEMENT Each peripheral driver has to actively and aggressively manage power consumption while obeying the peripheral power state (limit) set by the OS. Let us consider a serial driver example. A serial driver may have three supported peripheral states which are listed below in order of ascending power consumption: 1. “OFF” – The serial port is not functional, all available circuitry that can be controlled (clocks, transmitter, receiver, any RS232 level converters) is powered down and any interrupts that may come from the serial port are disabled. 2. “SLEEP” – In this state the serial power is powered off as in the OFF state, however it can receive a RING signal interrupt and pass it up to the applications or power controller. The power controller (or another application) at that point, may raise the power state of the serial port directly or by raising the system power state. 3. “ON” – In this state the serial port is expected to be fully functional and circuitry powered on as needed basis. The states OFF and SLEEP are fairly straightforward, however the ON state needs to implement logic to dynamically control the power consumption. Here are some considerations: ■ If the serial port is not opened by any applications, even though its power state is ON, the hardware should stay powered down and Rx interrupts disabled just as if it was in the SLEEP state since there is no user of the serial port. There is no requirement to burn power. A peripheral state is defined as the limit, or maximum power to be consumed, not the minimum. ■ If there is a separate control of transmitter or transmit clock, it should be disabled if there is no out- going activity on the serial port for some pre-determined amount of time. Other drivers should be implementing a similarly aggressive power management strategy. All power-aware drivers shipped as part of the Mentor® Embedded Nucleus® ReadyStart™ BSP have such algorithms implemented (limited by the abilities of the particular hardware). DYNAMIC POWER CONSUMPTION

Load more