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

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

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 2

Application 1

I/O

I/O

Micro-kernel

Monolith-kernel

VM

NFS

Application 1

Scheduler

IPC

HW

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

VM

TinyOS Architecture Overview (1)

Scheduler
Application
Component
I/O

Application
Component
COMM .

TinyOS

Application
Component
.

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

Communication
Sensing
Communication

Hardware Abstractions

TinyOS Component Model

Component has:
Frame (storage)
Tasks: computation
Interface:
Command
Event

Messaging Component
Internal Tasks

Commands

Internal State

Events

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
communication

Data Collection
Network Maintenance
Majority of operation

Triggered Events
But must be reported
quickly and reliably

Long Lifetime
Months to Years without
changing batteries
Power management is the key
to WSN success

Power

Detection/Notification
Infrequently occurs

sleep

The mote revolution: Low Powr

Wireless Sensor Network

Time
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

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

14

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

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

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)

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:
Frame (storage)
Tasks: computation
Interface:
Command
Event

Messaging Component
Internal Tasks

Commands

Frame: static storage model - compile time

memory allocation (efficiency)
Command and events are function calls
(efficiency)

Internal State

Events

Structure of a Component

Command Handlers

Event Handlers

Set of Tasks

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
Tasks

Preempt

events

POST

FIFO

commands
commands
Interrupts

Hardware

Time

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
Lamar

UHCL

Terminal 1 of PC B# java
net.tinyos.tools.Listen -comm
sf@140.158.130.239:9002
Option 3: Listen connects to
remote SerialForwarder

PC B at UHCL
Terminal 2 of PC B# java
net.tinyos.sf.SerialForwarder -comm
sf@140.158.130.239:9002
Terminal 3 of PC B# java
net.tinyos.tools.Listen -comm
sf@localhost:9002
Option 4: One local SerialForwarder connects
to a remote SerialForwarder. Listen connects
to local SerialForwarder

Terminal 1 of PC A# java
net.tinyos.tools.Listen -comm
serial@/dev/ttyUSB1:micaz

Run
BlinkToRadio
MTS300
Option 1: Listen connects to local
+ MicaZ
serial ports
Internet
MIB520
+ MicaZ Run
BaseStation
PC A at Lamar Univ. with IP
140.158.130.239
Terminal 2 of PC A# java
net.tinyos.sf.SerialForwarder -comm serial@/
dev/ttyUSB1:micaz
Terminal 3 of PC A# java
net.tinyos.tools.Listen -comm
sf@localhost:9002
Option 2: Listen connects to SerialForwarder
running on a local machine

Application Example - Oscilloscope

Lamar

UHCL

Terminal 1 of PC B# java
net.tinyos.tools.Listen -comm
sf@140.158.130.239:9002
Option 3: Listen connects to
remote SerialForwarder

PC B at UHCL

Terminal 3 of PC B# export
MOTECOM=sf@140.158.130.239:9002
Terminal 3 of PC B# oscilloscope/java/run
Option 4: oscilloscope connects to remote
SerialForwarder

Terminal 1 of PC A# export
MOTECOM=serial@/dev/
ttyUSB1:micaz
Terminal 1 of PC A# oscillloscope/
java/run

Run
OscilloscopeC.nc

MTS300
Option 1: Oscilloscope connects to
+ MicaZ
local serial ports
Internet
MIB520
+ MicaZ Run
BaseStation
PC A at Lamar Univ. with IP
140.158.130.239
Terminal 2 of PC A# java
net.tinyos.sf.SerialForwarder -comm serial@/
dev/ttyUSB1:micaz
Terminal 3 of PC A# export
MOTECOM=sf@localhost:9002
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
Run
net.tinyos.sf.SerialForwarder comm serial@/dev/ttyUSB1:micaz MultihopOscilloscopeC.nc

MTS300
+ MicaZ

Terminal 2 of PC#
MultihopOscilloscope/java/run

Text Interface
Terminal 3 of PC# java
net.tinyos.tools.Listen -comm
serial@/dev/ttyUSB1:micaz

MIB520
+ MicaZ

MTS300
+ MicaZ
Run
MultihopOscilloscopeC.nc

Run
MultihopOscilloscopeC.nc

MTS300
+ MicaZ
Run
MultihopOscilloscopeC.nc

MTS300
+ MicaZ
Run
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

UHCL

Terminal 1 of PC A#java
net.tinyos.sf.SerialForwarder -comm
serial@/dev/ttyUSB1:micaz

Lamar

Terminal 2 of PC A#tos-mviz -comm

sf@localhost:9002 -dir /opt/tinyos-2.x/
apps/MViz MVizMsg
PC B at UHCL

Run MViz

Internet
Terminal 1 of PC B#tos-mviz -comm
sf@140.158.130.239:9002 -dir /opt/
tinyos-2.x/apps/Mviz MVizMsg
Terminal 2 of PC B#java
net.tinyos.tools.Listen -comm
sf@140.158.130.239:9002

MTS300
+ MicaZ
Run MViz

MTS300
+ MicaZ
Run MViz

MIB520
+ MicaZ
PC A with IP:
140.158.130.239

MTS300
+ MicaZ

MTS300
+ MicaZ

Run MViz
Run MViz
1. Add SENSORBOARD=mts300 when compile
2. Modify MVizSensorC.nc to add related sensors
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
Lamar University

University of Houston,
Clear Lake

TelosB
Run MViz

Run MViz

TelosB
Run MViz

TelosB

Internet
PC A with IP:
140.158.130.239

TelosB
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
Collection

Terminal 2 of PC# java OctopusGui

Data
Collection

Run
Octopus

MIB520 +
MicaZ
Data
Collection
Data
Dissemination

Data
Dissemination

MTS300
+ MicaZ

MTS300
+ MicaZ

Run Octopus
Data
Dissemination

Data Run Octopus

Dissemination
Data
Collection

MTS300
+ MicaZ

Run Octopus

Data
Collection

Data
Dissemination

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

MTS300
+ MicaZ
Run Octopus

Octopus
Data
Collection
Data
Collection

Run
Octopus

TelosB
Data
Collection
Data
Dissemination

Data
Dissemination

TelosB

TelosB

Run Octopus
Data
Dissemination

Data Run Octopus

Dissemination
Data
Collection

TelosB

Run Octopus

Data
Collection

Data
Dissemination

TelosB
Run Octopus

BaseStation Listen - BlinkToRadio

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

Run BlinkToRadio

OscilloScope
GUI Interface
1. run java net.tinyos.sf.SerialForwarder comm serial@/dev/ttyUSB0:telosb
2. Under Oscilloscope/java, run ./run

Text Interface
1. run java net.tinyos.tools.Listen comm serial@/dev/ttyUSB0:telosb

Run BaseStation
TelosB
Mote

TelosB
Mote

Run
OscilloscopeC.nc

TelosB
Mote

Run
OscilloscopeC.nc

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

TelosB

Run
MultihopOscilloscopeC.nc

Run
MultihopOscilloscopeC.nc
TelosB

Run
MultihopOscilloscopeC.nc

Text Interface
1. run java net.tinyos.tools.Listen comm serial@/dev/ttyUSB0:telosb

TelosB

TelosB

Run
MultihopOscilloscopeC.nc

TelosB

Run
MultihopOscilloscopeC.nc

MViz
1. run java
net.tinyos.sf.SerialForwarder
-comm serial@/dev/
ttyUSB0:telosb

UHCL

2. run tos-mviz -comm

sf@localhost:9002 -dir /opt/
tinyos-2.x/apps/MViz
TelosB
MVizMsg

Lamar Univ.
TelosB

Run MViz
Run MViz

Machine in UHCL

TelosB

Run MViz
TelosB

Internet
run tos-mviz -comm
sf@140.158.130.239:9002 -dir /opt/
tinyos-2.x/apps/Mviz MVizMsg

IP: 140.158.130.239

TelosB

Run MViz

TelosB

Run MViz

Octopus
1. run java
net.tinyos.sf.SerialForwarder
-comm serial@/dev/
ttyUSB0:telosb

Lamar Univ.

2. run
2.a export
MOTECOM=serial@/dev/
ttyUSB0:telosb

TelosB

Run Octopus
Run Octopus
TelosB

2.b java OctopusGui

Run Octopus
TelosB

IP: 140.158.130.239

TelosB

Run Octopus

TelosB

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/tinyos2.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 doesnt TinyOS 2 make every
statement async?