The Hardware Abstraction Architecture of TinyOS 2.x

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
Hardware Abstraction in WSN Operating Systems

• What is the most appropriate level of hardware
  abstraction?

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

Application
HA
Hardware Abstraction
HA
HA
Hardware
3
Hardware Abstraction Architecture for TinyOS 2.x

• Combine the component model with a flexible,
  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
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
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
HAL
HIL
HAL

• For maximum performance, the platform-specific
  applications can directly tap to the HAL
  interfaces that provide optimized access to the
  hardware
• Similar in spirit with MITs Exokernel work
• Layering does not mean overhead because of the
  nesC heavy in-lining

HPL
HW platform
9
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 a year by at least two
  platforms, Telos and Eyes

Clock System
60 KB Flash
12-Bit ADC
USART0
USART1
2 KB RAM
MAB
Bus Conv
16-Bit
4-Bit
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
Example HPL ADC interface (MSP 430 platform)

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

• Configuration flag manipulation
• setConversionMode()
• isBusy()
• setSHT()
• setRefOn()
• getRefOn()
• setRef2_5V()
• getRef2_5V()
• HPL Events
• memOverflow()
• timeOverflow()
• converted()

• HPL Commands
• Standard Control
• init()
• start()
• stop()
• Full register reading/writing
• setControl0()
• getControl0()
• setMemControl()
• getMemControl()
• Interrupt flag manipulation
• setIEFlags()
• getIEFlags()
• isInterruptPending()

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