| Robert Szewczyk, Philip Levis, Martin Turon, Lama Nachman, Philip Buonadonna, Vlado Handziski | |
| Draft-Created: | 19-Sep-2005 |
|---|---|
| Draft-Version: | 1.7 | +
| Draft-Version: | 1.8 |
| Draft-Modified: | 2007-01-10 | +
| Draft-Modified: | 2009-07-07 |
| 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 @@ -318,13 +313,13 @@ requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This memo is in full compliance with TEP 1.
This memo documents how TinyOS manages the lower power state of a microcontroller.
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 @@ -340,8 +335,8 @@ bit, and a power state override. This memo documents these mechanisms and how they work, as well as the basics of subsystem power management.
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 @@ -393,8 +388,8 @@ to give the TinyOS microcontroller power manager information on their requirements, which it considers when calculating the right low power state.
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 @@ -457,8 +452,8 @@ whose signature MUST include the following interfaces:
McuSleepC MAY have additional interfaces.
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 @@ -468,8 +463,8 @@ 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.
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 @@ -549,8 +544,8 @@ combine function would look like this:
When McuSleepC computes the best low power state, it MUST call PowerOverride.lowestState(). McuSleepC SHOULD have a default implementation of this command, which returns the lowest power state @@ -572,9 +567,16 @@ TinyOS to behave badly. The presence of a combine function for mcu_power_t means that this command can have fan-out calls.
Section 5 describes one example use of McuPowerOverride, in the timer stack for the Atmega128 microcontroller family.
+As part of power state override, a platform MUST define the enum +TOS_SLEEP_NONE in its hardware.h file. This enum defines the highest +power state of the platform's microcontroller in a chip-independent +way. If a component wires to McuPowerOverride and returns TOS_SLEEP_NONE, +this will cause TinyOS to never put the microcontroller into a power +saving state. This enum allows a component to prevent sleep in a +platform-independent way.
At the HIL level, TinyOS subsystems generally have a simple, imperative power management interface. Depending on the latencies involved, this interface is either StdControl, SplitControl, @@ -587,24 +589,34 @@ change in status and control registers (e.g., a clock is disabled). Following the requirements in 3.1, the MCU power management subsystem will be notified of a significant change and act appropriately when the system next goes to sleep. TEP 115[5] -describes the power management of non-virtualized devices in +describes the power management of non-virtualized devices in greater detail, and TEP 108[4] describes how TinyOS can automatically include power management into shared non-virtualized devices.
An implementation of McuSleepC can be found in tinyos-2.x/tos/chips/atm128, +
An implementation of McuSleepC can be found in tinyos-2.x/tos/chips/atm128, tinyos-2.x/tos/chips/msp430, and tinyos-2.x/tos/chips/px27ax.
-An example of a use of McuPowerOverride can be found in the atmega128 timer +
An example use of McuPowerOverride can be found in the atmega128 timer system. Because some low-power states have much longer wakeup latencies than others, the timer system does not allow long latencies if it has a timer -that is going to fire soon. The implementation can be found in +that is going to fire soon. The implementation can be found in tinyos-2.x/tos/chips/atm128/timer/HplAtm128Timer0AsyncP.nc, and tinyos-2.x/tos/chips/atm128/timer/HplAtm128Timer0AsyncC.nc automatically wires it to McuSleepC if it is included.
+For the atmega128 microcontroller, TOS_SLEEP_NONE is the "idle" power +state.
+A second example use of McuPowerOverride is in the msp430 timer system. +By default, the msp430 lowest power state is LPM4, which does not keep +clocks enabled. If tinyos-2.x/tos/chips/msp430/timer/Msp430ClockC.nc'' +is included in the component graph, however, this configuration wires +the McuPowerOverride of ``tinyos-2.x/tos/chips/msp430/timer/Msp430ClockP.nc +to McuSleepC. This implemementation of McuPowerOverride raises the lowest +power state to LPM3, which keeps clocks enabled.
+For msp430 microcontrollers, TOS_SLEEP_NONE is the "active" power state.