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

• Basic knowledge of Operating Systems,
  Object-oriented Design, Analysis, and
  Programming, and 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

5
TinyOS Hardware Abstraction Architecture (HAA)

• Section 2.3 and Figure 2.5 of J. Polastre
  Dissertation http//www.polastre.com/papers/polas
  tre-thesis-final.pdf

6
TinyOS Hardware Abstraction Architecture (HAA)
Ref Figure 2.4 of J. Polastre Dissertation
http//www.polastre.com/papers/polastre-thesis-fin
al.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.

8
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 exception
Function 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
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)

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
Typical WSN Application
processing data acquisition communication

• 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

Power
wakeup
sleep
Time
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
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 listenreceivesend 11.051.4

17
TinyOS Radio Stack
18
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.n
  et/index.php/Modules_and_the_TinyOS_Execution_Mode
  l

• 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 CC2420s memory
• The software stack sends a packet by writing it
  to CC2420s 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
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_Tutorials

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
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
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
Timer Stack on MicaZ/Mica2
49
Timer Subsystem

• HplTimer0-3C 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)

58
Structure of a Component
Command Handlers
Set of Tasks
Event Handlers
Frame (containing state information)
TinyOS Component
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

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
Class Project

• Group project
• Goal
• develop a multi-hop data collection tree protocol
  for WSNs
• Use the developed tree to collect light intensity
  information in Lab 209
• Collaboration is important