-appropriately when the system next goes to sleep.</p>
-<p>These imperative appraoches are flexible and powerful, but are also
-very error prone, partially due to their deep semantics. For example,
-depending on the circumstances, an application calling StdControl.stop
-on a routing layer may or may not also want to turn off the underlying
-radio. StdControl and SplitControl provide a <em>mechanism</em> to control
-subsystem power states, but no real <em>policy</em> for arbitrating
-conflicting requirements from components built on top of them.</p>
-<p>Service distributions (described in TEP 110[_tep110]) are responsible
-for providing policies on top of these low-level mechanisms. OSKI, for
-example, the sample distribution described in TEP 110, uses an
-OR-policy: a subsystem is active if any of its clients want it active,
-and inactive iff all of its clients want it inactive. Other
-distributions can provide alternative power management policies in top
-of the basic HIL mechanisms.</p>
+appropriately when the system next goes to sleep. TEP 115[<a class="reference" href="#id6">5</a>]
+describes the power management of non-virtualized devices in
+greater detail, and TEP 108[<a class="reference" href="#id5">4</a>] describes how TinyOS can automatically
+include power management into shared non-virtualized devices.</p>
+</div>
+<div class="section">
+<h1><a id="implementation" name="implementation">5. Implementation</a></h1>
+<p>An implementation of McuSleepC can be found in <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/atm128</span></tt>,
+<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/msp430</span></tt>, and <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/px27ax</span></tt>.</p>
+<p>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
+<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/atm128/timer/HplAtm128Timer0AsyncP.nc</span></tt>, and
+<tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/atm128/timer/HplAtm128Timer0AsyncC.nc</span></tt> automatically
+wires it to McuSleepC if it is included.</p>
+<p>For the atmega128 microcontroller, TOS_SLEEP_NONE is the "idle" power
+state.</p>
+<p>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 <tt class="docutils literal"><span class="pre">tinyos-2.x/tos/chips/msp430/timer/Msp430ClockC.nc''</span>
+<span class="pre">is</span> <span class="pre">included</span> <span class="pre">in</span> <span class="pre">the</span> <span class="pre">component</span> <span class="pre">graph,</span> <span class="pre">however,</span> <span class="pre">this</span> <span class="pre">configuration</span> <span class="pre">wires</span>
+<span class="pre">the</span> <span class="pre">McuPowerOverride</span> <span class="pre">of</span> <span class="pre">``tinyos-2.x/tos/chips/msp430/timer/Msp430ClockP.nc</span></tt>
+to McuSleepC. This implemementation of McuPowerOverride raises the lowest
+power state to LPM3, which keeps clocks enabled.</p>
+<p>For msp430 microcontrollers, TOS_SLEEP_NONE is the "active" power state.</p>