T2: A Second Generation OS For Introduction Embedded Sensor - PDF document

Outline T2: A Second Generation OS For � Introduction Embedded Sensor Networks � TinyOS-2.x Core � Comparison to other mote OSs � Critique Presented by: Kevin Klues Department of Computer Science and Engineering 2 TinyOS Development Trends What is T2? � Platform development � Complete rewrite of the TinyOS operating system � Mica family, Telos, eyes, TinyNode, iMote… � Many similar principles, but not necessarily compatible � Commonalities: micaZ and Telos � Revisit basic abstractions: remove historical artifacts Need system support for introduction of new platforms � Designed to meet three goals: � � Emergence of basic system abstractions � Simplify/improve platform support � Timers, communication, collection routing � Support higher level abstractions � New work addresses mostly higher layers � Improve system robustness and reliability � Need for stable, robust implementations 3 4 Why Not Adapt TinyOS 1.x? T2 Design Principles � � It has a well established code base, lots of users Telescoping Abstractions � Layered implementation of device drivers � Why not slowly ease in improvements? � Lowest layers allow for fine grained control of device � Some improvements are not backwards compatible � Higher layers more portable � • Task model Virtualized Services Result: a periodic compatibility battle � Hide complexity of sharing resources � � Arbitration of shared devices (exclusive virtualization) � Regularly breaking code is contrary to the benefit of � Timers (concurrent virtualization) an established code base… � Static Binding and Allocation � Didn’t want to disrupt existing work and systems All memory allocated at compile time � � All resources/services bound at compile time 5 6 1

Major differences from TinyOS-1.x Outline � More restrictive concurrency model � Introduction Task scheduler has changed � � TinyOS-2.x Core � Allows for custom task scheduler to be inserted � Different boot sequence � Comparison to other mote OSs � StdControl split into two separate interfaces (Init, StdControl) � Boot interface with single event indicating mote has booted � Critique � New set of interfaces � Send/Receive interfaces have changed Interfaces designed around use of virtualized services � � Requires the use of nesC 1.2 � Relies heavily on the use of generic components � Allows compile time wiring checks (@exactlyonce, etc.) � http://csl.stanford.edu/~pal/pubs/tinyos-programming-1-0.pdf 7 8 Decomposition of Components Hardware Abstraction Architecture � Telescoping abstractions (Design Principle 1) Hardware Interface Layer (HI L) � Vertical vs. Horizontal decomposition • Provides platform independent interface Hardware Abstraction Architecture (HAA) � • Used to write cross platform applications Chip abstractions (MCU, radio, flash, etc.) � Hardware Adaptation Layer (HAL) � Chips composed together to build up platform Hardware Presentation Layer (HPL) • Uses HPL to provide “useful” chip dependent interface � Chip dependent vs. platform dependent code • Exposes full capabilities of the hardware • Used to write chip dependent applications • Pulls low level C library calls into nesC • Never used directly by components other than HAL 9 10 Virtualized Services Virtualized Services (con’t) � Implemented at the HIL layer � Implementation of TimerMilliC � Hides resource sharing from user generic configuration TimerMilliC() { � Instantiate generic components using “new” keyword provides interface Timer<TMilli>; } Indirectly removes errors with using “unique” � implementation { components TimerMilliP; configuration BlinkAppC{} implementation { components MainC, BlinkC, LedsC; Timer = TimerMilliP.TimerMilli[unique(UQ_TIMER_MILLI)]; } components new TimerMilliC() as Timer; BlinkC -> MainC.Boot; BlinkC.Timer -> Timer; BlinkC.Leds -> LedsC; } 11 12 2

Core Components Task Scheduler � Platform Independent � Implemented in nesC as a TinyOS component � Task Scheduler Tinyos-1.x scheduler written in C and not easily changed � � Resource Arbiters � Allows new schedulers to be created as desired � Resource Power Managers � Reserves a single slot for each individual task � Collection and Dissemination routing � Deluge/Trickle (over the air code propagation) � Doesn’t allow new posts from same task to be made until � Platform/Chip Dependent previous one has started running Timers � � Possible because of static binding � Radio Stacks � Runs tasks in FIFO order without preemption � Serial Stacks � ADCs � Sensor Drivers � Non-volatile storage (Flash) 13 14 Task Scheduler (con’t) Timer Abstraction � � Follows telescoping abstraction principle Provides provisions for performing mcu power management � Whenever empty, try and go to sleep � Bottom layer provides microcontroller specific interfaces � Uses mcu-chip specific McuSleepC component to dedicated hardware timer command void Scheduler.taskLoop(){ � Upper layers virtualize the use of these timers, providing for (;;){ a platform independent interface uint8_t nextTask; atomic{ while((nextTask = popTask()) == NO_TASK){ call McuSleep.sleep(); } } signal TaskBasic.runTask[nextTask](); } } 15 16 Radio Communication Radio Communication (con’t) � Packet formats defined by platform � Virtualized Send Service � Radio chips define own packet header formats � As far as each user is concerned he is the only sender � Platform maps these into that platforms packet type � Calls to send don’t fail just because other users are trying to send at the same time (they get queued) � Headers added at each level of networking stack � Guaranteed slot per sender (similar to Task Scheduler) � Default Data Link abstraction (Active Messages) � Calls to send guaranteed to succeed as long as two consecutive calls aren’t made before previous runs � Different from tinyos-1.x model � GenericComm component had queue of fixed length � When that queue filled, calls to send would fail Had to be careful to try and resend due to failure � Same user could put multiple packets in queue � 17 18 3