The hardware abstraction architecture of tinyos 2 x l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 17

The Hardware Abstraction Architecture of TinyOS 2.x PowerPoint PPT Presentation


  • 286 Views
  • Uploaded on
  • Presentation posted in: Internet / Web

The Hardware Abstraction Architecture of TinyOS 2.x Vlado Handziski * , Joseph Polastre † , Jan Hauer * , Cory Sharp † , Adam Wolisz * and David Culler † * Telecommunication Networks Group Technische Universität Berlin † Computer Science Department University of California, Berkeley

Download Presentation

The Hardware Abstraction Architecture of TinyOS 2.x

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


The hardware abstraction architecture of tinyos 2 x l.jpg

The Hardware Abstraction Architecture of TinyOS 2.x

Vlado Handziski*, Joseph Polastre†, Jan Hauer*,

Cory Sharp†, Adam Wolisz* and David Culler†

*Telecommunication Networks Group

Technische Universität Berlin

†Computer Science Department

University of California, Berkeley


Hardware abstraction in wsn operating systems l.jpg

Two seemingly conflicting requirements

Energy-efficient implementation

Low level of abstraction

Rapid application development

 High level of abstraction

How to effectively reconcile this gap?

Reconfigurable operating system architecture

TinyOS

 Let the application programmer choose the appropriate level of abstraction

How to organize the hardware abstraction into components?

Hardware Abstraction in WSN Operating Systems

  • What is the most appropriate level of hardware abstraction?

Application

HA

Hardware

Abstraction

HA

HA

Hardware


Hardware abstraction architecture for tinyos 2 x l.jpg

Cross-platform applications

Platform-specific

applications

Platform-specific

applications

Platform-independent hardware interface

Hardware independence

HIL 1

HIL 2

HIL 3

HIL 4

HAL 1

HAL 2

HAL 3

HAL 4

HPL 2

HPL 1

HPL 3

HPL 4

HW/SW

boundary

HW platform 1

HW platform 2

HW platform 3

HW platform 4

Hardware Abstraction Architecture for TinyOS 2.x

Combine the component model with aflexible, three-tier organization of the hardware abstraction


Outline l.jpg

Outline

  • Hardware Abstraction for WSN Operating Systems

  • Three-layer Hardware Abstraction Architecture

    • Hardware Presentation Layer (HPL)

    • Hardware Adaptation Layer (HAL)

    • Hardware Interface Layer (HIL)

  • Flexibility of the Architecture

  • Application to Specific Hardware Modules

    • Analog-to-Digital Converters (ADC)

  • Conclusion


Hardware presentation layer hpl l.jpg

Cross-platform

application

HIL

HAL

HPL

HW platform

Hardware Presentation Layer (HPL)

  • “Present” the capabilities of the hardware using the native concepts of the OS

  • Interfaces fully determined by the HW module capabilities, but have a common structure

    • Initialization, starting and stopping

    • Getting and setting of the control registers

    • Enabling/disabling of interrupts

    • Service routines for the generated interrupts

  • Stateless, does not provide substantial abstraction over the hardware, but hides the most hardware-dependent code

    • Higher abstractions can change between HW modules of the same class with rewiring instead of rewriting


Hardware adaptation layer hal l.jpg

Cross-platform

application

HIL

HAL

HPL

HW platform

Hardware Adaptation Layer (HAL)

  • Uses the raw interfaces provided by the HPL to build useful abstractions

  • Exposes the “best” possible abstraction for the given hardware without compromising efficiency for convenience

  • Exports domain specific interfaces instead of narrow and overloaded abstractions

    • Alarm, ADC Channel, EEPROM Page…

  • Maintains state, performs arbitration and resource control if needed


Hardware interface layer hil l.jpg

Hardware Interface Layer (HIL)

  • Convert the platform-specific HAL abstractions into hardware-independent interfaces

  • Tension between keeping this API “contract” unchanged and efficient use of the capabilities on new hardware

  • Evolution in discrete jumps

    • Realign the HIL interfaces with the HAL abstractions of the newer platforms

    • New platforms get “thinner” HIL components

    • Old platforms will require more “boosting”

  • Support for legacy platforms

    • HIL interface versioning

    • Write applications using legacy interfaces

Cross-platform

application

HIL

HIL

HIL

ver. 1

HAL

HPL

HW platform


Properties why three layers l.jpg

Properties: Why three-layers?

  • Why not expose the platform-independent interfaces directly at the HAL level?

  • Because of the increased flexibility resulting from the separation!

Cross-platform

application

Platform-specific

application

HIL

HAL

HAL

  • For maximum performance, the platform-specific applications can directly tap to the HAL interfaces that provide optimizedaccess to the hardware

    • Similar in spirit with MIT’s Exokernel work

  • Layering does not mean overhead because of the nesC heavy in-lining

HPL

HW platform


First experiences with the architecture l.jpg

First used during the porting of TinyOS to the Texas Instruments MSP430 microcontroller family

Contained abstractions of the ADC, timer and bus modules

Implementation official part of TinyOS since ver.1.1.7

Code successfully used for a year by at least two platforms, Telos and Eyes

Main

MainM

BusArbitrationC

MSP430InterruptC

HPLInitC

HPLInitM

BusArbitrationM

MSP430InterruptM

HPLUARTC

HPLSpiM

HPLUARTM

MSP430ClockC

MSP430ClockM

HPLUSART0M

HPLUSART1M

ADCC

ADCM

MSP430ADC12C

MSP430ADC12M

RefVoltC

RefVoltM

TimerC

MSP430TimerC

TimerM

MSP430TimerM

HPLADC12M

First Experiences with the Architecture

Clock

System

60 KB

Flash

2 KB

RAM

12-Bit ADC

USART0

USART1

MAB

16-Bit

4-Bit

Bus Conv

RISC CPU

16-Bit

16-Bit

8-Bit

MDB

TimerA

TimerB

I/O port 1/2

Interrupt

Capability

I/O port 3-6

The TI MSP430F149 μC

The MSP430 platform in TinyOS 1.1.7


Example abstraction of the adc modules l.jpg

Example: Abstraction of the ADC modules

  • Challenge

    • High variability in the capabilities of the ADC hardware

      • Resolution

      • Conversion modes

      • Number of channels

      • Reference voltages

      • Conversion clock sources

      • Sample-and-hold times

      • Triggering

  • Goal

    • Gradually adapt these differences and provide useful platform-independent ADC abstraction to the application programmer while offering direct access when needed


Example hpl adc interface msp 430 platform l.jpg

HPL Commands

Standard Control

init()

start()

stop()

Full register reading/writing

setControl0()

getControl0()

setMemControl()

getMemControl()

Interrupt flag manipulation

setIEFlags()

getIEFlags()

isInterruptPending()

Configuration flag manipulation

setConversionMode()

isBusy()

setSHT()

setRefOn()

getRefOn()

setRef2_5V()

getRef2_5V()

HPL Events

memOverflow()

timeOverflow()

converted()

Example: HPL ADC interface (MSP 430 platform)

  • Completely defined by the capabilities of the ADC12

  • Provides low-level access to the hardware module


Example hal adc interface msp430 platform l.jpg

Example: HAL ADC interface (MSP430 platform)

  • Based on a “ADC channel” abstraction exported as parameterized interface

    • “bind” call used to configure each interface with the settings supported by the hardware module

  • Data requested using the traditional getData()

  • Available data signaled via dataReady() events

  • “reserve” call for low-latency sampling support

HAL supported settings

  • input channel

  • reference voltage

  • reference voltage level

  • clock source sample-hold-time

  • sample-hold-time

  • clock source sampcon signal

  • clock divider sampcon

  • clock divider sample-hold-time

HAL Commands

  • bind()

  • getData()

  • getDataRepeat()

  • reserve()

  • reserveRepeat()

  • unreserve()

    HAL Events

  • dataReady()


Example hil adc interface cross platform l.jpg

ADCHIL

StdControl

TemperatureC

MSP430ADC12

TemperatureM

MSP430ADC12C

Example: HIL ADC interface (cross-platform)

  • Wrapper that transforms a platform-independent “sensor” abstraction into platform-specific HAL calls and settings for the “bind” command

  • Exported interface is a compromise between the capabilities of the supported HW platforms

HIL Commands

  • getData()

  • getDataContinuous()

  • reserve()

  • reserveContinuous ()

  • unreserve()

    HIL Events

  • dataReady()

Temperature sensor HIL wrapper

on the MSP430 platform


Conclusion l.jpg

Conclusion

  • The new HAA continues TinyOS philosophy of making it possible to operate at higher levels of abstraction without forcing that on all applications

    • Code in HPL: trivial - just gives an interface to the raw hardware

    • Code in HAL: implements a useful abstraction efficiently

    • Code in HIL: adapt the platform-specific capability into a hardware independent form

  • Application to the ADC module

    • The new “sensor” stack offers richer functionality  

    • Now available as a common abstraction on severalplatforms


Questions l.jpg

Questions?

More information available:

TEP 2: Hardware Abstraction Architecture

TEP 102: Analog-to-Digital Converter Abstraction


Slide16 l.jpg

  • BACKUP


Properties mixing levels of abstraction l.jpg

Properties: Mixing Levels of Abstraction

  • Sometimes only parts of the application require efficient access to the hardware

Application

Application

MAC

Temperature

  • Example: OscilloscopeRF

    • Sample values from a temperature sensor and send them over the radio

    • Temperature sampling is not critical

      use the cross-platform HIL interfaces

    • MAC requires efficient use of the ADC

      use the platform-specific HAL interfaces

  • We end up with a concurrent use of the same ADC hardware module with two different levels of abstraction

     more complex arbitration and resource control functionality in the HAL components

HIL

HAL

HPL

ADC module


  • Login