| Type: | Best Current Practice | |
|---|---|---|
| Status: | -Draft | |
| TinyOS-Version: | 2.0 | +Final |
| TinyOS-Version: | 2.x | |
| Author: | -Vlado Handziski, Joseph Polastre, Jan-Hinrich Hauer, + | Vlado Handziski, Joseph Polastre, Jan-Hinrich Hauer, Cory Sharp, Adam Wolisz, David Culler, David Gay |
| Draft-Created: | 14-Sep-2004 | -|
| Draft-Version: | 1.6 | -|
| Draft-Modified: | 2007-02-28 | -|
| Draft-Discuss: | TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu> | -
Note
This document specifies a Best Current Practices for the TinyOS @@ -322,8 +309,8 @@ this document are taken verbatim from the [T2_TR] technical report. This memo is in full compliance with [TEP1].
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 @@ -335,8 +322,8 @@ 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.
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 @@ -358,16 +345,16 @@ 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 HAA is the architectural basis for many TinyOS 2.0 documentary @@ -375,8 +362,8 @@ TEPs, e.g. [TEP focus on the hardware abstraction for a particular hardware module, and [TEP112] and [TEP115] explain how power management is realized.
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 @@ -387,46 +374,47 @@ 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.
-- +-----------------------------+ - | | - | 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 Platform 1| |HW Platform 2| |HW Platform 3| |HW Platform 4| - +-------------+ +-------------+ +-------------+ +-------------+ - - - Fig.1: The proposed Hardware Abstraction Architecture ++ +-----------------------------+ + | | + | 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 ArchitectureIn contrast to the more traditional two step approach used in other embedded operating systems like [WindowsCE], the three-level design @@ -439,8 +427,8 @@ 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)
++-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 @@ -496,8 +484,8 @@ 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)
++-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 @@ -518,8 +506,8 @@ 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)
++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 @@ -558,8 +546,8 @@ also branch, providing multiple different HIL interfaces with increasing levels of functionality.
-3. Combining different levels of abstraction
++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 @@ -581,7 +569,7 @@ 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.
-++--------------------------------+ | APP | +-+----------------------------+-+ @@ -623,8 +611,8 @@ more complex arbitration and resource control functionality -4. Horizontal decomposition
++-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, @@ -634,7 +622,7 @@ 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)
-++----------------------------------------------------+ | AppC | | /Application Component/ | @@ -706,8 +694,8 @@ 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
++-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 @@ -724,8 +712,8 @@ 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
++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 @@ -736,8 +724,8 @@ concept of a HIL. It also uses the following differentiation:
definition may be differentplatform-specific X: X is defined on just one platform --Strong/Real HILs
++-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 @@ -750,8 +738,8 @@ 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
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 @@ -773,23 +761,23 @@ still be easier to port than code built on top of HALs, because weak which should help programmers and provide guidance to platform developers.
-Hardware Independent Interfaces (HII)
++-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
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
++-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 @@ -799,11 +787,11 @@ 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
++Author's Address
--Vlado Handziski (handzisk at tkn.tu-berlin.de) [1]-Joseph Polastre (polastre at cs.berkeley.edu) [2]+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]@@ -813,9 +801,9 @@ remainder of the application.@@ -823,7 +811,7 @@ Sekr. FT 5, Einsteinufer 25
- [1] (1, 2, 3) Technische Universitaet Berlin -Telecommunication Networks Group -Sekr. FT 5, Einsteinufer 25 + [1] (1, 2, 3) Technische Universitaet Berlin +Telecommunication Networks Group +Sekr. FT 5, Einsteinufer 25 10587 Berlin, Germany @@ -836,8 +824,8 @@ CA 94704 [2] (1, 2, 3) University of California, Berkeley -Computer Science Department +Computer Science Department Berkeley, CA 94720 USA -Citations
++Citations
@@ -850,12 +838,12 @@ 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 Universität Berlin, November 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. @@ -868,7 +856,7 @@ Technische Universität Berlin, November 2005.
-@@ -944,12 +932,6 @@ Levis, "Power Management of Non-Virtualised Devices"
- [NetBSD] "The NetBSD project home page", Online, + [NetBSD] "The NetBSD project home page", Online, http://www.netbsd.org [TEP117] (1, 2) Phil Buonadonna, Jonathan Hui, "Low-Level I/O"