Part 2TinyOS and nesC

Programming

Selected slides from:

Wireless Sensor NetworksHardware/Software

Tiny OS & NesC Programming

borrowed fromTurgay Korkmaz

What is TinyOS?• Operating system developed by UC Berkeley

• Open Source development environment

– System, library and applications written in nesC• nesC (network embedded system C) a component-based C

– Event-driven architecture

– Single shared stack

– NO kernel, process/memory management– Sleep as often as possible to save power

Programming Model• Basic concept behind nesC

• Separation of construction and composition

• Programs are built out of components

Components

• A component is a black box specified by interface(s)

• Interfaces define a set of logically related I/O functions called commands and events

• Components use and provide interfaces

• Components are statically wired together based on their interfaces

Timer Component

StdControl Timer

Clock

provides

uses

StdControl.nc

interface StdControl {

command result_t init();

command result_t start();

command result_t stop();

}

Clock.nc

interface Clock {

command result_t setRate( char

interval, char scale);

event result_t fire();

}

Components (cont’d)• A component–Processes Commands– Throws Events–Has a Frame for local state–Uses Tasks for concurrency

• Components must implement – the events they use and – the commands they provide

Can signalMust implementProvide

Must implementCan callUse

EventsCommandsComponent

Commands and Events• commands

– deposit request parameters into the frame

– are non-blocking

– need to return status

– postpone time consuming work by posting a task

– can call lower level commands

• events

– can call commands, signal events, post tasks

– can Not be signaled by commands

– preempt tasks, not vice-versa

– interrupt trigger the lowest level events

– deposit the information into the frame

{... status = call CmdName(args)...}

command CmdName(args) {...return status;}

{... status = signal EvtName(args)...}

event EvtName(args) {...return status;}

Component Hierarchy• Components are wired

together by connecting users with providers• Commands:

–Flow downwards

–Control returns to caller

• Events:

–Flow upwards

–Control returns to signaler

Types of Components

• There are two types of components:• Modules: provide code that implements one

or more interfaces and internal behavior

• Configurations: Wires/links components together to yield a new component

• A component does not care if another component is a module or configuration

• A component may be composed of other components

Component Syntax - module

module ForwarderM { provides { interface StdControl; } uses { interface StdControl as CommControl; interface ReceiveMsg; interface SendMsg; interface Leds; }}implementation {code implementing all

provided commands used events, andtasks

}

ForwarderM

StdControl ReceiveMsg

provides uses

CommControl

SendMsg

Leds

interface StdControl {command result_t init(); command result_t start(); command result_t stop();

}

interface SendMsg{ command result_t send(uint16_t address, uint8_t length, TOS_MsgPtr msg); event result_t sendDone(TOS_MsgPtr msg, result_t success);

}

Component implementation

module ForwarderM { //interface declaration}implementation { command result_t StdControl.init() { call CommControl.init(); call Leds.init(); return SUCCESS; } command result_t StdControl.start() {…} command result_t StdControl.stop() {…} event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m) { call Leds.yellowToggle(); call SendMsg.send(TOS_BCAST_ADDR, sizeof(IntMsg), m); return m; } event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool success) { call Leds.greenToggle(); return success; }}

Command imp. (interface provided)

Event imp. (interface used)

Component Syntax - Configurationconfiguration Forwarder { }implementation{ components Main, LedsC; components GenericComm as Comm; components ForwarderM;

Main.StdControl -> ForwarderM.StdControl; ForwarderM.CommControl -> Comm; ForwarderM.SendMsg -> Comm.SendMsg[AM_INTMSG]; ForwarderM.ReceiveMsg -> Comm.ReceiveMsg[AM_INTMSG]; ForwarderM.Leds -> LedsC;}

ComponentSelection

Wiring the Components together

ForwarderM

StdControl ReceiveMsg

provides uses

CommControl

SendMsg

Leds

Main StdControl

LedsCLeds

GenericCommSendMsg

ReceiveMsg

StdControlForwarder

Lab 3• The lab is done on the computer :

• csmisc19.cs.chalmers.se• To get a username and password:

• do an empty submission in Fire!• TinyOS with all sources for libraries and everything is

installed at /opt/tinyos-2.1.0• Unpack Rout.tar.gz into your home directory (at the server) and

do the assignment from there.• Compile the program by executing: make micaz sim• Run the simulation by executing: ./simulation.py <topology file>• Build topologies using buildtopo.py to get a grid and then

remove some nodes to get some interesting formation

Part 1 – improve the basic routing• Implement something better than the basic routing

algorithm. • The battery level is something that is known to a

node, so feel free to use that in your algorithm. • Report:

• Discuss the idea behind your algorithm.• Present results from comparing your algorithm to the

original algorithm.• Discuss failed improvements.

Part 2 – Clustered data aggregation• Aggregate information and send it to the sink.• Many nodes in an area send their information to a cluster head,

that do the summarization and then sends the aggregate message to the sink.

• A simple algorithm to choose cluster head: for every node with a certain probability announces itself to be a cluster head. • Choose the parameters you like: battery level of the node, battery level of

neighbors, etc.

• A cluster head should not store content for more than 1 round.• Report:

• Discuss the idea behind your algorithm.• Present results from comparing your algorithm to your

algorithm in part one.• Discuss failed improvements.