-
-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.
-
-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. [TEP112]_,
-for example, details how TinyOS 2.x manages the multiple power-
-consumption states for *microcontrollers.* This document, in turn,
-details the support for managing the *physical and dedicated* and
-*physical and shared* device classes as defined in [TEP108]_. Devices
-belonging to these classes often have only two power consumption
-states (*on* and *off*), 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.
-
-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 *physical and shared* 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 *physical and shared* devices, except that an attempt to power
-down such a device would not occur until *all* 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
-*virtual* 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.
-
-In order to provide the building blocks for implementing such power
-managment policies on top of *physical and dedicated* and *physical
-and shared* devices, TinyOS 2.x defines two different power management
-models that devices belonging to one of these two classes must adhere
-to: the *explicit power management* model and the *implicit power
-management* model.
+\rThe energy resources on a typical TinyOS platform are limited, so\revery effort should be made to put all devices on a given platform\rinto their lowest possible power state as often as\rpossible. Depending on the device type, selecting the correct\rpower state could be as simple as switching between on and\roff states, or involve selecting the optimum state from among\rseveral. Choosing the best possible power state requires making\rtradeoffs between various factors such as power consumption, fidelity,\rperformance, and wake-up latency.\r\rUnfortunately, it is not feasible do design a unified one size-fits-all power\rmanagement 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 (*on* and *off*). 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 *on* or *off*. 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 [TEP112]_.
+
+The term "peripheral device" specifically refers to any hardware device for which
+the mechanisms described in [TEP108]_ can be used to provide resource arbitration
+for them. These devices are considered *non-virtualised* 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.