-<p>The energy resources on a typical TinyOS platform are limited, so
-every effort should be made to put all devices on a given platform
-into their lowest possible power-consumption states as often as
-possible. Depending on the device type, selecting the correct
-power-consumption state could be as simple as switching between on and
-off states, or could involve selecting the optimum state from among
-several. Choosing the best power-consumption state requires making
-tradeoffs between various factors such as power consumption, fidelity,
-performance, and wake-up latency.</p>
-<p>Because of the large difference in the number of supported power-
-consumption states that could potentially be present on any given
-device, as well as the complexity in keeping track of the state
-information needed for safe execution of any sort of system wide
-power-control algorithm, a unified power management strategy for all
-devices on all possible platforms is simply infeasible. Developing
-such a solution would most likely be overly complex and in some cases
-even suboptimal. TinyOS 2.x, therefore, takes the approach of
-defining several different classes of devices for which several
-different power-management strategies have been optimized. <a class="citation-reference" href="#tep112" id="id1" name="id1">[TEP112]</a>,
-for example, details how TinyOS 2.x manages the multiple power-
-consumption states for <em>microcontrollers.</em> This document, in turn,
-details the support for managing the <em>physical and dedicated</em> and
-<em>physical and shared</em> device classes as defined in <a class="citation-reference" href="#tep108" id="id2" name="id2">[TEP108]</a>. Devices
-belonging to these classes often have only two power consumption
-states (<em>on</em> and <em>off</em>), and can therefore be treated differently than
-devices that have multiple power consumption states. Additionally, it
-turns out that, in practice, TinyOS software often just uses the two
-most useful of the many power states in these cases.</p>
-<p>Various policies can be implemented on top of these two classes of
-devices that decide exactly when a device should be powered on or off.
-For <em>physical and shared</em> devices, for example, a power management
-policy could be written that explicitly powers a device on and off
-whenever the higher level component that uses it no longer requires
-it. Another policy, however, might decide to defer the power down of
-the device for a a few milliseconds if its wake-up time is large
-enough and it is likely that the device will be needed again sometime
-in the near future. A similar set of policies could be implemented
-for <em>physical and shared</em> devices, except that an attempt to power
-down such a device would not occur until <em>all</em> components using it had
-signalled that they no longer needed it. Providing these sorts of
-policies cause devices belonging to one of these two classes to become
-virtualized in the sense that their power states are automatically
-handled. Any higher level components connecting to one of these
-<em>virtual</em> devices need only signify when they require the use of the
-device and when they don't. The time at which the device actually
-becomes powered on or off, is left up to the power managment policy
-being used.</p>
-<p>In order to provide the building blocks for implementing such power
-managment policies on top of <em>physical and dedicated</em> and <em>physical
-and shared</em> devices, TinyOS 2.x defines two different power management
-models that devices belonging to one of these two classes must adhere
-to: the <em>explicit power management</em> model and the <em>implicit power
-management</em> model.</p>
+<p>TinyOS platforms have limited energy. A unified power management
+strategy for all devices and peripherals is not feasible, as
+they vary significantly in warm-up times, power profiles, and
+operation latencies. While some devices, such as
+microcontrollers, can efficiently calculate their lowest possible
+power state very quickly, others, such as sensors with warm-up
+times, require external knowledge to do so.</p>
+<p>In TinyOS 1.x, applications are responsible for all power management.
+Low-level subsystems, such as an SPI bus, are explicitly powered on
+and off by higher level abstractions. This approach of deep calls
+to <tt class="docutils literal"><span class="pre">StdControl.start()</span></tt> and <tt class="docutils literal"><span class="pre">StdControl.stop()</span></tt> introduces strange behaviors
+and can get in the way of power conservation. Turning off the radio
+on the Telos platform, for example, turns off the SPI bus and therefore
+prevents the flash driver from working. Additionally, the microcontroller
+stays in a higher power state for the SPI bus even when it is
+inactive.</p>
+<p>TinyOS 2.x defines two classes of devices for power-management:
+microcontrollers and peripherals. TEP 112 documents how TinyOS 2.x
+manages the power state of a microcontroller <a class="citation-reference" href="#tep112" id="id1" name="id1">[TEP112]</a>.
+Unlike microcontrollers, which typically have several power states,
+peripheral devices typically have two distinct states, <em>on</em> and <em>off</em>.
+This TEP is dedicated to documenting how TinyOS 2.x controls the power
+state of peripheral devices.</p>
+<p>The term "peripheral device" refers to any hardware device which
+arbitrates access with the mechanisms described in <a class="citation-reference" href="#tep108" id="id2" name="id2">[TEP108]</a> . These
+devices are not virtualised in the sense that access to
+them must be explicitly requested and released by their users.</p>