TinyOS

1. TinyOS

2. Learning Objectives • Understand TinyOS – the dominant open source operating systems for WSN • Hardware abstraction architecture (HAA) • TinyOS architecture and component model • Main characteristics of TinyOS 2 • Understand NesC programmng • Learn representative WSN applications

3. Prerequisites • Module 1 • Basic concepts of Operating Systems • Basic concepts of Object-oriented Design and Analysis • Basic concepts of Computer Networks

4. Software Challenges - TinyOS • Power efficient • Put microcontroller and radio to sleep • Small memory footprint • Non-preemptable FIFO task scheduling • Efficient modularity • Function call (event and command) interface between commands • Application specific • Concurrency-intensive operation • Event-driven architecture • No user/kernel boundary http://www.tinyos.net

5. TinyOS Hardware Abstraction Architecture (HAA) • Section 2.3 and Figure 2.5 of J. Polastre Dissertation: http://www.polastre.com/papers/polastre-thesis-final.pdf [TinyOS_1]: Table 2

6. TinyOS Hardware Abstraction Architecture (HAA) Ref: Figure 2.4 of J. Polastre Dissertation http://www.polastre.com/papers/polastre-thesis-final.pdf

7. Application 2 Application 1 Application 1 NFS I/O Micro-kernel Monolith-kernel IPC Scheduler Scheduler VM I/O VM HW HW Traditional OS Architectures • Problem with Large Scale Deeply embedded system.. • Large memory & storage requirement • Unnecessary and overkill functionality ( address space isolation, • complex I/O subsystem , UI ) for our scenario. • Relative high system overhead ( e.g, context switch ) • Require complex and power consuming hardware support.

8. Application Component Application Component Application Component TinyOS Architecture Overview (1) 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 instead Goal: to strip down memory size and system overhead.

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

10. Messaging Component Internal State Internal Tasks Commands Events TinyOS Component Model • Component has: • Frame (storage) • Tasks: computation • Interface: • Command • Event • Frame: static storage model - compile time memory allocation (efficiency) • Command and events are function calls (efficiency) [TinyOS_4]

11. Periodic Data Collection Network Maintenance Majority of operation Triggered Events Detection/Notification Infrequently occurs But… must be reported quickly and reliably Long Lifetime Months to Years without changing batteries Power management is the key to WSN success Typical WSN Application processing data acquisition communication Power wakeup sleep Time The mote revolution: Low Powr Wireless Sensor Network Devices, Hot Chips 2004

12. Design Principles • Key to Low Duty Cycle Operation: • Sleep – majority of the time • Wakeup – quickly start processing • Active – minimize work & return to sleep The mote revolution: Low Powr Wireless Sensor Network Devices, Hot Chips 2004

13. Minimize Power Consumption • Compare to Mica2: a MicaZ mote with AVR mcu and 802.15.4 radio • Sleep • Majority of the time • Telos: 2.4mA • MicaZ: 30mA • Wakeup • As quickly as possible to process and return to sleep • Telos: 290ns typical, 6ms max • MicaZ: 60ms max internal oscillator, 4ms external • Active • Get your work done and get back to sleep • Telos: 4-8MHz 16-bit • MicaZ: 8MHz 8-bit The mote revolution: Low Powr Wireless Sensor Network Devices, Hot Chips 2004

14. Power Consumption

15. Energy Consumption • Idle listen:receive:send = 1:1.05:1.4

16. TinyOS Radio Stack [Introduction_2]: Figure 3

17. Code and Data Size Breakdown [Introduction_2]: Table 2

18. WSN Protocol Stack Ref: [Introduction_1] “A Survey on Sensor Networks,” IEEE Communications Magazine, Aug. 2002, pp. 102-114.

19. TinyOS 2 • An operating system for tiny, embedded, and networked sensors • NesC language • A dialect of C Language with extensions for components • Three Limitations • Application complexity • High cost of porting to a new platform • reliability • Little more that a non-preemptive scheduler • Component-based architecture • Event-driven • Ref: P. Levis, et al. “T2: A Second Generation OS For Embedded Sensor Networks”

20. TinyOS 2 • Static binding and allocation • Every resource and service is bound at compile time and all allocation is static • Single thread of control • Non-blocking calls • A call to start lengthy operation returns immediately • the called component signals when the operation is complete • Split phase • See this link for one example http://docs.tinyos.net/index.php/Modules_and_the_TinyOS_Execution_Model • Ref: P. Levis, et al. “T2: A Second Generation OS For Embedded Sensor Networks” • Ref: [TinyOS_3] Section 2.1

21. TinyOS 2 • The scheduler has a fixed-length queue, FIFO • Task run atomically • Interrupt handlers can only call code that has the async keyword • Complex interactions among components • Event • In most mote applications, execution is driven solely by timer events and the arrival of radio messages • ATmega128 has two 8-bit timers and two 16-bit timers • Ref: P. Levis, et al. “T2: A Second Generation OS For Embedded Sensor Networks”

22. TinyOS 2 • sync code is non-preemptive, • when synchronous (sync) code starts running, it does not relinquish the CPU to other sync code until it completes • Tasks • enable components to perform general-purpose "background" processing in an application • A function which a component tells TinyOS to run later, rather than now • The post operation places the task on an internal task queue which is processed in FIFO order • Tasks do not preempt each other • A Task can be preempted by a hardware interrupt • See TinyOS lesson: • Modules and the TinyOS Execution Model

23. 802.15.4 and CC2420 • CC2420 hardware signals packet reception by triggering an interrupt • The software stack is responsible for reading the received bytes out of CC2420’s memory; • The software stack sends a packet by writing it to CC2420’s memory then sending a transmit command • Ref: P. Levis, et al. “T2: A Second Generation OS For Embedded Sensor Networks”

24. TinyOS 2 • Platforms • MicaZ, Mica2, etc; • Compositions of chips • Chips • MCU, radio, etc • Each chip follows the HAA model, with a HIL implementation at the top • Ref: P. Levis, et al. “T2: A Second Generation OS For Embedded Sensor Networks”

25. TinyOS 2 • A T2 packet has a fixed size data payload which exists at a fixed offset • The HIL of a data link stack is an active message interface • Zero-copy • Ref: P. Levis, et al. “T2: A Second Generation OS For Embedded Sensor Networks”

26. Scheduler in TinyOS 2.x SchedulerBasicP.nc of TinyOS 2.x

27. TinyOS Serial Stack • Ref: P. Levis, et al. “T2: A Second Generation OS For Embedded Sensor Networks”

28. Device Drivers in T2 • Virtualized • Dedicated • Shared • Ref: Section 3 of [Energy_1]

29. T2 Timer Subsystem • MCU comes with a wide variation of hardware timers • ATmega128: two 8-bit timers and two 16-bit times • MSP430: two 16-bit timers • Requirement of Timer subsystem • Different sampling rates: one per day to 10kHz [TinyOS_1]: Section 5

30. T2 Timer Subsystem • See interface at: • tos/lib/timer/Timer.nc

31. One Example TinyOS Application - BlinkC • http://docs.tinyos.net/index.php/TinyOS_Tutorials

32. One Example of Wiring • Ref: D. Gay, et al. “Software Design Patterns for TinyOS”

33. AppM • Ref: D. Gay, et al. “Software Design Patterns for TinyOS”

34. AppM • Ref: D. Gay, et al. “Software Design Patterns for TinyOS”

35. Sensor Interface • Ref: D. Gay, et al. “Software Design Patterns for TinyOS”

36. Initialize Interface • Ref: D. Gay, et al. “Software Design Patterns for TinyOS”

37. SensorC • Ref: D. Gay, et al. “Software Design Patterns for TinyOS”

38. AppC • Ref: D. Gay, et al. “Software Design Patterns for TinyOS”

39. Notation

40. CTP Routing Stack

41. Parameterized Interfaces • An interface array • Ref: D. Gay, et al. “Software Design Patterns for TinyOS”, Section 2.3

42. unique and uniqueCount • Want to use a single element of a parameterized interface and does not care which one, as long as no one else use it • Want to know the number of different values returned by unique • Ref: D. Gay, et al. “Software Design Patterns for TinyOS”, Section 2.4

43. async • Functions that can run preemptively are labeled with async keyword • Command an async function calls and events an async function signals must be async • All interrupt handlers are async • atomic keyword • Race conditions, data races section 4.5 "TinyOS Programming manual"

44. Generic Components and Typed Interface • Have at least one type parameter • Generic Components are NOT singletons • Can be instantiated within an configuration • Instantiated with the keyword new (Singleton components are just named)

45. Example - VirtualizeTimerC • Use a single timer to create up to 255 virtual timers • generic module VirtualizeTimerC(typedef precision_tag, int max_timers) • Precision_tag: A type indicating the precision of the Timer being virtualized • max_timers: Number of virtual timers to create. • How to use it? • Components new VirtualizeTimerC(TMilli, 3) as TimerA • This will allocate three timers • Components new VirtualizeTimerC(TMilli, 4) as TimerB • This will allocate three timers • Ref: • /tos/lib/timer/VirtualizeTimerC.nc • Section 7.1 of “TinyOS Programming Manual” /tos/lib/timer/VirtualizeTimerC.n

46. Virtualized Timer

47. Timer Stack on MicaZ/Mica2 Figure 4 of [TinyOS_1]

48. Timer Subsystem • HplTimer[0-3]C provide dedicated access to the two 8-bit and two 16-bit timers of ATmega128 MCU • T2 subsystem is built over the 8-bit timer 0 • Timer 1 is used for CC2420 radio

49. message_t • tos/types/message.h • Ref. TEP 111 • Every link layer defines its header, footer, and metadata structures

50. Relationship between CC1000 Radio Implementation and message_t • tos/chips/cc1000/CC1000Msg.h