-<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 state as often as
-possible. Depending on the device type, selecting the correct
-power state could be as simple as switching between on and
-off states, or involve selecting the optimum state from among
-several. Choosing the best possible power state requires making
-tradeoffs between various factors such as power consumption, fidelity,
-performance, and wake-up latency.</p>
-<p>Unfortunately, it is not feasible do design a unified one size-fits-all power
-management strategy for use by all types of devices. Some devices
-(particularly microcontollers) have direct access to internal registers that
-allow them to efficiently calculate their lowest possible power state
-very quickly. Other devices do not have this information readily available and
-would have to calculate it on the fly if other mechanisms were not in place to
-prevent this. Designing a general system wide power control algorithm to handle
-all such devices would most likely be overly complex and in some cases even
-suboptimal. TinyOS 2.x, therefore, takes the approach of defining two different
-classes of devices for which different power-management strategies have been
-optimized: microcontrollers and peripheral devices. As opposed to microcontrollers,
-which normally contain a number of different valid power states, peripheral devices
-tend to have only two distinct states they can be switched to (<em>on</em> and <em>off</em>). Even
-in the rare case where a device of this type happens to contain multiple power
-states, TinyOS has traditionally used just the two most useful power states and
-designated them to mean either <em>on</em> or <em>off</em>. This TEP is dedicated to
-describing power management for peripheral devices of this type. Details on the
-mechanisms used to perform microcontroller power management can be found in <a class="citation-reference" href="#tep112" id="id1" name="id1">[TEP112]</a>.</p>
-<p>The term "peripheral device" specifically refers to any hardware device for which
-the mechanisms described in <a class="citation-reference" href="#tep108" id="id2" name="id2">[TEP108]</a> can be used to provide resource arbitration
-for them. These devices are considered <em>non-virtualised</em> in the sense that
-access to them must be explicitly requested and released by higher level
-components wishing to use them. Various policies can be implemented on top of
-this class of devices to decide exactly when they should be powered on or off.
-The simplest policy involves leaving it up to the programmer
-to ensure that a device is switched on or off whenever it should be.
-Other policies involve automatically powering a device up or down
-by monitoring whether any clients are currently connected to it
-or not. Depending on the type of power management policy desired,
-different models should be followed when designing drivers for devices
-of this class.</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>