tep2.txt

tinyos-2.x.rar

=================================
Hardware Abstraction Architecture
=================================

:TEP: 2
:Group: Core Working Group 
:Type: Best Current Practice
:Status: Final
:TinyOS-Version: 2.x
:Author: Vlado Handziski, Joseph Polastre, Jan-Hinrich Hauer, 
         Cory Sharp, Adam Wolisz, David Culler, David Gay

.. Note::

   This document specifies a Best Current Practices for the TinyOS
   Community, and requests discussion and suggestions for
   improvements.  The distribution of the memo is unlimited, provided
   that the header information and this note are preserved. Parts of
   this document are taken verbatim from the [HAA2005]_ paper that is
   under IEEE copyright and from the [T2_TR]_ technical report.  This
   memo is in full compliance with [TEP1]_.


Abstract
========


This TEP documents a *Hardware Abstraction Architecture (HAA)* for
TinyOS 2.0 that balances the conflicting requirements of code
reusability and portability on the one hand and efficiency and
performance optimization on the other. Its three-layer design
gradually adapts the capabilities of the underlying hardware platforms
to the selected platform-independent hardware interface between the
operating system core and the application code. At the same time, it
allows the applications to utilize a platform's full capabilities --
exported at the second layer, when the performance requirements
outweigh the need for cross-platform compatibility.


1. Introduction
===============

The introduction of hardware abstraction in operating systems has
proved valuable for increasing portability and simplifying application
development by hiding the hardware intricacies from the rest of the
system. However, hardware abstractions come into conflict with the
performance and energy-efficiency requirements of sensor network
applications.

This drives the need for a well-defined architecture of hardware
abstractions that can strike a balance between these conflicting
goals.  The main challenge is to select appropriate levels of
abstraction and to organize them in form of TinyOS components to
support reusability while maintaining energy-efficiency through access
to the full hardware capabilities when it is needed.

This TEP proposes a three-tier *Hardware Abstraction Architecture
(HAA)* for TinyOS 2.0 that combines the strengths of the component
model with an effective organization in form of three different levels
of abstraction. The top level of abstraction fosters portability by
providing a platform-independent hardware interface, the middle layer
promotes efficiency through rich hardware-specific interfaces and the
lowest layer structures access to hardware registers and interrupts.

The rest of this TEP specifies:

* the details of the *HAA* and its three distinct layers  
  (`2. Architecture`_)
* guidelines on selecting the "right" level of abstraction 
  (`3. Combining different levels of abstraction`_)
* how hardware abstractions can be shared among different TinyOS
  platforms (`4. Horizontal decomposition`_)
* the level of hardware abstraction for the processing units 
  (`5. CPU abstraction`_)
* how some hardware abstractions may realize different degrees of
  alignment with the *HAA* top layer 
  (`6. HIL alignment`_)

The *HAA* is the architectural basis for many TinyOS 2.0 documentary
TEPs, e.g. [TEP101]_, [TEP102]_, [TEP103]_ and so forth. Those TEPs
focus on the hardware abstraction for a particular hardware module,
and [TEP112]_ and [TEP115]_ explain how power management is realized.


2. Architecture
===============

In the proposed architecture (Fig.1_), the hardware abstraction
functionality is organized in three distinct layers of components.
Each layer has clearly defined responsibilities and is dependent on
interfaces provided by lower layers.  The capabilities of the
underlying hardware are gradually adapted to the established
platform-independent interface between the operating system and the
applications. As we move from the hardware towards this top interface,
the components become less and less hardware dependent, giving the
developer more freedom in the design and the implementation of
reusable applications.




.. _Fig.1:

::

                           +-----------------------------+
                           |                             |
                           | Cross-platform applications |
                           |                             |
                           +--------------+--------------+
 +-----------------+                      |                  +-----------------+
 |Platform-specific|                      |                  |Platform-specific|
 |  applications   |                      |                  |  applications   |
 +--------+--------+                      |                  +--------+--------+
          |          Platform-independent | hardware interface        |      
          |        +-------------+--------+----+-------------+        |
          |        |             |             |             |        |
          |  +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+  |
          |  |.----+----.| |.----+----.| |.----+----.| |.----+----.|  |
          |  ||         || ||         || ||         || ||  HIL 4  ||  |
          |  ||  HIL 1  || ||  HIL 2  || ||  HIL 3  || |`----+----'|  |
          |  ||         || |`----+----'| |`----+----'| |     |     |  |
          |  |`----+----'| |     |     | |     |     | |     |  +--+--+
          +--+--+  |     | |.----+----.| |     |     | |     |  |  |
             |  |  |     | ||         || |.----+----.| |.----+--+-.|
             |.-+--+----.| ||         || ||         || ||         ||
             ||         || ||  HAL 2  || ||         || ||         ||
             ||         || ||         || ||  HAL 3  || ||  HAL 4  ||
             ||  HAL 1  || |`----+----'| ||         || ||         ||
             ||         || |     |     | ||         || ||         ||
             ||         || |     |     | |`----+----'| |`----+----'|
             |`----+----'| |.----+----.| |     |     | |     |     |
             |     |     | ||         || |.----+----.| |     |     |
             |.----+----.| ||  HPL 2  || ||         || |.----+----.|
             ||  HPL 1  || ||         || ||  HPL 3  || ||  HPL 4  ||
             |`----+----'| |`----+----'| |`----+----'| |`----+----'|
             +-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+  HW/SW
                   |             |             |             |          boundary
        ************************************************************************
            +------+-----+ +-----+-----+ +-----+-----+ +-----+-----+
            |HW Plat 1   | |HW Plat 2  | |HW Plat 3  | |HW Plat 4  |
            +------------+ +-----------+ +-----------+ +-----------+

                    
              Fig.1: The proposed Hardware Abstraction Architecture



In contrast to the more traditional two step approach used in other
embedded operating systems like [WindowsCE]_, the three-level design
results in increased *flexibility* that arises from separating the
platform-specific abstractions and the adaptation wrappers that
upgrade or downgrade them to the current platform-independent
interface.  In this way, for maximum performance, the platform
specific applications can circumvent the *HIL* components and directly
tap to the *HAL* interfaces that provide access to the full
capabilities of the hardware module.

The rest of the section discusses the specific roles of each component
layer in more detail.


Hardware Presentation Layer (HPL)
---------------------------------

The components belonging to the *HPL* are positioned directly over the
HW/SW interface. As the name suggests, their major task is to
"present" the capabilities of the hardware using the native concepts
of the operating system.  They access the hardware in the usual way,
either by memory or by port mapped I/O. In the reverse direction, the
hardware can request servicing by signaling an interrupt. Using these
communication channels internally, the *HPL* hides the hardware
intricacies and exports a more readable interface (simple function
calls) for the rest of the system.

The *HPL* components SHOULD be stateless and expose an interface that
is fully determined by the capabilities of the hardware module that is
abstracted. This tight coupling with the hardware leaves little
freedom in the design and the implementation of the components.  Even
though each *HPL* component will be as unique as the underlying
hardware, all of them will have a similar general structure. For
optimal integration with the rest of the architecture, each *HPL*
component SHOULD have:

- commands for initialization, starting, and stopping of the
  hardware module that are necessary for effective power management
  policy
- "get" and "set" commands for the register(s) that control
  the operation of the hardware
- separate commands with descriptive names for the most
  frequently used flag-setting/testing operations
- commands for enabling and disabling of the interrupts generated by
  the hardware module
- service routines for the interrupts that are generated by the
  hardware module

The interrupt service routines in the *HPL* components perform only
the most time critical operations (like copying a single value,
clearing some flags, etc.), and delegate the rest of the processing to
the higher level components that possess extended knowledge about the
state of the system.

The above *HPL* structure eases manipulation of the hardware.  Instead
of using cryptic macros and register names whose definitions are
hidden deep in the header files of compiler libraries, the programmer
can now access hardware through a familiar interface.

This *HPL* does not provide any substantial abstraction over the
hardware beyond automating frequently used command
sequences. Nonetheless, it hides the most hardware-dependent code and
opens the way for developing higher-level abstraction components.
These higher abstractions can be used with different *HPL*
hardware-modules of the same class.  For example, many of the
microcontrollers used on the existing sensornet platforms have two
USART modules for serial communication.  They have the same
functionality but are accessed using slightly different register names
and generate different interrupt vectors. The *HPL* components can
hide these small differences behind a consistent interface, making the
higher-level abstractions resource independent.  The programmer can
then switch between the different USART modules by simple rewiring
(*not* rewriting) the *HPL* components, without any changes to the
implementation code.

  
Hardware Adaptation Layer (HAL)
-------------------------------

The adaptation layer components represent the core of the
architecture. They use the raw interfaces provided by the *HPL*
components to build useful abstractions hiding the complexity
naturally associated with the use of hardware resources. In contrast
to the *HPL* components, they are allowed to maintain state that can
be used for performing arbitration and resource control.

Due to the efficiency requirements of sensor networks, abstractions at
the *HAL* level are tailored to the concrete device class and
platform. Instead of hiding the individual features of the hardware
class behind generic models, *HAL* interfaces expose specific features
and provide the "best" possible abstraction that streamlines
application development while maintaining effective use of resources.

For example, rather than using a single "file-like" abstraction for
all devices, we propose domain specific models like *Alarm*, *ADC
channel*, *EEPROM*. According to the model, *HAL* components SHOULD
provide access to these abstractions via rich, customized interfaces,
and not via standard narrow ones that hide all the functionality
behind few overloaded commands. This also enables more efficient
compile-time detection of abstraction interface usage errors.



Hardware Interface Layer (HIL)
------------------------------

The final tier in the architecture is formed by the *HIL* components
that take the platform-specific abstractions provided by the *HAL* and
convert them to hardware-independent interfaces used by cross-platform
applications.  These interfaces provide a platform independent
abstraction over the hardware that simplifies the development of the
application software by hiding the hardware differences.  To be
successful, this API "contract" SHOULD reflect the *typical* hardware
services that are required in a sensornet application.

The complexity of the *HIL* components mainly depends on how advanced
the capabilities of the abstracted hardware are with respect to the
platform-independent interface. When the capabilities of the hardware
exceed the current API contract, the *HIL* "downgrades" the
platform-specific abstractions provided by the *HAL* until they are
leveled-off with the chosen standard interface. Consequently, when the
underlying hardware is inferior, the *HIL* might have to resort to
software simulation of the missing hardware capabilities.  As newer
and more capable platforms are introduced in the system, the pressure
to break the current API contract will increase. When the performance
requirements outweigh the benefits of the stable interface, a discrete
jump will be made that realigns the API with the abstractions provided
in the newer *HAL*.  The evolution of the platform-independent
interface will force a reimplementation of the affected *HIL*
components. For newer platforms, the *HIL* will be much simpler
because the API contract and their *HAL* abstractions are tightly
related. On the other extreme, the cost of boosting up (in software)
the capabilities of the old platforms will rise.

Since we expect *HIL* interfaces to evolve as new platforms are
designed, we must determine when the overhead of software emulation of
hardware features can no longer be sustained.  At this point, we
introduce *versioning* of *HIL* interfaces.  By assigning a version
number to each iteration of an *HIL* interface, we can design
applications using a legacy interface to be compatible with previously
deployed devices.  This is important for sensor networks since they execute
long-running applications and may be deployed for years.  An *HIL* MAY
also branch, providing multiple different *HIL* interfaces with
increasing levels of functionality.


3. Combining different levels of abstraction
============================================

Providing two levels of abstraction to the application --the *HIL* and
*HAL*-- means that a hardware asset may be accessed at two levels in
parallel, e.g. from different parts of the application and the OS
libraries. 

The standard Oscilloscope application in TinyOS 2.0, for example, may
use the ADC to sample several values from a sensor, construct a
message out of them and send it over the radio. For the sake of
cross-platform compatibility, the application uses the standard
``Read`` interface provided by the ADC *HIL* and forwarded by the
``DemoSensorC`` component wired to, for example, the temperature
sensor wrapper.  When enough samples are collected in the message
buffer, the application passes the message to the networking stack.
The MAC protocol might use clear channel assessment to determine when
it is safe to send the message, which could involve taking several ADC
samples of an analog RSSI signal provided by the radio hardware. Since
this is a very time critical operation in which the correlation
between the consecutive samples has a significant influence, the
programmer of the MAC might directly use the hardware specific
interface of the *HAL* component as it provides much finer control
over the conversion process. (Fig.2_) depicts how the ADC hardware
stack on the MSP430 MCU on the level of *HIL* and *HAL* in parallel.

.. _Fig.2:

::