[Tinyos-2-commits] CVS: tinyos-2.x/doc/txt tep2.txt,1.4,1.5
Vlado Handziski
vlahan at users.sourceforge.net
Wed Feb 28 10:06:51 PST 2007
Update of /cvsroot/tinyos/tinyos-2.x/doc/txt
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv30335
Modified Files:
tep2.txt
Log Message:
Update of Fig.3, small markup changes.
Index: tep2.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-2.x/doc/txt/tep2.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** tep2.txt 21 Feb 2007 17:09:46 -0000 1.4
--- tep2.txt 28 Feb 2007 18:06:49 -0000 1.5
***************
*** 8,12 ****
:Status: Draft
:TinyOS-Version: 2.0
! :Author: Vlado Handziski, Joseph Polastre, Jan-Hinrich Hauer, Cory Sharp, Adam Wolisz and David Culler
:Draft-Created: 14-Sep-2004
--- 8,13 ----
:Status: Draft
:TinyOS-Version: 2.0
! :Author: Vlado Handziski, Joseph Polastre, Jan-Hinrich Hauer,
! Cory Sharp, Adam Wolisz, David Culler, David Gay
:Draft-Created: 14-Sep-2004
***************
*** 45,61 ****
===============
! The introduction of hardware abstraction in modern 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 the 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
--- 46,62 ----
===============
! 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
***************
*** 69,73 ****
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
--- 70,74 ----
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
***************
*** 78,89 ****
(`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.
--- 79,89 ----
(`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.
***************
*** 168,173 ****
---------------------------------
! 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,
--- 168,173 ----
---------------------------------
! 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,
***************
*** 175,186 ****
hardware can request servicing by signaling an interrupt. Using these
communication channels internally, the *HPL* hides the hardware
! intricacies and exports a more usable 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*
--- 175,186 ----
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*
***************
*** 205,212 ****
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
--- 205,212 ----
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
***************
*** 216,224 ****
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
--- 216,224 ----
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
***************
*** 237,246 ****
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
--- 237,246 ----
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
***************
*** 263,268 ****
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
--- 263,268 ----
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
***************
*** 278,287 ****
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
--- 278,287 ----
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
***************
*** 321,326 ****
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:
--- 321,325 ----
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:
***************
*** 328,369 ****
::
- +--------------------------------+
- | APP |
+--------------------------------+
| |
Read Send
- | |
- v |
- +--------------------+ |
- | DemoSensorC / | |
- | TemperatureC | |
- +--------------------+ |
| |
Read |
! | |
! v v
! +--------------------+ +--------------------+
! | HIL: AdcC | | Radio Stack |
! +--------------------+ +--------------------+
! | | MAC Protocol |
! | +--------------------+
! | |
! | |
! | -----------------------
! | |
Msp430Adc12SingleChannel
! | |
! v v
! +--------------------+
| 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 so that a
! safe shared access to the *HPL* exported resources can be guaranteed.
--- 327,371 ----
::
+--------------------------------+
+ | 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.
***************
*** 371,383 ****
===========================
! 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_)
--- 373,385 ----
===========================
! 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_)
***************
*** 389,393 ****
+----------------------------------------------------+
! | AppM |
| /Application Component/ |
+------+--------------------------------------+------+
--- 391,395 ----
+----------------------------------------------------+
! | AppC |
| /Application Component/ |
+------+--------------------------------------+------+
***************
*** 433,437 ****
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
--- 435,439 ----
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
***************
*** 439,443 ****
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.
--- 441,445 ----
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.
***************
*** 488,496 ****
================
! 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
--- 490,498 ----
================
! 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
***************
*** 503,516 ****
----------------
! *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, 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
--- 505,519 ----
----------------
! *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, if not
! using any radio metadata at least), sensor wrappers (DemoSensorC,
! [TEP109]_) or storage ([TEP103]_). Strong *HIL*s 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
***************
*** 531,539 ****
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.
--- 534,542 ----
readings.
! The benefit from weak *HIL* 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 *HAL*s, because weak
! *HIL*s involve some guidelines on how to expose some functionality,
which should help programmers and provide guidance to platform
developers.
***************
*** 543,548 ****
--------------------------------------
! - *Hardware Independent Interfaces (HII)*, which is just an interface
! definition intended for use across multiple platforms.
Examples include the SID interfaces, the pin interfaces from [TEP117]_,
--- 546,551 ----
--------------------------------------
! *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]_,
More information about the Tinyos-2-commits
mailing list