Introduction to TinyOS

1. Introduction to TinyOS

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

3. Mote Evolution Source: HotChips 2004

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

5. Sleep • Majority of time, 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, and bus operations while microcontroller core is stopped • There’s wake-up overhead too Source: HotChips 2004

6. Reminder • watt = voltage * amphere • Unit of power • joule = watt * second • Unit of energy

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

8. MicaZ (AVR) 0.2 ms wakeup 30 mW sleep 33 mW active 250 kbps Telos (TI MSP) 0.006 ms wakeup 2 mW sleep 3 mW active 250 kbps Power Calculation ComparisonDesign for low power • Mica2 (AVR) • 0.2 ms wakeup • 30 mW sleep • 33 mW active • 19 kbps Report data once every 3 minutes with two AA batteries (<1% duty cycle) 453 days 328 days 945 days

9. Software challenges • Power efficiency • Small memory footprint • Application specific • Modularity • Concurrency-intensive operations • Multiple, high-rate data flows (radio, sensor, actuator) • Real-time • 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.x • http://www.tinyos.net/tinyos-2.x/doc/html/tep106.html

10. “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  large memory • Context switch overhead • I/O model • Blocking I/O: waste memory on blocked threads • Polling: waste CPU cycles and power • Need a new OS architecture!

11. 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 Sensing Communication Communication Hardware Abstractions

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

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

14. Application Component Application Component Application Component TinyOS Architecture Overview TinyOS Scheduler ……. I/O 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 exceptionFunction call Goal: to strip down memory size and system overhead.

15. Actuating Sensing Active Message Communication TinyOS Architecture Overview • Characteristics of TinyOS • No UI, 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) Simplified TinyOS Architecture Mote Hardware

16. Messaging Component Internal State Internal Tasks Commands Events TinyOS component model • Component has: • Frame: storage • Tasks: computation • Interface • Command: request to lower-level components • Event: deal with hardware events • Frame: static storage model - compile time memory allocation (efficiency) • Command and events are function calls (efficiency)

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

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

19. Two-Level Scheduling • Event and Task • Tasks cannot preempt other tasks or events • 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, scheduler shuts down the node except for clock

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

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

22. 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 #, ack, re-transmission) • Tied with multi-threaded architecture • TinyOS solution: Active Messages

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

24. Analysis and Evaluation • Space, Power and Time

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

26. Time Breakdown

27. Power Breakdown…

28. Summary: TinyOS • Component-based architecture • An application wires reusable components together in a customized way • Tasks and event-driven concurrency • Tasks & events run to completion, but an event can preempt the execution of a task or an event • Tasks can’t preemt another task or event • Split-phase operations (for non-blocking operations) • A command will return immediately and an event signals the completion

29. A quick look at nesC • [O2] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler, The nesC Language: A Holistic Approach to Networked Embedded Systems, ACM Conference on Programming Language Design and Implementation (PLDI), June 2003.

30. Component • A component provides and uses interfaces • The interfaces are the only point of access to the component • An interface models some service, e.g., sending a msg • The provider of a command implements the commands, while the user implements the events

31. Interface • Bidirectional interfaces support split-phase execution

32. Component implementation • Two types of components: modules & configurations • Modules provide application code and implements one or more interfaces • Configurations wire components together • Connect interfaces used by components to interfaces provided by others

33. Module • Surge: Get a sensor reading and send a message every second

34. Configuration • Wire TimerM and HWClock components together

35. Example: SurgeC configuration

36. Concurrency and Atomicity • Asynchronous code (AC): reachable from at least one interrupt handler • Synchronous code (SC): only reachable from tasks • Synchronous code is atomic w.r.t. other synchronous code • Still potential races between AC and SC • Any update to shared state from AC • Any update to shared state from SC that is also updated from AC • Solution: Race-Free Invariant • Any update to a shared variable is by SC or occurs inside an atomic section

37. atomic & norace • Atomic • Disable interrupts • Atomic statements are not allowed to call commands or events • If a variable x is accessed by AC, any access of x outside of an atomic section is a compile time error • An atomic section should be short! • norace • If a programmer knows a potential race is not an actual race, declare norace Disable interrupts Enable interrupts

38. Evaluation • Tested for three TinyOS applications • Surge, Mate, TinyDB • Core TinyOS consists of 172 components • 108 modules & 64 configurations • Group necessary components, via nesC’s bidirectional interfaces, for a specific application

39. Effect of inlining • Impact of inlining on footprint and performance

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

41. Is TinyOS a silver bullet? • Preemptive & deadline-driven scheduling? • More support for power and energy-efficiency beyond OS? • End-to-end timing guarantees? • Reliable synchronization mechanism? • Most of things, e.g., I/O, are asynchronous • Comeback of multithreading? • Most programmers are more used to multithreaded than event-driven programming • TinyThreads, TOSThreads

42. Other WSN Operating Systems • Contiki • Events & Threads: Lightweight threading mechanism, called protothreads • Flash file system, called Coffee • Mantis • Preemptive time-sliced multithreading • Synchronous I/O • Concurrency control, e.g., binary & counting semaphores • Nano-RK • Reservation-based RTOS for WSNs • Fixed priority preemptive multitasking to meet real-time dedadlines • CPU and network bandwidth reservation • Socket-like abstractions and network scheduling and routing

43. RTEOS • Dual mode (kernel & user mode) • Application code checking at compile and runtime • Multithreading & support for POSIX 1003.b real-time scheduling • LiteOS • Traditional Unix-like environment • Built-in hierarchical file system & a wireless Unix-like command shell • Kernel support for dynamic loading of multithreaded applications • LiteC++ (OO language using a subset of C++)

44. For a more comprehensive survey of WSN OS, talk to me to get a copy of: “Providing OS support for wireless sensor networks: challenges and approaches”, IEEE Communication Surveys and Tutorials. • For more info about TinyOS, visit www.tinyos.net

45. Next Class • At the beginning of the next class, submit one-page critique on the S-MAC paper: [M2] “An Energy-Efficient MAC Protocol for Wireless Sensor Networks”