TinyOS

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
 Prerequisites
• Module 1
• Basic concepts of Operating Systems
• Basic concepts of Object-oriented Design and
Analysis
• Basic concepts of Computer Networks
 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 4
 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 5
 TinyOS Hardware Abstraction
Architecture (HAA)

Ref: Figure 2.4 of J. Polastre Dissertation

http://www.polastre.com/papers/polastre-thesis-final.pdf
 Traditional OS Architectures
Application 1 Application 2 Application 1 NFS I/O

Monolith-kernel Micro-kernel

VM I/O Scheduler IPC Scheduler VM

HW HW

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.
 TinyOS Architecture Overview (1)
Scheduler TinyOS

Application Application Application

Component Component Component

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.

 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
 TinyOS Component Model

• Component has: Messaging Component

– Frame (storage) Internal State
Internal Tasks

– Tasks: computation
– Interface:
• Command
Commands Events
• Event

• Frame: static storage model - compile time

memory allocation (efficiency)
• Command and events are function calls
(efficiency) [TinyOS_4] 10
 Typical WSN Application
• Periodic processing
data acquisition
– Data Collection
communication
– Network Maintenance
– Majority of operation
• Triggered Events
– Detection/Notification
– Infrequently occurs
• But… must be reported

Power
quickly and reliably
• Long Lifetime
– Months to Years without
changing batteries sleep
– Power management is the key
to WSN success
Time

The mote revolution: Low Powr 12

Wireless Sensor Network
 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 13

Wireless Sensor Network
 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 14

Wireless Sensor Network
Power Consumption
 Energy Consumption
• Idle listen:receive:send = 1:1.05:1.4
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.
 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”
 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
 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”
 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
 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”
 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”
 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”
 Scheduler in TinyOS 2.x

SchedulerBasicP.nc of TinyOS 2.x

 TinyOS Serial Stack

• Ref: P. Levis, et al. “T2: A Second Generation OS For Embedded Sensor

Networks”
 Device Drivers in T2

• Virtualized
• Dedicated
• Shared

• Ref: Section 3 of [Energy_1]

 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
 One Example TinyOS Application -
BlinkC
• http://docs.tinyos.net/index.php/TinyOS_Tutor
ials
 One Example of Wiring

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

 AppM

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

 AppM

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

 Sensor Interface

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

 Initialize Interface

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

 SensorC

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

 AppC

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

Notation
CTP Routing Stack
 Parameterized Interfaces
• An interface array

•Ref: D. Gay, et al. “Software Design Patterns for TinyOS”, Section 2.3
 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
 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 44

manual"
 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)
 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
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
 message_t
• tos/types/message.h
• Ref. TEP 111
• Every link layer defines its header, footer, and
metadata structures
 Relationship between CC1000 Radio
Implementation and message_t
• tos/chips/cc1000/CC1000Msg.h
 Relationship between CC2420 Radio
Implementation and message_t
• tos/chips/cc2420/CC2420.h
 Relationship between Serial Stack
Packet Implementation and message_t
• tinyos-2.x/tos/lib/serial/Serial.h
 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
 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!!!!!!!
 TinyOS Component
• Two types of components
– Module: provide implementations of one or more
interfaces
– Configuration: assemble other components
together
 TinyOS Component Model

• Component has:
Messaging Component
– Frame (storage)
Internal Tasks Internal State
– Tasks: computation
– Interface:
• Command
• Event
Commands Events

• Frame: static storage model - compile time

memory allocation (efficiency)
• Command and events are function calls
(efficiency)
Structure of a Component

Command Handlers Set of Tasks

Event Handlers Frame

(containing state information)

TinyOS Component
 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

Preempt Tasks
POST FIFO
events

commands

commands

Interrupts
Time
Hardware
 TinyOS Applications
• In most mote applications, execution is driven
solely by timer events and the arrival of radio
messages
How to Program motes Under TinyOS
• make telosb install,n mib510,/dev/ttyUSB0
• make telosb install,1 mib510,/dev/ttyUSB0
 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
Application Example - BaseStation,
Listen and BlinkToRadio
UHCL Lamar

Terminal 1 of PC A# java
Terminal 1 of PC B# java net.tinyos.tools.Listen -comm
Run
net.tinyos.tools.Listen -comm serial@/dev/ttyUSB1:micaz
BlinkToRadio
[email protected]:9002 Option 1: Listen connects to local MTS300
serial ports + MicaZ
Option 3: Listen connects to
remote SerialForwarder Internet
MIB520
+ MicaZ Run
BaseStation
PC A at Lamar Univ. with IP
PC B at UHCL 140.158.130.239

Terminal 2 of PC A# java
Terminal 2 of PC B# java
net.tinyos.sf.SerialForwarder -comm serial@/
net.tinyos.sf.SerialForwarder -comm
dev/ttyUSB1:micaz
[email protected]:9002
Terminal 3 of PC A# java
Terminal 3 of PC B# java
net.tinyos.tools.Listen -comm
net.tinyos.tools.Listen -comm
sf@localhost:9002
sf@localhost:9002
Option 4: One local SerialForwarder connects Option 2: Listen connects to SerialForwarder
to a remote SerialForwarder. Listen connects running on a local machine
to local SerialForwarder
Application Example - Oscilloscope
UHCL Lamar
Terminal 1 of PC A# export
MOTECOM=serial@/dev/
ttyUSB1:micaz
Terminal 1 of PC B# java Run
Terminal 1 of PC A# oscillloscope/
net.tinyos.tools.Listen -comm OscilloscopeC.nc
java/run
[email protected]:9002 MTS300
Option 1: Oscilloscope connects to + MicaZ
Option 3: Listen connects to local serial ports
remote SerialForwarder Internet
MIB520
+ MicaZ Run
BaseStation
PC A at Lamar Univ. with IP
PC B at UHCL 140.158.130.239

Terminal 2 of PC A# java
Terminal 3 of PC B# export net.tinyos.sf.SerialForwarder -comm serial@/
[email protected]:9002 dev/ttyUSB1:micaz
Terminal 3 of PC B# oscilloscope/java/run
Terminal 3 of PC A# export
Option 4: oscilloscope connects to remote MOTECOM=sf@localhost:9002
SerialForwarder Terminal 3 of PC A# oscilloscope/java/run

Option 2: Oscilloscope connects to

SerialForwarder running on a local machine

Add SENSORBOARD=mts300 in Makefile

 Application Example -
MultihopOscilloscope
GUI Interface
Terminal 1 of PC# java MTS300
net.tinyos.sf.SerialForwarder - Run
+ MicaZ
comm serial@/dev/ttyUSB1:micaz MultihopOscilloscopeC.nc
Run
MTS300 MultihopOscilloscopeC.nc
Terminal 2 of PC#
MultihopOscilloscope/java/run
+ MicaZ
Run
MIB520 MultihopOscilloscopeC.nc
+ MicaZ
Text Interface
Terminal 3 of PC# java MTS300
net.tinyos.tools.Listen -comm MTS300
+ MicaZ
serial@/dev/ttyUSB1:micaz + MicaZ
Run
Run
MultihopOscilloscopeC.nc
MultihopOscilloscopeC.nc
1. Add SENSORBOARD=mts300 when compile
2. Based on MultihopOscilloscopeC.nc, the root id should be 0
2.a For root node: make micaz install,0 mib510,/dev/ttyUSB0
2.b For non-root node (e.g. node 1): make micaz install,1 mib510,/dev/ttyUSB0
3. chmod 666 /dev/USB*
4. Make sure the root node and non-root nodes are all running
5. How to configurate light, temperature sensors? Modify:
5.a $TOSROOT/tos/platforms/micaz/DemoSensorC.nc
5.b $TOSROOT/tos/sensorboards/mts300/DemoSensorC.nc
5.c $TOSROOT/apps/MultihopOscilloscope/MultihopOscilloscopeAppC.nc
 Application Example - MViz
Terminal 1 of PC A#java
UHCL net.tinyos.sf.SerialForwarder -comm Lamar
serial@/dev/ttyUSB1:micaz
MTS300
Terminal 2 of PC A#tos-mviz -comm + MicaZ
sf@localhost:9002 -dir /opt/tinyos-2.x/ Run MViz
apps/MViz MVizMsg MTS300
PC B at UHCL
Run MViz + MicaZ
Run MViz
MIB520
+ MicaZ
Internet
MTS300
PC A with IP:
Terminal 1 of PC B#tos-mviz -comm + MicaZ MTS300
140.158.130.239
[email protected]:9002 -dir /opt/ + MicaZ
tinyos-2.x/apps/Mviz MVizMsg Run MViz
1. Add SENSORBOARD=mts300 when compile Run MViz
Terminal 2 of PC B#java
net.tinyos.tools.Listen -comm 2. Modify MVizSensorC.nc to add related sensors
[email protected]:9002 3. Based on MultihopOscilloscopeC.nc, the root id should be 0
3.a For root node: make micaz install,0 mib510,/dev/ttyUSB0
3.b For non-root node (e.g. node 1): make micaz install,1
mib510,/dev/ttyUSB0
4. chmod 666 /dev/ttyUSB*
5. add CFLAGS += -DCC2420_DEF_RFPOWER=3 in Makefile to
change transmission power
6. How to configurate light, temperature sensors? Modify:
6.a $TOSROOT/tos/platforms/micaz/DemoSensorC.nc
6.b $TOSROOT/tos/sensorboards/mts300/DemoSensorC.nc
6.c $TOSROOT/apps/Mviz/MVizSensorC.nc
 MViz

University of Houston, Lamar University TelosB

Clear Lake
Run MViz
TelosB
Run MViz
Run MViz
TelosB
Internet
PC A with IP: TelosB
140.158.130.239 TelosB
Run MViz
Run MViz
 Application Example - Octopus
Terminal 1 of PC# java net.tinyos.sf.SerialForwarder
-comm serial@/dev/ttyUSB1:micaz

Terminal 2 of PC# export MOTECOM=serial@/dev/

ttyUSB1:micaz
Data MTS300
Terminal 2 of PC# java OctopusGui Collection + MicaZ
Run Octopus
Data MTS300
Collection Data
Run + MicaZ Dissemination
Octopus
Data Run Octopus
MIB520 +
Dissemination
MicaZ
Data
Data Collection
Data Data
Collection Dissemination MTS300 Collection
Data + MicaZ MTS300
Dissemination Run Octopus
Data + MicaZ
Dissemination Run Octopus

• http://csserver.ucd.ie/~rjurdak/Octopus.htm
 Octopus

Data
TelosB
Collection
Run Octopus
Data
Collection TelosB Data
Run Dissemination
Octopus
Data Run Octopus
TelosB Dissemination
Data
Data Collection
Data Data
Collection Dissemination Collection
TelosB
Data
Dissemination Run Octopus
Data TelosB
Dissemination Run Octopus
 BaseStation – Listen - BlinkToRadio

Run BaseStation
run java net.tinyos.tools.Listen -
comm serial@/dev/ttyUSB0:telosb
TelosB
Mote

TelosB Run BlinkToRadio

Mote
 OscilloScope

GUI Interface
1. run java net.tinyos.sf.SerialForwarder - Run BaseStation
comm serial@/dev/ttyUSB0:telosb
2. Under Oscilloscope/java, run ./run TelosB
Mote
Run
OscilloscopeC.nc
TelosB
Text Interface Mote
1. run java net.tinyos.tools.Listen -
comm serial@/dev/ttyUSB0:telosb TelosB
Mote
Run
OscilloscopeC.nc
 MultihopOscilloscope

GUI Interface
Run TelosB
MultihopOscilloscopeC.nc Run
1. run java net.tinyos.sf.SerialForwarder -comm
serial@/dev/ttyUSB0:telosb MultihopOscilloscopeC.nc
2. Under MultihopOscilloscope/java, run ./run TelosB

Run
MultihopOscilloscopeC.nc
TelosB
Text Interface
1. run java net.tinyos.tools.Listen -
comm serial@/dev/ttyUSB0:telosb
TelosB
TelosB
Run
Run
MultihopOscilloscopeC.nc
MultihopOscilloscopeC.nc
 MViz
1. run java
net.tinyos.sf.SerialForwarder
-comm serial@/dev/
UHCL ttyUSB0:telosb Lamar Univ.
2. run tos-mviz -comm
sf@localhost:9002 -dir /opt/ TelosB
tinyos-2.x/apps/MViz Run MViz
MVizMsg TelosB Run MViz
Machine in UHCL TelosB

Run MViz
TelosB
Internet
run tos-mviz -comm
IP: 140.158.130.239 TelosB
[email protected]:9002 -dir /opt/ TelosB
tinyos-2.x/apps/Mviz MVizMsg
Run MViz
Run MViz
 Octopus
1. run java
net.tinyos.sf.SerialForwarder
-comm serial@/dev/
ttyUSB0:telosb
Lamar Univ.
2. run

2.a export TelosB

MOTECOM=serial@/dev/ Run Octopus
ttyUSB0:telosb Run Octopus
TelosB
2.b java OctopusGui
Run Octopus
TelosB

IP: 140.158.130.239 TelosB

TelosB

Run Octopus Run

Octopus
 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.
 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.
 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.
 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?