tep112.txt

tinyos-2.x.rar

introduce significant overhead and jitter.

MCU power states MUST be represented as an enum in the standard chip
implementation header file. This file MUST also define a type
``mcu_power_t`` and a combine function that given two power state
values returns one that provides the union of their functionality.

For example, consider a hypothetical microcontroller with three low
power states, (LPM0, LPM1, LPM2) and two hardware resources such as
clocks (HR0, HR1). In LPM0, both HR0 and HR1 are active. In LPM1, HR0
is inactive but HR1 is active. In LPM2, both HR0 and HR1 are inactive.
The following table describes the results of a proper combine function
(essentially a MAX):

+------+------+------+------+
|      | LPM0 | LPM1 | LPM2 |
+------+------+------+------+
| LPM0 | LPM0 | LPM0 | LPM0 | 
+------+------+------+------+
| LPM1 | LPM0 | LPM1 | LPM1 |
+------+------+------+------+
| LPM2 | LPM0 | LPM1 | LPM2 |
+------+------+------+------+

In contrast, if in LPM2, HR0 is active but HR1 is inactive, the
combine function would look like this:

+------+------+------+------+
|      | LPM0 | LPM1 | LPM2 |
+------+------+------+------+
| LPM0 | LPM0 | LPM0 | LPM0 | 
+------+------+------+------+
| LPM1 | LPM0 | LPM1 | LPM0 |
+------+------+------+------+
| LPM2 | LPM0 | LPM0 | LPM2 |
+------+------+------+------+

3.3 Power State Override
====================================================================

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
the MCU is capable of. The return value of this command is a
``mcu_power_t.`` McuSleepC MUST respect the requirements of the return
of this call and combine it properly with the low power state it
computes.

The PowerOverride functionality exists in case higher-level components
have some knowledge or requirements that cannot be captured in
hardware status and configuration registers, such as a maximum
tolerable wakeup latency. Because it can overrides all of the MCU
power conservation mechanisms, it SHOULD be used sparingly, if at
all. Because it is called in an atomic section during the core
scheduling loop, implementations of PowerOverride.lowestState() SHOULD
be an efficient function, and SHOULD NOT be longer than twenty or
thirty cycles; implementations SHOULD be a simple return of a cached
variable. Wiring arbitrarily to this command is an easy way to cause
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.

4. Peripherals and Subsystems
====================================================================

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``,
or ``AsyncStdControl``.
These interfaces are imperative in that when any component calls
``stop`` on another component, it causes the subsystem that
component represents to enter an inactive, low-power state.

From the perspective of MCU power management, this transition causes a
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 
greater detail, and TEP 108[4_] describes how TinyOS can automatically
include power management into shared non-virtualized devices.

5. Implementation
====================================================================

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 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 
``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.

6. Author's Address
====================================================================

| Robert Szewczyk
| Moteiv Corporation
| 2168 Shattuck Ave, Floor 2
| Berkeley, CA 94704
|
| email - [e-mail]
|
|
| Philip Levis
| 358 Gates
| Computer Science Laboratory
| Stanford University
| Stanford, CA 94305
|
| phone - [phone]
| email - [e-mail]
|
|
| Martin Turon
| PO Box 8525
| Berkeley, CA 94707
|
| phone - [phone]
| email - [e-mail]
|
|
| Lama Nachman
| 3600 Juliette Lane, SC12-319
| Intel Research
| Santa Clara, CA 95052
|
| email - [e-mail]
|
|
| Phil Buonadonna
| Arched Rock Corp.
| 2168 Shattuck Ave. 2nd Floor
| Berkeley, CA 94704
|
| phone - [phone]
| email - [e-mail]
|
|
| Vlado Handziski
| Sekr FT5
| Einsteinufer 25
| 10587 Berlin
| GERMANY
|
| email - [e-mail]
|

6. Citations
====================================================================

.. [1] TEP 2: Hardware Abstraction Architecture

.. [2] TEP 106: Schedulers and Tasks.

.. [3] TEP 107: TinyOS 2.x Boot Sequence.

.. [4] TEP 108: Resource Arbitration

.. [5] TEP 115: Power Management of Non-Virtualised Devices