April 15, 2005TinyOS: A Component Based OSPage 1 of 27 TinyOS A Component-Based Operating System for Networked Embedded Systems Tom Bush Graduate College

April 15, 2005 TinyOS: A Component Based OS Page 1 of 27

TinyOS

A Component-Based Operating System for Networked Embedded Systems

Tom Bush

Graduate College of Union University

April 15, 2005 TinyOS: A Component Based OS Slide 2 of 27

Overview

Networked Embedded Systems Environment of TinyOS Implementation of TinyOS - nesC

Component model Concurrency model Compiler features

Basic Example Evaluation of nesC implementation


Networked Embedded Systems

What is a networked embedded system? An interacting group of devices with computing

components embedded in purpose built devices Usually perform single task such as monitoring

an environmental characteristic Connected through some type of network Usually not mobile, typically very small Little if any human interaction



How NESs are used Structural integrity of buildings,

bridges Monitor vehicle movements/traffic Monitor movements of animals Utilities data collection Military uses

Replace minefields Sniper detection



RF Mote Mica2

Golum DustweC

UCB Spec


Physical Constraints on NESs

Relatively slow processors Small amount of memory and storage Limited battery life Must be self contained Radio or other communication Asynchronous hardware triggers


What is the TinyOS?

An event-based operating system designed for wireless networked sensors

Uses component based architecture Supports concurrent operations required by

networked sensors Special purpose Single application (no multi-programming) Supports tasks (not threads)


TinyOS Environment

NES operating system must support Component based architecture Tasks and event-based concurrency Split-phase operations

Commands Events


Introducing nesC

A programming language for NESs An extension of C Static language, no dynamic memory

allocation Supports concept of components and

event-based concurrency model Whole program analysis & optimization


nesC Component Model

Two types of components Modules Configurations

Both types use and provide interfaces Only point of access to components Bi-directional; commands and events Detailed implementation provided by

components

Component A Component B


Interfaces

A collection of 1 or more command and events

Defines interaction boundary between components

Providing component must implement the start and stop commands

Using component must implement the fired event

interface Timer {command result_t start(

char type, uint32_t interval);

command result_t stop();

event result_t fired();}


Components

Configurations Wire other

components together

Connect interfaces used by one component to those provided by another

Top level application

Modules Provide application

code Implement one or

more interfaces


Example applicationTop Level Application

Component C

Component A

Component B

Component EComponent D

ProvidesUses


Component Implementations

configuration Blink {}implementation {

components Main, BlinkM, SingleTimer, LedsC;

Main.StdControl -> SingleTimer.StdControl; Main.StdControl -> BlinkM.StdControl; BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC;}


Component Implementationsmodule BlinkM {

provides interface StdControl;uses {

interface Timer;interface Leds;

}}implementation {

command result_t StdControl.init( ) {call Leds.init( );return SUCCESS;

}

command result_t stdControl.start[int id](char type, uint32_t interval) {

return call Timer.start(Timer_Repeat, 1000);}

command result_t StdControl.stop[int id]( ) {return call Timer.stop( );

}

event result_t Timer.fired( ) { call Leds.redToggle( ); return SUCCESS; }}


Concurrency Model

Two types of concurrency in TinyOS Tasks

Travel down application graph (to HW) Events (HW Interrupts)

Travel up application graph (away from HW)


Tasks

Delayed computations Posted by components

Calls are non-blocking Handled by event scheduler (FIFO) Run to completion Can be preempted Do not preempt


Events

Signify either completion of a command (split-phase

operation) Hardware interrupt (environmental trigger)

Run to completion Preempt tasks and other events Can call commands, post tasks, signal other

events


Event/Task Exampletask void HandleFire() {

uint8_t i; setIntervalFlag = 1;if (mState) {

for (i=0;i<NUM_TIMERS;i++) {if (mState&(0x1<<i)) {

mTimerList[i].ticksLeft -= (mInterval+1) ; if (mTimerList[i].ticksLeft<=2) {

if (mTimerList[i].type==TIMER_REPEAT) {mTimerList[i].ticksLeft += mTimerList[i].ticks;

} else {// one shot timer mState &=~(0x1<<i);

}enqueue(i);post signalOneTimer();

}}

}}adjustInterval();

}

async event result_t Clock.fire() {post HandleFire();return SUCCESS;

}


Concurrency Model

Asynchronous code (AC) – reachable from at least one interrupt handler

Synchronous code (SC) – code only reachable from tasks

To prevent race conditions Shared variables updated by SC only or in atomic code

Must implement “atomic” keyword to disable interrupts when processing SC

Keep atomic sections short to keep system reactive


Component Model Analysis

Application ModulesOS Modules

(% of full OS)

OS Modules (% of

application)Lines

OS Lines(% of

full OS)

OS Lines (% of

application)

Surge 31 27 (25%) 87% 2860 2160 (14%) 76%

Maté 35 28 (25%) 80% 4736 2524 (17%) 53%

TinyDB 65 38 (35%) 58% 11681 4160 (28%) 36%


Concurrency Model Analysis

nesC version 1.0 No race condition analysis No atomic function

nesC version 1.1 Added both 103 race conditions Fixed by tasking or atomic statements


Fixing race conditions

/* Contains a race: */

if (state == IDLE) { state = SENDING; count++; // send a packet

}

/* Fixed Version */

uint8_t oldState;atomic {

oldState = state;if (state == IDLE) {

state = SENDING;}

}

if (oldState == IDLE) {count++;// send a packet

}


Compiler Optimization

Uses component model restrictions: Eliminate unreachable code Inline small functions

ApplicationCode Size Code

ReductionInlined Noninlined

Surge 14794 16984 12%

Maté 25040 27458 9%

TinyDB 64910 71724 10%


Support FunctionsTinyOS Simulator

/*====== Core mote modes =============*/ DBG_BOOT = DBG_MODE(0), /* the boot sequence */ DBG_CLOCK = DBG_MODE(1), /* clock */ DBG_TASK = DBG_MODE(2), /* task stuff */ DBG_SCHED = DBG_MODE(3), /* switch, scheduling */ DBG_SENSOR = DBG_MODE(4), /* sensor readings */ DBG_LED = DBG_MODE(5), /* LEDs */ DBG_CRYPTO = DBG_MODE(6), /* Cryptography/security */

/*====== Networking modes ============*/ DBG_ROUTE = DBG_MODE(7), /* network routing */ DBG_AM = DBG_MODE(8), /* Active Messages */ DBG_CRC = DBG_MODE(9), /* packet CRC stuff */ DBG_PACKET = DBG_MODE(10), /* Packet level stuff */ DBG_ENCODE = DBG_MODE(11), /* Radio encoding/decoding */ DBG_RADIO = DBG_MODE(12), /* radio bits */


Conclusions

nesC implements TinyOS concurrency and component models effectively ↑

nesC also provides compile time optimizations and race condition detection ↑

Component swapping ↑ TOSSIM and TinyViz support functions ↑ Rapidly changing hardware ↓ Everyone knows C ↑


Conclusions

TinyOS provides great interface for distributed applications ↑

Not perfect for all applications ↓ 18 pages of code to blink 1 LED?

Documents

April 15, 2005TinyOS: A Component Based OSPage 1 of 27 TinyOS A Component-Based Operating System for Networked Embedded Systems Tom Bush Graduate College