Why are sleep modes important?
A large proportion of embedded control applications do not require the processor core to be processing data at all times – the processor will often be sized to be able to respond quickly to external stimuli rather than its average workload, which might imply the use of a much slower processor. Traditionally, MCUs would simply run an idle loop when there was no useful work to be done. But, for a growing number of applications, leakage is a major component of the lifetime energy consumption of an MCU, making it essential to shut the processor core down when it is not needed.
Wireless sensor nodes and other internet-of-things applications that require long lifetimes on a single battery charge will often have a duty cycle of 1 per cent or less – more than 99 per cent of the time, the processor will be asleep, waking only to collect data periodically or to respond to unexpected events triggered by a hardware interrupt.
How are the modes typically differentiated?
MCUs aimed at low-energy applications generally support several power-down modes that offer tradeoffs between responsiveness and energy savings. Low-power modes typically range from a light sleep or standby mode that, for a substantially clock-gated design, is unlikely to be very different from an idle loop, through deep-sleep to hibernate. Each of these respective modes will typically power-down a larger set of peripherals and their clocks, increasing the time that it takes to wake from sleep. Generally, the deeper the sleep, the less power is consumed by the MCU and the longer it will take for the MCU to resume execution when it reawakens.
The wake-up time is generally the biggest obstacle to maximising energy savings during sleep. Because the MCU needs to respond quickly to interrupts, it is often the case that the core and and many of the peripherals can only enter a light-sleep mode.
A number of advanced MCUs use on-chip phase-locked loops (PLLs), generally driven by a low-frequency quartz crystal, to generate the clocks used by the MCU’s hardware cores. Ideally, these would be powered down. But it can take many milliseconds before the PLL is ready to provide a stable clock signal when it restarts.
Similarly, as with power gating techniques, the time it takes to restore state to the processor core plays a large role in determining the applicability of a particular sleep mode. For example, if a processor core is fully powered down, its software state must be saved to memory. Restoration can take thousands of clock cycles. In a lighter sleep mode, the PLLs may keep running and power maintained to registers and on-chip memory, possibly using a lower voltage to allow them to ‘drowse’ but still keep their state.
Are there ways to improve the responsiveness of sleep modes?
Although vendors have worked on ways to speed up PLL restart, the main technique used to maintain responsiveness in deep-sleep modes is to use dedicated hardware blocks to offload interrupt processing from the processor core. These blocks can often run at low voltages and at much lower energy than a processor core that executes software. These hardware cores are used to keep the processor powered down for longer – only waking the MCU when the inputs move outside preprogrammed bounds or a task needs the additional horsepower of the processor.
Examples of hardware assist for MCUs are the Atmel Sleepwalking system and the Lesense core of Energy Micro. NXP Semiconductor has employed secondary processor cores in concert with a event-processing engine for some of its MCUs based around the ARM Cortex-M4. The event-processing module can handle a number of conditions using its programmable state machine, only waking the low-power Cortex M0 when it can do no more. The M0, in turn, only wakes the M4 when additional processing power is required.
The article describes the context and need for embedded operating systems that are more responsive to the power management demands placed on today’s electronic devices. It reviews the design objectives for the two main types of power management, reactive and proactive, and examines how both can be implemented. For system developers designing portable electronic devices, […]
View All Sponsors