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. http://www.tinyos.net4 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

5. [TinyOS_1]: Table 25 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

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

7. 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. VMI/O Scheduler Application 1 Application 2 Monolith-kernel HW NFSI/O Scheduler Application 1 Micro-kernel HW IPC VM

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

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

10. [TinyOS_4]10 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) Messaging Component Internal State Internal Tasks CommandsEvents

11. Power Optimization Energy is the most valuable resource All components must support low power modes (sleep) Low Duty cycle operation –Duty cycle - The proportion of time during which a device is operated Get job done quickly and go to sleep!

12. The mote revolution: Low Powr Wireless Sensor Network Devices, Hot Chips 2004 12 Typical WSN Application 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 sleep wakeup processing data acquisition communication Power Time

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

14. The mote revolution: Low Powr Wireless Sensor Network Devices, Hot Chips 2004 14 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

15. Power Consumption

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

17. [Introduction_2]: Figure 317 TinyOS Radio Stack

18. [Introduction_2]: Table 218 Code and Data Size Breakdown

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

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

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

22. 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”

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

24. 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”

25. 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”

26. 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 ”

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

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

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

30. [TinyOS_1]: Section 530 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

31. T2 Timer Subsystem See interface at: –tos/lib/timer/Timer.nc

32. One Example TinyOS Application - BlinkC http://docs.tinyos.net/index.php/TinyOS_Tutor ials

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

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

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

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

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

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

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

40. Notation

41. CTP Routing Stack

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

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

44. section 4.5 "TinyOS Programming manual" 44 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

45. 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)

46. /tos/lib/timer/VirtualizeTimerC.n46 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”

47. Virtualized Timer

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

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

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

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

52. Relationship between CC2420 Radio Implementation and message_t tos/chips/cc2420/CC2420.h

53. Relationship between Serial Stack Packet Implementation and message_t tinyos-2.x/tos/lib/serial/Serial.h

54. Active Message (AM) Why do we need AM? –Because it is very common to have multiple services using the same radio to communicate –AM layer to multiplex access to the radio make micaz install,n –n: unique identifier for a node

55. Active Message Every message contains the name of an event handler Sender –Declaring buffer storage in a frame –Naming a handler –Requesting Transmission –Done completion signal Receiver –The event handler is fired automatically in a target node No blocked or waiting threads on the receiver Behaves like any other events Single buffering Double Check!!!!!!!

56. TinyOS Component Two types of components –Module: provide implementations of one or more interfaces –Configuration: assemble other components together

57. 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) Messaging Component Internal State Internal Tasks CommandsEvents

58. Structure of a Component TinyOS Component Command Handlers Event Handlers Set of Tasks Frame (containing state information)

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

60. TinyOS Applications In most mote applications, execution is driven solely by timer events and the arrival of radio messages

61. How to Program motes Under TinyOS make telosb install,n mib510,/dev/ttyUSB0 make telosb install,1 mib510,/dev/ttyUSB0

62. Representative WSN Applications BaseStation – Listen – BlinkToRadio –One-hop WSN application to collect sensed values OscilloScope –one-hop WSN application with GUI interface MultiOscilloScopre –multihop WSN application Octopus –multi-hop WSN application with a more dynamic display of network topology and data dissemination functions

63. Application Example - BaseStation, Listen and BlinkToRadio

64. Application Example - Oscilloscope

65. Application Example - MultihopOscilloscope

66. Application Example - MViz

67. MViz

68. Application Example - Octopus http://csserver.ucd.ie/~rjurdak/Octopus.htm

69. Octopus

70. BaseStation – Listen - BlinkToRadio

71. OscilloScope

72. MultihopOscilloscope

73. MViz

74. Octopus

75. Lab 1 a) Write a PingPong application that runs on two nodes. When a node boots, it sends a broadcast packet using the AMSend interface. When it receives a packet, it a) wait one second; b) sends a packet; c) toggle an LED whenever a node sends a packet.

76. Lab 2 b) Please add the reliable data transmission feature to the PingPong application from the Application and Link layer, respectively. Suppose that two motes A and B are talking to each other. I. Application Layer: When mote A sends a broadcast pack P to node B, mote A will start a timer T. When mote B receives the packet P, mote B will send an ACK to node A. b.1 If the timer T expires before mote A receives the ACK from mote B (either the packet P or the ACK is lost), mote A will retransmit the packet; b.2 If mote A receives the ACK from mote B before the timer T expires, mote A will do nothing when the timer T expires. b.3 If mote B receive a packet which has already been received (based on sequence number), node B just drop this packet. There is a sequence number included in the payload of the packet P. The sequence number starts from 0. When a packet P is received, the receiver will display the bottom three bits (through LEDs) of the sequence number in the packet P.

77. Lab 2 - continue II. Link Layer: In TEP 126 (http://www.tinyos.net/tinyos- 2.x/doc/html/tep126.html), it says: “PacketLink: This layer provides automatic retransmission functionality and is responsible for retrying a packet transmission if no acknowledgement was heard from the receiver. PacketLink is activated on a per-message basis, meaning the outgoing packet will not use PacketLink unless it is configured ahead of time to do so” Therefore, as an alternative, you may also configure PacketLink to provide automatic retransmission functionality,

78. Assignment 1. What is the relationship among all the application components in the Oscilloscope application? 2. please give two examples of split-phase operations in TinyOS 2. 3. What is the usage of Active Message in TinyOS 2 4. Why doesn’t TinyOS 2 make every statement async?