tep112.txt

tinyos-2.x.rar

====================================================================
Microcontroller Power Management
====================================================================

:TEP: 112
:Group: Core Working Group 
:Type: Documentary
:Status: Draft
:TinyOS-Version: 2.x
:Author: Robert Szewczyk, Philip Levis, Martin Turon, Lama Nachman, Philip Buonadonna, Vlado Handziski

:Draft-Created: 19-Sep-2005
:Draft-Version: $Revision: 1.8 $
:Draft-Modified: $Date: 2009/07/07 19:03:33 $
:Draft-Discuss: TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu>

.. Note::

   This memo documents a part of TinyOS for the TinyOS Community, and
   requests discussion and suggestions for improvements.  Distribution
   of this memo is unlimited. This memo is in full compliance with
   TEP 1.

Abstract
====================================================================

This memo documents how TinyOS manages the lower power state of a
microcontroller.


1. Introduction
====================================================================

Microcontrollers often have several power states, with varying power
draws, wakeup latencies, and peripheral support. The microcontroller
should always be in the lowest possible power state that can satisfy
application requirements. Determining this state accurately requires
knowing a great deal about the power state of many subsystems and
their peripherals. Additionally, state transitions are common. Every
time a microcontroller handles an interrupt, it moves from a low power
state to an active state, and whenever the TinyOS scheduler finds the
task queue empty it returns the microcontroller to a low power state.
TinyOS 2.x uses three mechanisms to decide what low power state it
puts a microcontroller into: status and control registers, a dirty
bit, and a power state override. This memo documents these mechanisms
and how they work, as well as the basics of subsystem power
management.


2. Background
====================================================================

The TinyOS scheduler[2_] puts a processor into a sleep state when
the task queue is empty. However, processors can have a spectrum of
power states. For example, the MSP430 has one active mode (issuing
instructions) and five low-power modes. The low power modes range from
LPM0, which disables only the CPU and main system clock, to LPM4,
which disables the CPU, all clocks, and the oscillator, expecting to
be woken by an external interrupt source. The power draws of these low
power modes can differ by a factor of 350 or more (75 uA for LPM0 at
3V, 0.2 uA for LPM4). Correctly choosing the right microcontroller low
power state can greatly increase system lifetime.

TinyOS 1.x platforms manage MCU power in several different ways, but
there are commonalities in the approaches. The mica platforms, for
example, have a component named HPLPowerManagement, which has a
commands for enabling and disabling low power modes, as well as a
command (adjustPower()) to tell it to compute the low power state
based on the configuration of its various control and status
registers, storing the result in the Atmega128's MCU control
register. When TinyOS tells the microcontroller to go to sleep, it
uses the control register to decide exactly which power state to go
into. In contrast, MSP430 based platforms such as Telos and eyes
compute the low power state every time the scheduler tells the system
to go to sleep.

Each of the two approaches has benefits and drawbacks. The 1.x mica
approach is efficient, in that it only calculates the low power state
when told to. However, this leaves the decision of when to calculate
the low power state to other components, which is an easy way to
introduce bugs. The lack of a well-defined hardware abstraction
architecture in 1.x exacerbates this problem. In contrast, the MSP430
approach is simpler, in that the system will always enter the right
power state without any external prompting. However, it is
correspondingly costly, introducing 40-60 cycles of overhead to every
interrupt that wakes the system up, which can be a bottleneck on the rate
at which the system can handle interrupts.

Both of these approaches assume that TinyOS can determine the correct
low power state by examining control and status registers. For
example, the MSP430 defaults to low power mode 3 (LPM3) unless it
detects that Timer A, the USARTs, or the ADC is active, in which case
it uses low power mode 1 (LPM1). From the perspective of what
peripherals and subsystems might wake the node up or must continue
operating while the MCU sleeps, this is true. However, power modes
introduce wakeup latency, a factor which could be of interest to
higher-level components. While wakeup latency is not a significant
issue on very low power microcontrollers, such as the Atmega128 and
MSP430, more powerful processors, such as the Xscale family (the basis
of platforms such as the imote2) can have power states with wakeup
latencies as large as 5ms. For some application domains, this latency
could be a serious issue. Higher level components therefore need a way
to give the TinyOS microcontroller power manager information on their
requirements, which it considers when calculating the right low power
state.

3. Microcontroller Power Management
====================================================================

TinyOS 2.x uses three basic mechanisms to manage and control
microcontroller power states: a dirty bit, a chip-specific low power
state calculation function, and a power state override function.  The
dirty bit tells TinyOS when it needs to calculate a new low power
state, the function performs the calculation, and the override allows
higher level components to introduce additional requirements, if
needed.

These three mechanisms all operate in the TinyOS core scheduling loop,
described in TEP 106: Schedulers and Tasks[2_]. This loop is
called from the boot sequence, which is described in TEP 107: Boot
Sequence[3_]. The command in question is
``Scheduler.taskLoop()``, when microcontroller sleeping is enabled.

If this command is called when the task queue is empty, the TinyOS
scheduler puts the microcontroller to sleep. It does so through
the ``McuSleep`` interface:

|  ``interface McuSleep {``
|    ``async command void sleep();``
|  ``}``

``McuSleep.sleep()`` puts the microcontroller into a low power sleep
state, to be woken by an interrupt. This command deprecates the
``__nesc_atomic_sleep()`` call of TinyOS 1.x. Note that, as the 1.x
call suggests, putting the microcontroller to sleep MUST have certain
atomicity properties. The command is called from within an atomic
section, and MUST atomically re-enable interrupts and go to sleep. An
issue arises if the system handles an interrupt after it re-enables
interrupts but before it sleeps: the interrupt may post a task, but
the task will not be run until the microcontroller wakes up from sleep.

Microcontrollers generally have hardware mechanisms to support this
requirement. For example, on the Atmega128, the ``sei`` instruction
does not re-enable interrupts until two cycles after it is issued (so
the sequence ``sei sleep`` runs atomically).

A component named ``McuSleepC`` provides the McuSleep interface, and
``TinySchedulerC`` MUST automatically wire it to the scheduler
implementation. McuSleepC is a chip- or platform-specific component,
whose signature MUST include the following interfaces:

|  ``component McuSleepC {``
|    ``provides interface McuSleep;``
|    ``provides interface PowerState;``
|    ``uses interface PowerOverride;``
|  ``}``
|
|  ``interface McuPowerState {``
|    ``async command void update();``
|  ``}``
|
|  ``interface McuPowerOverride {``
|    ``async command mcu_power_t lowestState();``
|  ``}``


McuSleepC MAY have additional interfaces.

3.1 The Dirty Bit
====================================================================

Whenever a Hardware Presentation Layer (HPL, see TEP 2: Hardware
Abstraction Architecture[1_]) component changes an aspect of
hardware configuration that might change the possible low power state
of the microcontroller, it MUST call McuPowerState.update(). This is
the first power management mechanism, a *dirty bit*. If
McuPowerState.update() is called, then McuSleepC MUST recompute the
low power state before the next time it goes to sleep as a result of
McuSleep.sleep() being called.


3.2 Low Power State Calculation
====================================================================

McuSleepC is responsible for calculating the lowest power state that
it can safely put the microcontroller into without disrupting the
operation of TinyOS subsystems. McuSleepC SHOULD minimize how often it
must perform this calculation: it is an inherently atomic calculation,
and so if performed very often (e.g., on every interrupt) can