[Tinyos-beta-commits]
CVS: tinyos-1.x/beta/teps/txt tep112.txt, NONE, 1.1
Martin Turon
mturon at users.sourceforge.net
Fri Sep 2 19:01:17 PDT 2005
Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/txt
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv19309
Added Files:
tep112.txt
Log Message:
Initial version -- Power Management TEP112
--- NEW FILE: tep112.txt ---
============================
Power Management
============================
:TEP: 112
:Group: Core Working Group
:Type: Documentary
:Status: Draft
:TinyOS-Version: 2.x
:Author: Martin Turon, Robert Szewczyk
:Draft-Created: 19-Apr-2005
:Draft-Version: $Revision: 1.1 $
:Draft-Modified: $Date: 2005/09/03 02:01:15 $
: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 power management is done in TinyOS, the
general design principles followed by components that affect power,
and interfaces by which a developer can influence the power state.
1. Introduction
====================================================================
This document defines the various power management techniques available
in TinyOS. There are three disctint levels that are addressed, each with
their own considerations:
* Microcontroller (including subsystems such as timers and adc)
* Platform (flash, radio, and other peripheral chips)
* Application (including specific sensors)
It is likely there will be applications with specific concerns that cannot
conform to this specification, but following as closely to its spirit as
possible will simplify generic applications.
2. Background
====================================================================
The original TinyOS power management is as powerful as it is simple.
The philosophy is that once the task queue is empty, the processor
will automatically go to sleep. At the component level, a StdControl
interface is used to start or stop the use of power as required.
* MCU (automatic)
* Component (manual)
None of these concepts are to go away. Rather, this proposal adds
extensions to each area to better handle some common cases:
* MCU -- a notification hook for the platform HAL to quickly
set pin states accordingly during MCU sleep/wake.
* Component -- a set of services to power up a component and
automatically "spin down" during periods of
inactivity.
3. HPL Sleep Notification
====================================================================
Historically, TinyOS uses a section of "adjustPower" code to calculate
the desired sleep mode of the processor depending on the current
conditions such as ADC and Timer state.
command HPLPwrMgr.adjustPower {
// chips/CPU determines exact sleep mode
if (external timers running) {
mode = IDLE;
} else if (radio running) {
mode = IDLE;
} else if (adc running) {
mode = ADC_NR;
} else {
mode = POWER_SAVE;
}
sleep_state = mode;
}
This code is to use a proper HPL interface into the MCU and not directly
call registers by punching through the HPL abstraction layer. As such,
it must be called by a wired in component. This must happen in the
scheduler:
[scheduler]
while (1) {
<do tasks>
atomic {
signal HPLPwrMgr.sleep();
__nesc_atomic_sleep();
}
signal HPLPwrMgr.wake();
}
The HPLPwrMgr.sleep event is in a critical timing path for sleeping the
processor. It is crucial that this code be extremely efficient. The
first job of the sleep() code is to run adjustPower only if necessary.
This can be determined by a dirty flag in the power management state that
subsytems are required to responsibly set if they are started or stopped.
async atomic event HPLPwrMgr.sleep() {
if (pwr_state.bits.dirty) {
call HPLPwrMgr.adjustPower();
}
// set power down pin states
}
4. Platform Pin State Management
====================================================================
When a node goes to sleep, it assumes that all GPIO pins are in the proper
state. A platform may want to intercept a signal when the node is powering
down to properly insure that pins it is responsible for are set correctly.
This is especially true for a platform subsystem such as external flash or
a thermistor that draws contiuous power when its Pwr pin is set high. Such
devices may have nominal power consumtion relative to the MCU, have minimal
latency requirements, and are convenient to have available while running.
For devices with these properties, it makes sense to quickly powered them
down with a GPIO pin when the MCU goes to sleep.
In this way, a platform can specify reasonable defaults for pin-setting in
its implementation of the HPLPwrMgr.sleep event. Restoration of these
pin settings are done in the HPLPwrMgr.wake event, and account for whether
the device has been started or stopped by the application:
async atomic HALFlashPwrMgr.sleep() {
// this must be fast, responsible code: just flip one pin!
call HPLFlashPwrPin.clr();
}
async HALFlashPwrMgr.wake() {
if (flash_started) call HPLFlashPwrPin.set();
}
Note: for flash devices that use a bus command to set it into standby
mode, this interface is not suggested. The HPLPwrMgr code path must be
fast, is run in atomic context, and is reserved for simple pin management
and sleep mode calculations.
5. Sensor Power Management
====================================================================
Managing the power of individual devices in the system should be decoupled
as much as possible from the MCU sleep. Modern processors can sleep and
wake very quickly, and are on a different time scale from sensor devices
which have warm up times and other latency requirements. This section
attempts to address the concerns of simplifying sensor and device power
management by specifying a set of general components that handle common
application cases.
An interesting example is to consider the following case: suppose you have a
sensor that takes 2 seconds to warm up; its driver implements start, stop,
and sampling methods correctly. The application samples the sensor
periodically. Now, the power states of that sensor may look very different
when you tell it to sample 10 times a second vs. 1 time per minute. How
should this latency and sampling rate be embedded in the individual
components? How should this be presented to the developer or network
manager? This points to a set of basic power mgmt policy components
that wrap the AcquireData interface with an internal timeout.
6. Application Services
=====================================================================
AutoPowerBasic
An AutoPowerBasic component would provide the StdControl and AcquireData
interfaces. If you stop the sensor, it will remain off. If you start it,
it will only power on when you signal getData. The initial getData request
will start up the sensor and internally manages warm up time latency.
Subsequent getData requests reset the timeout. Finally, after a designated
period of inactivity, the timeout timer fires and the sensor is put to sleep.
The exact length of the timeout can be a generic component parameter and
tuned by the sensor board driver developer to a reasonable default value.
AutoPowerAdvanced
Other wrapper components could provide a facility to preWarm() the sensor
ahead of an actual getData request. An advanced interface would also
allow an explicit ability to setTimeout() time. In addition, an advanced
power management wrapper component may want to provide a getDataContinous
style interface and power down immediately after the dataReady returns that
a burst has ended.
7. Author's Address
====================================================================
| Martin Turon
| PO Box 8525
| Berkeley, CA 94707
|
| phone - +1 408 965 3355
| email - mturon at xbow.com
|
More information about the Tinyos-beta-commits
mailing list