IMPLEMENTING POWER MANAGEMENT

FEATURES ON THE NUCLEUS RTOS

ADAM KAISER, NUCLEUS RTOS ARCHITECT

W H I T E P A P E R

E M B E D D E D S O F T W A R E

w w w.m e n t o r.c o m
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.

w w w. m e nto r. co m
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.

w w w. m e nto r. co m
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.

w w w. m e nto r. co m
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

Dynamic power consumption refers to power that is consumed depending on the activity in the system.
Though different activity can affect the power consumed by the peripherals (e.g. if the device transmits data
using a radio interface) we are going to focus here on the CPU activity related power consumption.

When no tasks are scheduled in the system, Nucleus allows for the processor and related hardware to enter
low power modes. To accomplish this, the CPU driver for a particular platform registers two functions:

1. CPU_Idle(UINT32 expected_idle_time, UINT32 wakeup_constraint)

2. VOID CPU_Wakeup(VOID)

The CPU_Idle function is called every time there is no task to be scheduled, while CPU_Wakeup() function is
called whenever the CPU becomes active again -- due to pre-scheduled task or an external interrupt.

w w w. m e nto r. co m
5
Implementing Power Management Features on the Nucleus RTOS

SIMPLEST CPU_IDLE/WAKEUP
The simplest CPU_Idle function simply puts the CPU into a CPU Idle state. For our reference platform this code
is shown Figure 4 below.

static VOID CPU_Idle(UINT32 expected_idle_time, UINT32 wakeup_constraint)

{
/* Disable the PMC forcing idle state */
ESAL_GE_MEM_WRITE32((CPU_PMC_REGISTER + CPU_PMC_CLOCK_DISABLE), CPU_PMC_SCDR_PCK);

/* Wait for interrupt */

ESAL_TS_RTE_CP_WRITE(ESAL_TS_RTE_CP15, 0, 0, ESAL_TS_RTE_C7, ESAL_TS_RTE_C0, 4);
}

static VOID CPU_Wakeup(VOID)

{
/* Note that PCK auto re-enables */
}
Figure 4: Example CPU_Idle and CPU_Wakeup implementation.

The CPU_Wakeup() function is empty for this implementation as the CPU automatically exits the “Wait For
Interrupt” state without any software setup requirements.

To illustrate the power savings gained we have implemented a simple test program that keeps the CPU busy
for 1 second, then sleeps for 1 second, repeating the pattern indefinitely. The results without and with our
simple CPU_Idle function are shown in Figure 5 below.

Power Values

Maximum

Calculated Average

Minimum

Figure 5: CPU_Idle power savings.

As we can see in Figure 5, the simple CPU_Idle saves ~190mA of current whenever the CPU is idle. Without
CPU_Idle implementation the power consumption would stay at ~460mA regardless of the CPU utilization3.

w w w. m e nto r. co m
6
Implementing Power Management Features on the Nucleus RTOS

ADVANCED CPU_IDLE
While the CPU Idle implemented in the previous section shows demonstrable results, Idle power consumption
can be further reduced to take advantage of specific hardware features. Our reference platform, for example,
offers the capability to put SDRAM into self-refresh mode at the cost of the power and time to enter and exit
such low power mode. Our CPU_Idle function can be modified to allow the SDRAM to enter self-refresh mode
if the expected idle time (passed to the CPU_Idle function as a parameter) is greater than a given threshold.
This value is experimentally determined by performing measurements of the cost and benefits. Figure 6
below illustrates the principle behind this determination4.

Figure 6: Determining the threshold of whether to put SDRAM in self-refresh mode.

The new CPU_Idle for our reference platform now looks like this:

static VOID CPU_Idle(UINT32 expected_idle_time, UINT32 wakeup_constraint)

{
/* Disable the PMC forcing idle state */
ESAL_GE_MEM_WRITE32((CPU_PMC_REGISTER + CPU_PMC_CLOCK_DISABLE), CPU_PMC_SCDR_PCK);

/* Place DDR2 in Self Refresh mode */

ESAL_GE_MEM_WRITE32((CPU_SDRAM_REGISTER + CPU_DDRSDRC_LPR_OFFSET),
((ESAL_GE_MEM_READ32(CPU_SDRAM_REGISTER + CPU_DDRSDRC_LPR_OFFSET) &
~CPU_DDRSDRC_LPR_LPCB_MASK) I CPU_DDRSDRC_LPR_LPCB_SR));

/* Wait for interupt */

ESAL_TS_RTE_CP_WRITE(ESAL_TS_RTE_CP15, 0, 0, ESAL_TS_RTE_C7, ESAL_TS_RTE_C0, 4);
}

3 In some cases when CPU_Idle is not implemented the current can even increase during times when there is nothing to be
scheduled, since when CPU_Idle is not implemented, the scheduler enters an infinite loop while waiting for the next interrupt
and that infinite loop can cause the CPU to consume even more power than during typical application operations.

4 In this specific reference platform the threshold is enforced by an automatic hardware timer measuring “idle DRAM time,”
therefore, it is not necessary to make this determination in CPU_Idle function.

w w w. m e nto r. co m
7
Implementing Power Management Features on the Nucleus RTOS

static VOID CPU_Wakeup(VOID)

{
/* Note that PCK auto re-enables */

/* Place DDR2 in Normal mode */

ESAL_GE_MEM_WRITE32((CPU_SDRAM_REGISTER + CPU_DDRSDRC_LPR_OFFSET),
((ESAL_GE_MEM_READ32(CPU_SDRAM_REGISTER + CPU_DDRSDRC_LPR_OFFSET) &
~CPU_DDRSDRC_LPR_LPCB_MASK) I CPU_DDRSDRC_LPR_LPCB_NORM));
}
Figure 7: CPU_Idle & CPU_Wakeup with DDR self-refresh.

Please note that this time the CPU_Wakeup function is no longer empty – in this function, we disable the
ability for SDRAM to go so self-refresh low power mode so that it doesn’t affect performance as needed.
Power savings realized by going to self-refresh mode on our reference platform are on the order of 70mA in
addition to the initial idle mode savings with the grand total of ~260mA savings at the highest CPU operating
point. The resulting power consumption using the test code from the previous section as shown in Figure 8.

Power Values

Maximum

Calculated Average

Minimum

Figure 8: Dynamic Power Consumption with more advanced CPU_Idle.

Other more advanced techniques can be used to further reduce dynamic CPU idle power consumption when
using tick suppression (see next section) to allow longer duration idle times. In some situations where idle
times are really long (and hardware allows for such long duration hardware timers) it may even be worth your
while to consider attempting to transition to a lower Operating Point and restore the original in CPU_Wakeup.
Please see the following section on Dynamic Voltage and Frequency Scaling (DVFS) for more details.

Please note that basing your CPU idle on the expected idle time pays off in systems that do not have a large
number of asynchronous external interrupts. Whenever the system receives such an external interrupt while it
is idle, the expected idle time is not met, therefore any calculated power savings will not be fully utilized.

w w w. m e nto r. co m
8
Implementing Power Management Features on the Nucleus RTOS

TICK SUPPRESSION
The Nucleus OS task scheduler has a regular tick timer interrupt occurring at a fixed interval in order to
perform task scheduling. This interval is typically 10ms. In order to allow the CPU idle time to be longer than
this interval, tick suppression must be enabled. Tick Suppression in Nucleus is fully automatic and requires
only that the software developer enable it. To enable tick suppression, all that is required is generate a call
to an API:

NU_PM_Start_Tick_Suppress ();

And to disable it:

NU_PM_Stop_Tick_Suppress ();

Tick suppression can generally be enabled and left enabled without any drawbacks. The way tick suppression
works is that whenever the scheduler sees an expected idle time (no tasks to be scheduled) longer than the
time remaining to the next scheduled timer interrupt, it reschedules the next tick/interval timer interrupt to a
much later time (either when the next known tasks are scheduled to run or to a maximum possible tick timer
value). Upon coming out of the idle state, whether the exit was caused by the scheduled interval timer
interrupt or an asynchronous external interrupt, the system time and other state information is properly
adjusted so that any running tasks are not affected – they see “the world” the same regardless if tick
suppression happened or not.

To illustrate how tick suppression works, Figure 9 shows the power consumption of a system running a test
pattern of busy and idle times with tick suppression disabled.

Power Values

Maximum

Calculated Average

Minimum

Figure 9: Tick supression disabled.

w w w. m e nto r. co m
9
Implementing Power Management Features on the Nucleus RTOS

In Figure 10 below, we show the very same test pattern but with tick suppression enabled. As you can see
in this graph a large number of power spikes are gone since the tick processing never actually happened.

Power Values

Maximum

Calculated Average

Minimum

Figure 10: Tick suppression enabled power consumption.

(IMPORTANT NOTE ON TICK SUPPRESSION AND POWER SAVINGS)

Nucleus ticks are very short in duration and therefore use very little power. This means that just suppressing the
ticks can have a very small effect on power consumption. For example at 400MHz on the reference platform a single
tick only runs for ~2us, which means that at a rate of 100 ticks per second (10ms interval) suppressing ticks alone
will at most save 0.02% CPU utilization which is not very significant. The obvious question here is why do tick
suppression at all? The answer is because tick suppression allows the CPU to stay idle for a much longer time,
multiplying savings from such techniques as DRAM self-refresh mode or changing operating points in idle. This
multiplication of savings can be significant. To illustrate this let’s revisit Figure 6 – in this diagram, tick suppression
allows the energy saved (red area) to be increased multiple times (100’s of times in some situations) by simply
lengthening the contiguous time duration that CPU spends in idle.

One other point worth mentioning is that in order to capture power spikes due to ticks on a power graph, measured
current needs to be sampled at a sufficiently enough rate to capture such short duration “blips.”

w w w. m e nto r. co m
10
 Implementing Power Management Features on the Nucleus RTOS

DYNAMIC VOLTAGE AND FREQUENCY SCALING (DVFS)

The benefit of scaling voltage and frequency is reduced power consumption of the CPU and the attached
peripherals. The cost is reduced peak performance. An Operating Point is a set voltage and frequency in which
the CPU and/or the system can operate5. Typically, the voltage is determined by the minimum voltage that
can sustain a set CPU frequency, therefore it usually doesn’t make sense to have two different operating
points at the same frequency, but at different voltages. There are exceptions to this when a specific peripheral
requires different voltages for a specified frequency and the voltage is chosen to meet the requirements of
the highest voltage peripheral enabled.

Nucleus abstracts DVFS in terms of operating points. The number of supported operating points can be
obtained from the Nucleus Power Services by calling the NU_PM_Get_OP_Count () API. Information about
each operating point, including frequency (or frequencies if there are multiple clocks in the system) and
voltage can be obtained by calling APIs such as NU_PM_Get_Freq_Info(), NU_PM_Get_Voltage_Info() and
NU_PM_Get_OP_Specific_Info(). For more information on this topic please see the Nucleus power reference
manual6.

Determining the optimal operating point for a particular functionality is best done using measurements.
Ideally, power can be measured at different operating points on the final hardware design while performing
the desired function (e.g. playing music). The optimal operating point is the one that fulfills the performance
requirement and consumes the least power to complete the job.

The problem of finding the optimal operating point can alternatively be approached by a combination of
some simpler measurements and calculations. Since the total power consumed by the device can be divided
between static and dynamic utilization, we can measure each component independently. Both the static and
dynamic power consumption components are typically a function of an operating point. Let’s start by
re-measuring the static power consumption measured in the “System Power States” section earlier in this
paper for each operating point of interest. For our purposes, we’ll pick three different operating points shown
in table below (Figure 11). Note that this reference platform does not support voltage scaling and therefore
only the frequency varies between operating points.

Operating Point Frequency

(MHz)
OP1 400
OP2 200
OP3 133
Figure 11: Table of operating points (OP) tested.

5 In Nucleus, an operating point can also define additional independent clocks and such as DRAM clock and other parameters
such as clock divider settings, etc. Use NU_PM_Get_OP_Specific_Info() API to retrieve the additional information.

6 A Nucleus® Power Management Services Reference Manual is available with Nucleus OS.

w w w. m e nto r. co m
11
Implementing Power Management Features on the Nucleus RTOS

Since we want to measure the static power consumption we made sure that the test application is idle
(sleeping) after setting the system power state and the operating point. A simple application shown in
Figure 12 below accomplishes this task.

#define eMHZ_133 1
#define eMHZ_200 2
#define eMHZ_400 3

static VOID PMF_Task_Entry(UNSIGNED argc, VOID *argv)

{
PM_STATUS pm_status;

pm_status = NU_PM_Set_System_State(eLCD_OFF_USBH_OFF);
pm_status = NU_PM_Start_Tick_Suppress();

while (1)
{
pm_status = NU_PM_Set_Current_OP(eMHZ_400);
NU_Sleep(1*NU_PLUS_TICKS_PER_SEC);

pm_status = NU_PM_Set_Current_OP(eMHZ_200);
NU_Sleep(1*NU_PLUS_TICKS_PER_SEC);

pm_status = NU_PM_Set_Current_OP(eMHZ_133);
NU_Sleep(1*NU_PLUS_TICKS_PER_SEC);
}
}
Figure 12: Operating point test application.

The resulting power consumption is shown in Figure 13 below.

 

Power Values

Maximum

Calculated Average

Minimum

Figure 13: Power consumption at different operating points.

w w w. m e nto r. co m
12
Implementing Power Management Features on the Nucleus RTOS

Next, we repeated these measurement for each system state and we the resulting power consumption is
shown in the table below (Figure 14).

System State Operating Power Consumption (Idle)

Point [mA]

STATE 1 OP1 162

OP2 185
OP3 202
STATE 2 OP1 190
OP2 212
OP3 232
STATE 3 OP1 PM_REQUEST_BELOW_MIN
OP2 PM_REQUEST_BELOW_MIN
OP3 325
STATE 4 OP1 PM_REQUEST_BELOW_MIN
OP2 PM_REQUEST_BELOW_MIN
OP3 402

Figure 14: Idle static power measurements.

Notice that for states 3 and 4 OP1 and OP2 do not show results. PM_REQUEST_BELOW_MIN code is returned
by the NU_PM_Set_Current_OP() API indicating that some entity has requested that the operating point not
transition below OP3. In our case it’s the LCD driver that cannot operate properly at the lower operating
points and therefore it issues a minimum operating point request preventing the system from transitioning
any lower. As soon as the LCD driver is turned off, the operating point transitions are allowed again.

w w w. m e nto r. co m
13
Implementing Power Management Features on the Nucleus RTOS

Once we have the idle power consumption measured, we can modify our application to loop for a specified
period of time instead of sleeping. This will allow us to measure the 100% CPU utilization power consumption.
The results for our reference platform are shown in the table below (Figure 15).

System State Operating Power Consumption (P_Idle) Power Consumption (P_Busy)

Point [mA] [mA]

STATE 1 OP1 162 295

OP2 185 365
OP3 202 455
STATE 2 OP1 190 298
OP2 212 370
OP3 232 460
STATE 3 OP1 PM_REQUEST_BELOW_MIN PM_REQUEST_BELOW_MIN
OP2 PM_REQUEST_BELOW_MIN PM_REQUEST_BELOW_MIN
OP3 325 472
STATE 4 OP1 PM_REQUEST_BELOW_MIN PM_REQUEST_BELOW_MIN
OP2 PM_REQUEST_BELOW_MIN PM_REQUEST_BELOW_MIN
OP3 402 551
Figure 15: Matrix of complete power measurement results.

Now that we have the complete measurement results we can proceed to calculating the estimated power
consumption given a system state, the operating point, and an estimated average CPU utilization. CPU
utilization should be measured at a lowest operating point that allows it to be under 100%. What that means
is a minimum operating point has to be picked that satisfies the performance requirements and the time
duration of the measurement so the average CPU utilization is under 100%.

For example, if you have a function to be performed that takes 100% CPU utilization for 1.2 seconds at
100MHz, every 2 seconds, then the average CPU utilization is 60% at 100MHz. For remaining operating points
the measured utilization can be scaled linearly with the frequency (e.g. 60% utilization at 100MHz will scale to
20% utilization at 300MHz).

The estimated power consumption can be calculated using the following equation:

Power = P_Busy(STATE,OP) * CPU_UTIL + P_Idle(STATE,OP) * (1-CPU_UTIL)

where P_Busy and P_Idle come from in Figure 15 above and CPU_UTIL is the estimated average CPU utilization
normalized to 100% = 1.00. Please note that it’s extremely important to scale the CPU utilization properly in
order to get the accurate estimated result. Given the results, one can pick the most optimal operating point
in which to attempt a switch.

So why go through all of these calculations if hardware is available to have power measured for any particular
function at any operating point? Well, with a large number of measurements, sometimes it may be easier to
calculate a large number of data points instead of measuring them, especially if every desired point is now
known at the start and hardware is not available all the time. This is where this estimation method can help.

w w w. m e nto r. co m
14
Implementing Power Management Features on the Nucleus RTOS

That said, the most exciting application for these calculations is the ability to automatically determine the
most optimal OP. Suppose that one has measured the data in Figure 15 and there exists a task that monitors
the current CPU utilization. Such a task can notice that CPU utilization is holding a steady average over some
time while the power state does not change, and attempt transitions to the most optimal calculated operating
point.

APPLICATION PROGRAMMING
When programming applications for a power-optimized system running the Nucleus RTOS, it’s important
to keep the following in mind:

1. Yield the processor (sleep, suspend on event or mutex, etc.) whenever possible. This will allow the
operating system to transition the CPU to the most optimal idle mode automatically.

2. When needing a specific system state, request it via the NU_PM_Request_Min_System_State() API only,
then release that request promptly using the NU_PM_Release_Min_System_State() API when its no
longer needed. This will allow the operating system to automatically fall back to the minimum required
state as requested by all applications in the system.

3. Avoid polled algorithms. Event interrupt and/or message driven systems should be implemented to allow
the CPU to stay Idle as long as possible. As the events get more and more frequent, there exists a point
at which the implementation should switch to polled operation in order to reduce the number of
interrupts and therefore context switches. This reduces the average CPU utilization (and therefore
power consumption) for the same load.

CONCLUSION
As embedded device deployments are growing exponentially, an ever increasing number of those
devices rely on batteries or other limited capacity power sources. Modern chipsets offer more and more
power saving features, but most of them require software complexity to fully utilize. A competitive
embedded OS today must address power management in order to simplify the design process, speed up
time to market, and increase reusability of code between different platforms by abstracting the power
saving features from the designer.

About the Author:

Adam Kaiser is a Nucleus RTOS Architect for the Mentor Embedded team at Mentor Graphics. He has an extensive expertise in
embedded power management and is responsible for architecture of the Nucleus Power Management Framework. Prior to
joining Mentor Graphics, Adam worked as a software architect for Texas Instruments (OMAP) as well as Microsoft (Windows
Mobile) where he worked closely with various mobile phone and other embedded device manufacturers focusing on power
management.

For the latest product information, call us or visit: w w w.m e n t o r.c o m

©2011 Mentor Graphics Corporation, all rights reserved. This document contains information that is proprietary to Mentor Graphics Corporation and
may be duplicated in whole or in part by the original recipient for internal business purposes only, provided that this entire notice appears in all copies.
In accepting this document, the recipient agrees to make every reasonable effort to prevent unauthorized use of this information. All trademarks
mentioned in this document are the trademarks of their respective owners.

MGC 11 - 11 TECH10420-w