Hardware Abstraction Architecture for TinyOS 2.x

1. Hardware Abstraction Architecture for 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

2. 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

3. 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

4. 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

5. 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

6. 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 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

7. 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

8. 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 expose the full capabilities of the hardware • Similar in spirit with MIT’s Exokernel work HPL HW platform

9. 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

10. 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 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

11. 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

12. 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

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

14. 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 • No “bind” command exported to the application HIL Commands • getData() • getDataContinuous() • reserve() • reserveContinuous () • unreserve() HIL Events • dataReady() Temperature sensor HIL wrapper on the MSP430 platform