220 likes | 472 Views
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….
E N D
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…
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? TTX II
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… • Don’t want to disrupt current work and systems TTX II
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 TTX II
Outline • Motivation • TinyOS 2.0 design • Process • Roadmap TTX II
Outline • Motivation • TinyOS 2.0 design • Process • Roadmap TTX II
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 TTX II
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 what’s broken • Don’t fix what works • Allow for possibility of compatibility shims • Keep basic programming model • Document discussion and decisions: TEPs TTX II
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 -> HAL -> 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 TTX II
Service Libraries, Distributions • TinyOS enables flexible boundaries • But everything is Timer, SendMsg|Send, 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” TTX II
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 TTX II
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 TTX II
New software architecture Improved Timer interfaces Multiple resolutions Alarm interface Using platform-specific functionality is clear Platform requirements are well defined (TimerC) Timers, Continued TimerC ChipHIL ChipHAL ChipHPL Hardware TTX II
Outline • Motivation • TinyOS 2.0 design • Process • Roadmap TTX II
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) TTX II
The Four TEP Classes • Best Common Practices (BCP) • Documentary • Experimental • Informational TTX II
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 you’d like, of course • TEP 1: TEP structure and key words • TEP 2: Hardware decomposition (HPL/HAL/HIL) • TEP 3: Coding conventions TTX II
Documentary • Document a working and stable TinyOS system in the core • Must follow all BCPs • TEP 101: ADC • TEP 102: Timer • TEP 103: Storage TTX II
Outline • Motivation • TinyOS 2.0 design • Process • Roadmap TTX II
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! TTX II
The Future • March: Single-hop networking (cross-platform!) • April: Collection routing (cross-platform!) • May: OSKI v1.0 TTX II
Questions TTX II