Introduction to TinyOS

Open Experimental Platform
Services Networking TinyOS
WeC 99 ³Smart Rock´ Rene 11/00 Dot 9/01 Mica 1/02 Telos 4/04 Robust Low Power 250kbps Easy to use

Small microcontroller 8 kB code 512 B data Simple, low-power radio 10 kbps ASK EEPROM (32 KB) Simple sensors Designed for experimentation -sensor boards -power boards

Demonstrate scale

Mica2 12/02 38.4kbps radio FSK NEST open exp. Platform 128 kB code, 4 kB data 40kbps OOK/ASK radio 512 kB Flash

Spec 6/03 ³Mote on a chip´

Commercial Off The Shelf Components (COTS)

Reminder
‡ watt = voltage * amphere
² Unit of power

‡ joule = watt * second
² Unit of energy

etc) doubling every 1-2 years ‡ Bell¶s Law ± New computing class every 10 years Streaming Data to/from the Physical World log (people per computer) year Source: HotChips 2004 . Numerous ‡ Moore¶s Law ± ³Stuff´ (transistors. Smaller.Faster.

Mote Evolution Source: HotChips 2004 .

Design Principles ‡ Key to Low Duty Cycle Operation: ± Sleep ± majority of the time ± Wakeup ± quickly start processing ± Active ± minimize work & return to sleep Source: HotChips 2004 .

node is asleep ± >99% ‡ Minimize sleep current through ± Isolating and shutting down individual circuits ± Using low power hardware ‡ Need RAM retention ‡ Run auxiliary hardware components from low speed oscillators (typically 32kHz) ± Perform ADC conversions. DMA transfers.Sleep ‡ Majority of time. and bus operations while microcontroller core is stopped Source: HotChips 2004 .

Wakeup ‡ Overhead of switching from Sleep to Active Mode ‡ Microcontroller ‡ Radio (FSK) 292 ns 10ns ± 4ms typical 2.5 ms 1± 10 ms typical Source: HotChips 2004 .

Flash ± 250kbps radio sending 1 byte ‡ Energy : 1. simple channel encoding. higher power. faster startup ‡ Radio vs. network code reprogramming. low active power ± Avoid external oscillators ‡ External Flash (stable storage) ± Data logging. low power tradeoffs ± Narrowband radios ‡ Low power. lower data rate. high data rates Source: HotChips 2004 . aggregation ± High power consumption ± Long writes ‡ Radio ± High data rate.5QJ ‡ Duration : 32Qs ± Atmel flash writing 1 byte ‡ Energy : 3QJ ‡ Duration : 78Qs ± Wideband radios ‡ More robust to noise.Active ‡ Microcontroller ± Fast processing.

2 ms wakeup 30 QW sleep 33 mW active 250 kbps 2.5V min ‡ 2/3 of AA capacity Report data once every 3 minutes with two AA batteries (<1% duty cycle) 453 days 328 days 945 days .006 ms wakeup 2 QW sleep 3 mW active 250 kbps 1.Power Calculation Comparison Design for low power ‡ Mica2 (AVR) ± ± ± ± ‡ MicaZ (AVR) ± ± ± ± ± ‡ Telos (TI MSP) ± ± ± ± ± 0.8V min ‡ 8/8 of AA capacity 0.5V min 0.2 ms wakeup 30 QW sleep 33 mW active 19 kbps ‡ 2/3 of AA capacity ± 2.

x/doc/html/tep106.net/tinyos-2.x ‡ http://www. sensor.html ‡ Perfect??? ‡ Real-time . actuator) ± ± ± ± ± Real-time query and feedback control of physical world Little memory for buffering: Data must be processed on the fly TinyOS: No buffering in radio hw: deadline miss data loss TinyOS provides NO real-time guarantees! EDF (Earliest Deadline First) scheduling supported in TinyOS 2.Software challenges ‡ ‡ ‡ ‡ ‡ Power efficiency Small memory footprint Application specific Modularity Concurrency-intensive operations ± Multiple. high-rate data flows (radio.tinyos.

´General-Purposeµ OS? MANY functionalities & programming APIs ‡ Protection between ³untrusted´ applications and kernel ± Overhead for crossing kernel/user boundary & interrupt handling ‡ Multi-threaded architecture ± Large number of threads ± Context switch overhead large memory ‡ I/O model ± Blocking I/O: waste memory on blocked threads ± Polling: waste CPU cycles and power ‡ Need a new OS architecture! .

TinyOS Overview ‡ Application = scheduler + graph of components ± Compiled into one executable ‡ Event-driven architecture ‡ Single shared stack ‡ No kernel/user space differentiation Main (includes Scheduler) Application (User Components) Actuating Communication Sensing Communication Hardware Abstractions .

complex I/O subsystem.Traditional OS Architectures Application 1 Application 2 Application 1 NFS Micro-kernel Scheduler IPC Scheduler HW VM I/O Monolithic kernel VM I/O HW Problems ‡ Large memory & storage requirement ‡ Unnecessary and overkill functionality ‡ Address space isolation. e.g. UI ‡ Relative high system overhead. context switch ‡ Require complex and power consuming hardware support .

Desirable OS architecture ‡ Extremely small footprint ‡ Extremely low system overhead ‡ Extremely low power consumption .

. TinyOS Application Component ««.TinyOS Architecture Overview Scheduler Application Component I/O Application Component COMM . NO Kernel Direct hardware manipulation NO Process management Only one process on the fly NO Virtual memory Single linear physical address space NO Dynamic memory allocation Assigned at compile time NO Software signal or exception Function call Goal: to strip down memory size and system overhead.

power constrained Application specific HW and SW Multiple flows. concurrent bursts Extremely passive vigilance (power saving ) Tightly coupled with the application Main (includes Scheduler) Application (User Components) Active Message Actuating Sensing Communication Mote Hardware Simplified TinyOS Architecture .TinyOS Architecture Overview ‡ Characteristics of TinyOS ± ± ± ± ± No UI.

TinyOS component model ‡ Component has: ± Frame: storage ± Tasks: computation ± Interface ‡ Command ‡ Event Messaging Component Internal Tasks Internal State Commands Events ‡ Frame: static storage model .compile time memory allocation (efficiency) ‡ Command and events are function calls (efficiency) .

An Example Application application sensing application routing Routing Layer messaging Messaging Layer packet Radio Packet byte Radio byte (MAC) photo Temp SW HW bit RFM clocks ADC i2c .

or post tasks Preempt POST events Tasks FIFO commands commands Interrupts Hardware Time . tasks do not ± Events can signal events. call commands.TinyOS Two-level Scheduling ‡ Tasks do computations ± Non-preemptive FIFO scheduling ± Bounded number of pending tasks ‡ Events handle concurrent dataflows ± Interrupts trigger lowest level events ± Events preempt tasks.

scheduler shuts down the node except for clock .Two-Level Scheduling ‡ Event and Task ± Tasks cannot preempt other tasks ± Single shared stack ‡ Used by both interrupts and function calls ± Simple FIFO scheduler ± Events can preempt a task ± Events can preempt each other ± When idle.

Event implementation Event is independent of FIFO scheduler. ‡ Lowest level events are supported directly by Hardware interrupt ‡ Software events propagate from lower level to upper level through function call .

How to handle multiple data flows? ‡ Data are handled by ± A sequence of non-blocking event/command (function calls) through the component graph ± Post tasks for computations that are not ³emergent´ ‡ Preempting tasks to handle new data .

retransmission) ± Tied with multi-threaded architecture ‡ TinyOS solution: Active Messages . ack.How should network msg be handled? ‡ Socket/TCP/IP? ± Too much memory for buffering and threads ‡ Data are buffered until application threads read it ‡ Application threads blocked until data is available ± Transmit too many bits (sequence #.

Active Message ‡ Every message contains the name of an event handler ‡ Sender ± ± ± ± Declare buffer storage in a frame Name a handler Request Transmission Done .completion signal ‡ Receiver ± The corresponding event handler invoked  No blocked or waiting threads on the receiver  Behaves like any other events  Single buffering .

Analysis and Evaluation ‡ Space. Power and Time .

Code and Data Size Breakdown Scheduler: 178 Bytes code Totals: 3450 Bytes code 226 Bytes data .

Time Breakdown .

Time Breakdown Total propagation delay: 40 us (80 instructions) .

Power Breakdown« .

Evaluation of TinyOS ‡ Small memory footprint ‡ Power efficient ˜ ± Put microcontroller and radio to sleep ˜ ± Non-preemptable FIFO task scheduling ‡ Efficient modularity ˜ ± Function call (event. no user/kernel boundary) ‡ Real-time v ± Non-preemptable FIFO task scheduling ± No real-time guarantees or overload protection . command) interface between components ‡ Concurrency-intensive operations ˜ ± Event-driven architecture ± Efficient interrupts/events handling (function calls.

e.g.& deadline-driven scheduling? ² RM? EDF? ² Appropriate for data-centric applications? ² How to deal with multiple resources.What should be added to TinyOS? ‡ Priority. CPU & wireless bandwidth? Extend RM or EDF? ‡ End-to-end timing guarantees? ‡ Reliable synchronization mechanism? ‡ Internet or large scale service infrastructure? ² Interoperability? ² Protocols? ‡ TCP/IP. RTP? ‡ « . UDP..

Sign up to vote on this title
UsefulNot useful