TinyOS 2'0

1
TinyOS 2.0

• TinyOS Technology Exchange II
• Phil Buonadonna, David Culler, David Gay, Ben
  Greenstein, Vlado Handziski, Jan Hauer, Jonathan
  Hui, Kevin Klues, Philip Levis, Joe Polastre,
  Lama Nachman, Cory Sharp, Gilman Tolle, Martin
  Turon, Adam Wolisz, Ion Yannopoulos, and more

2
Trends in TinyOS Use

• Platforms are multiplying
• Mica family, XSM, Telos family, eyes, iMote2
• Commonalities micaZ and Telos
• Basic system abstractions have emerged
• Timers, communication, collection routing
• Work is beginning to address higher layers
• Use is creeping from research to deployment
• Increasing need for robustness
• Stable abstraction implementations needed
• How can we best support these trends of growth?

3
Why Not Adapt TinyOS 1.x?

• Well established code base, a lot of users
• Slowly ease in improvements
• But some improvements are not backwards
  compatible
• Task model
• Result a periodic compatibility battle
• Regularly breaking code is contrary to the
  benefit of an established code base
• Dont want to disrupt current work and systems

4
Another Solution TinyOS 2.0

• Build on five years of community experience
• A clean break from 1.x code
• Many similar principles. but not required to be
  compatible
• Revisit basic abstractions remove historical
  artifacts
• Core goals
• Simplify/improve platform support
• Better support higher level abstractions,
  distributions
• Improve system robustness and reliability
• Sooner is better than later
• Document design through a community process

5
Outline

• Motivation
• TinyOS 2.0 design
• Process
• Roadmap

6
Outline

• Motivation
• TinyOS 2.0 design
• Process
• Roadmap

7
Three Major Design Goals

• Simplify supporting new platforms
• Decompose components tos/chips
• Define the hardware independent boundary
• Platform independent data (network types)
• Support design of service libraries building up
• Allow levels of abstraction above AM and Timer
• Distributions are packaged sets of working
  services
• Improve robustness, reliability
• Better code reuse
• More robust task model
• Support improved compile-time checks

8
Constraints and Process

• Backwards compatibility
• Desirable, but not required
• Changes OK, but drastic changes are problematic
• Try to limit transition pain for existing code
• Use nesC 1.2 (more on this later)
• Fix whats broken
• Dont fix what works
• Allow for possibility of compatibility shims
• Keep basic programming model
• Document discussion and decisions TEPs

9
Adding New Platforms

• Enable sharing a platform is a collection of
  chips (tos/chips)
• micaZ ATMega128 CC2420 at45b
• Telos MSP430 CC2420 STM25p
• eyes MSP430 TDA5250 MP5205
• Defined platform independent boundary
• Packet communication, timers,etc.
• Structure for writing platform specific code
• Three layers HPL -gt HAL -gt HIL
• Three layers allow platform-specific
  optimizations when needed
• Vlado will speak more on this later
• Platform independent types
• Joe/David G. will speak more on this later

10
Service Libraries, Distributions

• TinyOS enables flexible boundaries
• But everything is Timer, SendMsgSend, ADC
• Support concept of distributions
• Collection of components that work together
• Support concept of services
• Abstractions that distributions provide
• Not enough time to present this today, but a TEP
  will be forthcoming on an example, OSKI

11
Robustness

• New task semantics for improved robustness
• Per-task reserved slot
• Posting only fails if task is already posted
• Usually simplifies code (fewer busy flags, etc.)
• Cost one byte per task (Maté 43B, TinyDB 52B)
• Improved compile-time checks
• Wiring at most once, exactly once, at least once
• Attributes allow writing new checks
• Help prevent common mistakes
• E.g, unique strings

12
Example Timers

• Driving example in 2.0 design
• Critical concern in most TinyOS systems
• tinyos-1.x Timer interface is inadequate
• Need additional operations (how much time
  remaining?)
• Need timers of varying granularities (ms, 32Khz,
  etc.)
• tinyos-1.x TimerC implementation
• Robustness issues (tasks)
• Assumptions of Atmega 128 not portable
• HIL (TimerC) platform independent abstraction
• HAL/HPL platform dependent decomposition

13
Timers, Continued

• New software architecture
• Improved Timer interfaces
• Multiple resolutions
• Alarm interface
• Using platform-specific functionality is clear
• Platform requirements are well defined (TimerC)

TimerC
ChipHIL
ChipHAL
ChipHPL
Hardware
14
Outline

• Motivation
• TinyOS 2.0 design
• Process
• Roadmap

15
TEP TinyOS Enhancement Proposal

• Based on the Python PEP and IETF RFC models
• Generated from TinyOS Working Groups (WGs)
• Document and describe parts of TinyOS
• Promote interoperability
• Beyond works just like
• All TEPs are publically available on the web
• All are still in Draft form WGs welcome
  comments!
• http//www.tinyos.net/scoop/special/working_group_
  tinyos_2-0
• (also includes transcripts of meetings)

16
The Four TEP Classes

• Best Common Practices (BCP)
• Documentary
• Experimental
• Informational

17
BCPs

• Numbered from 1 to 100
• All others are 101
• As close to a standard as we get
• Describe practices or approaches that all TinyOS
  core code must follow
• You can write whatever code youd like, of course
• TEP 1 TEP structure and key words
• TEP 2 Hardware decomposition (HPL/HAL/HIL)
• TEP 3 Coding conventions

18
Documentary

• Document a working and stable TinyOS system in
  the core
• Must follow all BCPs
• TEP 101 ADC
• TEP 102 Timer
• TEP 103 Storage

19
Outline

• Motivation
• TinyOS 2.0 design
• Process
• Roadmap

20
The Past

• August 2004 First meeting of the 2.x WG
• September TEPs model discussion
• October-November TEP structure, platforms
• December Implementation begins
• January Boot sequence, getting things working
• February First application compilation!

21
The Future

• March Single-hop networking (cross-platform!)
• April Collection routing (cross-platform!)
• May OSKI v1.0

22
Questions