tep2.txt

tinyos-2.x.rar

               +--------------------------------+
               |               APP              |
               +-+----------------------------+-+
                 |                            |
                Read                         Send
                 |                            |
                 |                            |
       +---------+----------+         +-------+--------+
       |   DemoSensorC /    |         |                |
       |   TemperatureC     |         | ActiveMessageC |
       +---------+----------+         |                |
                 |                    +-------+--------+
                Read                          |
                 |                            |
                 |                    +-------+--------+
       +---------+----------+         |                |
       | HIL:   AdcC        |         |                |
       +---------+----------+         |  TDA5250       |
                 |                    |                |
                 |                    |  Radio Stack   |
                 |                    |                |
                 |                    +-------+--------+
                 |                            |
                 |     +----------------------+
                 |     |
         Msp430Adc12SingleChannel
                 |     |
                 |     |
       +---------+-----+----+
       | HAL: Msp430Adc12C  |
       +--------------------+
 
 
                Fig.2: Accessing the MSP430 ADC hardware abstraction
                       via *HIL* and *HAL* in parallel


To support this type of "vertical" flexibility the ADC *HAL* includes
more complex arbitration and resource control functionality [TEP108]_
so that a safe shared access to the *HPL* exported resources can be
guaranteed.


4. Horizontal decomposition
===========================

In addition to the *vertical* decomposition of the *HAA*, a
*horizontal* decomposition can promote reuse of the hardware resource
abstractions that are common on different platforms.  To this aim,
TinyOS 2.0 introduces the concept of *chips*, the self-contained
abstraction of a given hardware chip: microcontroller, radio-chip,
flash-chip, etc.  Each chip decomposition follows the *HAA* model,
providing *HIL* implementation(s) as the topmost component(s).
Platforms are then built as compositions of different chip components
with the help of "glue" components that perform the mapping (Fig.3_)


.. _Fig.3:

::



          +----------------------------------------------------+
          | AppC                                               |
          | /Application Component/                            |
          +------+--------------------------------------+------+
                 |                                      |
                 |Millisecond Timer                     | Communication
          +------+------+                     +---------+------+
          | TimerMilliC |                     | ActiveMessageC |
          |             |                     |                |
          | /Platform   |                     | /Platform      |
          |  Component/ |                     | Component/     |
          +------+------+                     +---------+------+
                 |                                      |
          +------+------+                        +------+------+
          |             | 32kHz Timer            |             |
          |             |    +--------------+    |             |
          | Atmega128   |    | CC2420AlarmC |    | CC2420      |
          |             +----+              +----+             |
          | Timer Stack |    | /Platform    |    | Radio Stack |
          |             |    |  Component/  |    |             |
          | /Chip       |    +--------------+    | /Chip       |
          |  Component/ |                        |  Component/ |
          +-------------+                        +-------------+



      Fig.3: The CC2420 software depends on a physical and dedicated
      timer. The micaZ platform code maps this to a specific Atmega128
      timer.


Some of the shared hardware modules are connected to the
microcontroller using one of the standard bus interfaces: SPI, I2C,
UART. To share hardware drivers across different platforms the issue
of the abstraction of the interconnect has to be solved. Clearly,
greatest portability and reuse would be achieved using a generic bus
abstraction like in NetBSD [netBSD]_. This model abstracts the
different bus protocols under one generic bus access scheme.  In this
way, it separates the abstraction of the chip from the abstraction of
the interconnect, potentially allowing the same chip abstraction to be
used with different connection protocols on different platforms.
However, this generalization comes at high costs in performance. This
may be affordable for desktop operating systems, but is highly
sub-optimal for the application specific sensor network platforms.

TinyOS 2.0 takes a less generic approach, providing *HIL*-level,
microcontroller-independent abstractions of the main bus protocols
like I2C, SPI, UART and pin-I/O. This distinction enables
protocol-specific optimizations, for example, the SPI abstraction does
not have to deal with client addresses, where the I2C abstraction
does. Furthermore, the programmer can choose to tap directly into the
chip-specific *HAL*-level component, which could further improve the
performance by allowing fine tuning using chip-specific configuration
options.

The TinyOS 2.0 bus abstractions, combined with the ones for low-level
pin-I/O and pin-interrupts (see [TEP117]_), enable a given chip
abstraction to be reused on any platform that supports the required
bus protocol.  The CC2420 radio, for example, can be used both on the
Telos and on micaZ platforms, because the abstractions of the serial
modules on the MSP430 and Atmega128 microcontrollers support the
unified SPI bus abstraction, which is used by the same CC2420 radio
stack implementation.

Sharing chips across platforms raises the issue of resource contention
on the bus when multiple chips are connected to it. For example, on
the micaZ the CC2420 is connected to a dedicated SPI bus, while on the
Telos platform one SPI bus is shared between the CC2420 radio and the
flash chip. To dissolve conflicts the resource reservation mechanism
proposed in [TEP108_] is applied: every chip abstraction that uses a
bus protocol MUST use the ``Resource`` interface in order to gain
access to the bus resource. In this way, the chip can be safely used
both in dedicated scenarios, as well as in situations where multiple
chips are connected to the same physical bus interconnect.


5. CPU abstraction
==================

In TinyOS most of the variability between the processing units is
hidden from the OS simply by using a nesC/C based programming language
with a common compiler suite (GCC). For example, the standard library
distributed with the compiler creates the necessary start-up code for
initializing the global variables, the stack pointer and the interrupt
vector table, shielding the OS from these tasks. To unify things
further, TinyOS provides common constructs for declaring reentrant and
non-reentrant interrupt service routines and critical code-sections.

The *HAA* is not currently used to abstract the features of the
different CPUs. For the currently supported MCUs, the combination of
the compiler suite support and the low-level I/O is
sufficient. Nevertheless, if new cores with radically different
architectures need to be supported by TinyOS in the future, this part
of the hardware abstraction functionality will have to be explicitly
addressed.


6. HIL alignment
================

While the *HAA* requires that the *HIL* provides full hardware
independence (`Strong/Real HILs`_), some abstractions might only
partially meet this goal (`Weak HILs`_). This section introduces
several terms describing different degrees of alignment with the
concept of a *HIL*. It also uses the following differentiation:

- *platform-defined X:* X is defined on all platforms, but the
  definition may be different

- *platform-specific X:* X is defined on just one platform


Strong/Real HILs 
----------------

*Strong/Real HILs* mean that "code using these abstractions can
reasonably be expected to behave the same on all implementations".
This matches the original definition of the *HIL* level according to
the *HAA*.  Examples include the *HIL* for the Timer (TimerMilliC,
[TEP102]_), for LEDs (LedsC), active messages (ActiveMessageC,
[TEP116]_, if not using any radio metadata at least), sensor wrappers
(DemoSensorC, [TEP109]_) or storage ([TEP103]_). Strong *HILs* may use
platform-defined types if they also provide operations to manipulate
them (i.e., they are platform-defined abstract data types), for
example, the TinyOS 2.x message buffer abstraction, ``message_t``
([TEP111]_).

Weak HILs
---------

*Weak HILs* mean that one "can write portable code over these
abstractions, but any use of them involves platform-specific
behavior". Although such platform-specific behavior can --at least at
a rudimentary syntactical level-- be performed by a
platform-independent application, the semantics require knowledge of
the particular platform.  For example, the ADC abstraction requires
platform-specific configuration and the returned data must be
interpreted in light of this configuration. The ADC configuration is
exposed on all platforms through the "AdcConfigure" interface that
takes a platform-defined type (adc_config_t) as a parameter. However,
the returned ADC data may be processed in a platform-independent way,
for example, by calculating the max/min or mean of multiple ADC
readings.

The benefit from weak *HILs* are that one can write portable utility
code, e.g., a repeated sampling for an ADC on top of the data path.
While code using these abstractions may not be fully portable, it will
still be easier to port than code built on top of *HALs*, because weak
*HILs* involve some guidelines on how to expose some functionality,
which should help programmers and provide guidance to platform
developers.


Hardware Independent Interfaces (HII)
--------------------------------------

*Hardware Independent Interfaces (HII)*, is just an interface
definition intended for use across multiple platforms.

Examples include the SID interfaces, the pin interfaces from [TEP117]_,
the Alarm/Counter/etc interfaces from [TEP102]_.


Utility components
------------------

*Utility components* are pieces of clearly portable code (typically
generic components), which aren't exposing a self-contained service.
Examples include the components in tos/lib/timer and the
ArbitratedRead* components. These provide and use HIIs.



6. Conclusion
====================================================================

The proposed hardware abstraction architecture provides a set of core
services that eliminate duplicated code and provide a coherent view of
the system across different platforms. It supports the concurrent use
of platform-independent and the platform-dependent interfaces in the
same application. In this way, applications can localize their
platform dependence to only the places where performance matters,
while using standard cross-platform hardware interfaces for the
remainder of the application.


Author's Address
================

| Vlado Handziski (handzisk at tkn.tu-berlin.de) [1]_ 
| Joseph Polastre (polastre at cs.berkeley.edu) [2]_ 
| Jan-Hinrich Hauer (hauer at tkn.tu-berlin.de) [1]_
| Cory Sharp (cssharp at eecs.berkeley.edu) [2]_
| Adam Wolisz (awo at ieee.org) [1]_
| David Culler (culler at eecs.berkeley.edu) [2]_
| David Gay (david.e.gay at intel.com) [3]_


.. [1] Technische Universitaet Berlin   
       Telecommunication Networks Group                    
       Sekr. FT 5, Einsteinufer 25                        
       10587 Berlin, Germany           

.. [2] University of California, Berkeley
       Computer Science Department                
       Berkeley, CA 94720 USA

.. [3] Intel Research Berkeley
       2150 Shattuck Ave, Suite 1300
       CA 94704

Citations
=========

.. [HAA2005] V. Handziski, J.Polastre, J.H.Hauer, C.Sharp,
   A.Wolisz and D.Culler, "Flexible Hardware Abstraction for Wireless
   Sensor Networks", in *Proceedings of the 2nd European Workshop on
   Wireless Sensor Networks (EWSN 2005)*, Istanbul, Turkey, 2005.

.. [T2_TR] P. Levis, D. Gay, V. Handziski, J.-H.Hauer, B.Greenstein, 
   M.Turon, J.Hui, K.Klues, C.Sharp, R.Szewczyk, J.Polastre, 
   P.Buonadonna, L.Nachman, G.Tolle, D.Culler, and A.Wolisz, 
   "T2: A Second Generation OS For Embedded Sensor Networks", 
   *Technical Report TKN-05-007*, Telecommunication Networks Group, 
   Technische Universitaet Berlin, November 2005.

.. [WindowsCE] "The WindowsCE operating system home page", *Online*,
   http://msdn.microsoft.com/embedded/windowsce

.. [NetBSD] "The NetBSD project home page", *Online*, 
   http://www.netbsd.org

.. [TEP1] Philip Levis, "TEP structure and key words" 
   
.. [TEP101] Jan-Hinrich Hauer, Philip Levis, Vlado Handziski, David Gay
            "Analog-to-Digital Converters (ADCs)"

.. [TEP102] Cory Sharp, Martin Turon, David Gay, "Timers"

.. [TEP103] David Gay, Jonathan Hui, "Permanent Data Storage (Flash)"

.. [TEP108] Kevin Klues, Philip Levis, David Gay, David Culler, Vlado
            Handziski, "Resource Arbitration"

.. [TEP109] David Gay, Philip Levis, Wei Hong, Joe Polastre, and Gilman
            Tolle "Sensors and Sensor Boards"

.. [TEP111] Philip Levis, "message_t"

.. [TEP112] Robert Szewczyk, Philip Levis, Martin Turon, Lama Nachman,
            Philip Buonadonna, Vlado Handziski, "Microcontroller Power
            Management"

.. [TEP115] Kevin Klues, Vlado Handziski, Jan-Hinrich Hauer, Philip
            Levis, "Power Management of Non-Virtualised Devices"

.. [TEP116] Philip Levis, "Packet Protocols"

.. [TEP117] Phil Buonadonna, Jonathan Hui, "Low-Level I/O"