Hardware Abstraction Architecture for TinyOS 2.x

Energy efficient sensor networks

Hardware Abstraction Architecture for TinyOS 2.x

Vlado Handziski*, Joseph Polastre†, Jan Hauer*, Cory Sharp†, Adam Wolisz* and David Culler†

*Telecommunication Networks GroupTechnische Universität Berlin

†Computer Science Department University of California, Berkeley

TinyOS Tecnology Exchange II2 energy efficient sensor networks

Telecommunication Networks Group

Technische Universität Berlin

Computer Science Department

University of California, Berkeley

Hardware Abstraction in WSN Operating Systems

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

Application

What is the most appropriate level of hardware abstraction?

HardwareAbstraction

HA

HAHA






Hardware Abstraction Architecture for TinyOS 2.x

Combine the component model with a flexible, three-tier organization of the hardware

abstraction

HW platform 2

HPL 2

HAL 2

HIL 2

HW platform 3

HPL 3

HAL 3

HIL 3

HW platform 1

HPL 1

HAL 1

HIL 1

HW platform 4

HPL 4

HAL 4

HIL 4

Platform-specificapplications

Platform-specificapplications

Cross-platform applications

Platform-independent hardware interface

HW/SWboundary

Hard

ware

in

dependence






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) Implementation status






HW platform

HPL

HAL

HIL

Cross-platformapplication

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






HW platform

HPL

HAL

HIL


Hardware Adaptation Layer (HAL)

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

Exposes the “best” possible abstraction while maintaining access to the full capabilities of the HW

Exports domain specific interfaces instead of narrow and overloaded abstractions

Alarm, ADC Channel, EEPROM Page… Maintains state, performs

arbitration and resource control if needed






HILHIL

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 HW platform

HPL

HAL

HIL


ver. 1






HAL

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!

HW platform

HPL

HAL

HIL


Platform-specificapplication

For maximum performance, the platform-specific applications can directly tap to the HAL interfaces that expose the full capabilities of the hardware

Similar in spirit with MIT’s Exokernel work






Properties: Mixing Levels of Abstraction

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

ADC module

HPL

HAL

HIL

Application

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

Application

MAC Temperature






First Experiences with the Architecture

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 nearly a full year by two

platforms: Telos and EyesMain

HPLUARTC

ADCC

HPLUSART0M HPLUSART1M

HPLUARTMHPLSpiM

ADCM

MSP430InterruptCMainM

HPLInitC

BusArbitrationC

MSP430ADC12CMSP430ADC12M

RefVoltC

HPLADC12M

RefVoltM

MSP430InterruptMBusArbitrationMHPLInitM

MSP430ClockC

MSP430ClockM

TimerC

TimerM

MSP430TimerC

MSP430TimerM

RISC CPU16-Bit

ClockSystem

60 KBFlash

12-Bit ADC USART0 USART1

TimerA TimerBI/O port 1/2

InterruptCapability

2 KBRAM

I/O port 3-6

MAB

MDB

Bu

s C

on

v

16-Bit

16-Bit 8-Bit

4-Bit

The TI MSP430F149 μC

The MSP430 platform in TinyOS 1.1.7






Example: Abstraction of the ADC modules

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

Gradually adapt these differences and provide useful platform-independent ADC abstraction to the application programmer






Example: HPL ADC interface (MSP 430 platform)

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()

Completely defined by the capabilities of the ADC12 Provides low-level access to the hardware module






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 Commands bind() getData() getDataRepeat() reserve() reserveRepeat() unreserve()

HAL Events dataReady()

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






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

No “bind” command exported to the application

HIL Commands getData() getDataContinuous() reserve() reserveContinuous

() unreserve()

HIL Events dataReady()

TemperatureC

TemperatureM MSP430ADC12C

ADCHIL

StdControl

MSP430ADC12

Temperature sensor HIL wrapperon the MSP430 platform

Documents

Hardware Abstraction Architecture for TinyOS 2.x