-On both the MSP430 and the Atmel, before entering a sleep mode, a
-component checks if any hardware modules require that the MCU core is
-active. Additionally, all services including *HPL* and *HAL*
-components have a start and stop function. When a service is no
-longer using a hardware module, it may call the stop function of the
-*HPL* or *HAL* component. Doing so disables the module for power
-savings, but also removes the MCU's dependence on that hardware module
-to enter sleep mode. For example, the ADC module may be clocked from
-a high speed oscillator. When a sample is not in progress, the ADC
-module may be shut down and it will no longer use the high speed
-oscillator. As a result, when the MCU is idle, it may enter low power
-mode.
-
-This rather efficient way of implementing the power management
-functionality is made possible by the fact that most of the hardware
-modules are on-chip, attached directly to the MCU system bus, and that
-there is no hardware memory protection hindering the access to their
-status registers. As TinyOS platforms add more external devices
-connected via the peripheral buses, this task will get increasingly
-complicated. Ultimately, keeping some state in the form of device
-enumeration or reference counting mechanisms might be needed for
-proper power management.
-
-
-Clocks and timers
------------------
-
-The application of the HAA for abstracting the clock and timer
-modules is documented in [TEP102]_.
-
-
-Analog-to-digital converters
-----------------------------
-
-The application of the HAA for abstracting the analog-to-digital
-converter modules is documented in [TEP101]_.
-
-Data busses
------------
-
-The *HPL* functionality for the data busses includes two paths--one
-for data and a second for control. The control path allows the clock
-source, prescaler, and baud rate to be set. Interrupts may be enabled
-or disabled and various hardware flags may be read, set, or cleared,
-useful for polling or blocking implementations. Through the control
-path, the entire module may be started or stopped for power control.
-The data interface simply consists of sending and receiving a byte
-through the hardware's data registers, as well as interrupt based
-reporting of received data. Here is an example of the interfaces used
-in the MSP430 platform::
-
- interface HPLUSARTControl {
- async command void enableUART();
- async command void disableUART();
- async command void enableUARTTx();
- async command void disableUARTTx();
- async command void enableUARTRx();
- async command void disableUARTRx();
- async command void enableSPI();
- async command void disableSPI();
- async command void setModeSPI();
- async command void setModeUART_TX();
- async command void setModeUART_RX();
- async command void setModeUART();
- async command void setClockSource(
- uint8_t source);
- async command void setClockRate(
- uint16_t baudrate, uint8_t mctl);
- async command result_t disableRxIntr();
- async command result_t disableTxIntr();
- async command result_t enableRxIntr();
- async command result_t enableTxIntr();
- async command result_t isTxIntrPending();
- async command result_t isRxIntrPending();
- async command result_t isTxEmpty();
- async command result_t tx(uint8_t data);
- async command uint8_t rx();
- }
-
- interface HPLUSARTFeedback {
- async event result_t txDone();
- async event result_t rxDone(uint8_t data);
- }
-
-Sometimes functionality for more than one bus protocol are supported
-through a single hardware module. In these cases, wrappers for each
-bus provide standard application interfaces for using the bus.
-Sharing the bus amongst different hardware devices or protocols may be
-done through a bus arbitration component. Bus arbitration allows
-higher level services to attain exclusive use of the bus, complete its
-operations, and then release the bus to the next service::
-
- interface BusArbitration {
- async command result_t getBus();
- async command result_t releaseBus();
- event result_t busFree();
- }
-
-
-External storage
-----------------