1 / 17

The Hardware Abstraction Architecture of TinyOS 2.x

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.

oshin
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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) • Conclusion

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

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

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

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

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

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

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

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

  15. Questions? More information available: TEP 2: Hardware Abstraction Architecture TEP 102: Analog-to-Digital Converter Abstraction

  16. BACKUP

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

More Related