TinyOS Tutorial CS580S Sensor Networks and Systems February 7, 2007 Jisu Oh Dept. of Computer Science SUNY-Binghamton

TinyOS Program Architecture NesC application: interfaces and components Concurrency Model: Two-level scheduling Component Development TinyOS installation Configuration file vs. Module file Running TinyOS code TOSSIM PowerTossim Outline TinyOS Program Architecture NesC application: interfaces and components Concurrency Model: Two-level scheduling

NesC application = components with well-defined, bidirectional interfaces Concurrency Model Two-level scheduling TinyOS Program Architecture

Interfaces /opt/tinyos-1.x/tos/interfaces The only point of access to the component Bi-directional Declare a set of functions command Provided by a component, these provide functionality into that component Invoked by a component wired to it the interface provider must implement event A “happening” that is produced by a component and that can be responded to by any components wired to this component the interface user must implement

Interface Timer /opt/tinyos-1.x/tos/interfaces/Timer.nc interface Timer{ command result_t start (char type, uint32_t interval); command result_t stop (); event result_t fired (); }

Configurations  wiring Assemble other components together Connecting interfaces used by components to interfaces provided by others Example: TimerC.nc Components configuration TimerC{ provides interface Timer[uint8_t id]; provides interface StdControl; } implementation{ components TimerM, ClockC; TimerM.Clock → ClockC; Timer = TimerM; }

Modules Provide application code Implement one or more interface Example CC1000RadioIntM.nc Components module CC1000RadioIntM{ provides interface StdControl; uses interface StdControl as TimerControl; uses interface Timer as WakeupTimer; } implementation{ task void PacketSent(){} command result_t StdControl.init(){} event result_t WakeupTimer.fired(){} }

Mica2 CC1000 Radio Stack Architecture

Provider, User and Interface configuration TimerC{ provides interface Timer[uint8_t id]; provides interface StdControl; } interface Timer{ command result_t start(char type, uint32_t interval); command result_t stop(); event result_t fired(); } module CC1000RadioIntM{ uses interface StdControl as TimerControl; uses interface Timer as WakeupTimer; } TimerC Provider TimerControl WakeupTimer CC1000RadioIntM User StdControl Timer Interface

Interfaces Verbs or nouns In mixed case with the first letter of each internal word capitalized ex) ADC, Range, SendMsg Components Nouns In mixed case with the first letter of each internal word capitalized ex) Counter, TimerC, TimerM Files “.nc” as a suffix ex) ADC.nc, TimerC.nc Naming Conventions

Two-level scheduling Hardware event handlers Call commands, post tasks, and signal other events Preempt tasks Preempted by asynchronous hardware event handlers (events and commands) Tasks computations Concurrency Model Hardware Interrupts events commands FIFO Tasks POST Preempt Time commands Hardware Event handler Tasks

Scheduling priority summary Hardware event, async events and async command Events and commands Tasks Concurrency Model (cont.) Low High Hardware Interrupts events commands FIFO Tasks POST Preempt Time commands

Two-level scheduling Hardware interrupt 1 command 1 Time Hardware interrupt 2 FIFO Post Task 2 Post Task 1 … command 2 event 4 event 1 event 2 event 3 event 5 Preempt Task 1

TinyOS Program Architecture NesC application: interfaces and components Concurrency Model: Two-level scheduling Component Development TinyOS installation Configuration file: wiring Module file: application code Running TinyOS code TOSSIM PowerTossim Next

Install TinyOS Not TinyOS or TinyOS 2.0 Upgrade your Cygwin Cygwin distributed with TinyOS is not compatible with TinyOS or above version Upgrade nesc version >= Reboot your computer Upgrade to TinyOS CVS Snapshots to use PowerTossim Check your installation Link to installation instruction TinyOS installation for windows

An example application: Blink /opt/tinyos-1.x/apps/Blink Configuration file – Blink.nc a top-level configuration file specify how and to which other components this particular component is wired to allow the component to “provide” various interfaces to other components (that can wire to it) or “use” interfaces Module file – BlinkM.nc the actual implementation of the component itself deal with event handling, command implementation, task posting, etc. Wireing! Application code!

A component graph of Blink application

Blink.nc – A frame of Configuration files configuration Blink { } implementation { } provide interfaces use interfaces components // wiring Indicate that this is a configuration file Interfaces which this configuration provides or uses A list of components which this configuration references Connecting components

Blink.nc – in detail components Main, BlinkM, SingleTimer, LedsC; // wiring Main.StdControl → BlinkM.StdControl; Main.StdControl → SingleTimer.StdControl; BlinkM.Timer → SingleTimer.Timer; BlinkM.Leds → LedsC; configuration Blink { } implementation { } //provides interfaces //uses interfaces No interfaces are provided or used by Blink.nc BIND interfacesimplementation Component.interface

Blink.nc – Main and StdControl A component “Main” Executed first in a TinyOS application A TinyOS application must have Main component in its configuration An interface “StdControl” Used to initialize and start TinyOS components /opt/tinyos-1.x/tos/interfaces/StdControl.nc interface StdControl { command result_t init(); command result_t start(); command result_t stop(); }

BlinkM.nc – A frame of Module files module BlinkM { } implementation { } Indicate that this is a module file provides interfaces uses interfaces Interfaces which this module provides or uses Application code // implementation of commands, //events or any tasks if needed

BlinkM.nc – inside of Module part module BlinkM { } provides interface StdControl ; uses interface Timer ; uses interface Leds ; interface StdControl { command result_t init(); command result_t start(); command result_t stop(); } interface Timer { command result_t start(char type, uint32_t, interval); command result_t stop(); event result_t fired(); } interface Leds { async command result_t init(); async command result_t redOn(); // and more commands } Implementation needed

BlinkM.nc – inside of Module (cont.) implementation { command result_t StdControl.init() { call Leds.init(); return SUCCESS; } command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000); } command result_t StdControl.stop() { return call Timer.stop(); } event result_t Timer.fired() { call Leds.yellowToggle(); return SUCCESS; }

Message Communication Example A component “MsgComm” A example application which shows a message communication in TinyOS

MsgComm //Message id for this application enum{ AM_MYMSG = 10 }; //Data structure for TOS_Msg.data Typedef struct MsgCommMsg{ uint16_t src; //source address uint16_t reading; //sensor reading }__attribute__((packed)) MsgCommMsg; MsgComm.h MsgComm.nc Includes MsgComm; configuration MsgComm { } Implementation{ components Main, MsgCommM, TimerC, Photo, GenericComm as Comm; Main.StdControl → MsgCommM.StdControl; Main.StdControl → TimerC; Main.StdControl → Photo; Main.StdControl → Comm; MsgCommM.ADC → Photo; MsgCommM.Timer → TimerC.Timer[unique (“Timer”)]; MsgCommM.SendMsg → Comm.SendMsg[AM_MYMSG]; MsgCommM.ReceiveMsg → Comm.ReceiveMsg[AM_MYMSG]; }

MsgComm (cont.) MsgCommM.nc (1) Includes MsgComm; module MsgCommM { provides interface StdControl; uses interface SendMsg; uses interface ReceiveMsg; uses interface ADC; uses interface Timer; } implementation { bool ch_busy; TOS_Msg tos_msg_buf; MsgCommMsg* send_buf; MsgCommMsg msg_buf; command result_t StdControl.init() { atomic ch_busy = FALSE; return SUCCESS; } // end of StdContro.init() command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000); } // end of StdControl.start() command result_t StdControl.stop() { return call Timer.stop(); }//end of StdControl.stop() event result_t Timer.fired() { call ADC.getData(); return SUCCESS; } // end of Timer.fired()

task void sendData() { atomic { if(!ch_busy) { send_buf = (MsgCommMsg*)tos_msg_buf.data; send_buf->src = msg_buf.src; send_buf->reading = msg_buf.reading; if((call SendMsg.send(TOS_BCAST_ADDR, sizeof(MsgCommMsg), &tos_msg_buf)) != SUCCESS) ch_busy = FALSE; else { dbg(DBG_USR1, “Sending at node [%d]: src[%d], data[%d]\n”, TOS_LOCAL_ADDRESS, send_buf->src, send_buf->reading); } } //end of if to check channel busy } //end of atomic } //end of task sendData() async event result_t ADC.dataReady(uint16_t data) { atomic msg_buf.src = TOS_LOCAL_ADDRESS; atomic msg_buf.reading = data; post sendData(); return SUCCESS; }// end of ADC.dataReady() MsgComm (cont.) MsgCommM.nc (2)

MsgComm (cont.) event result_t SendMsg.sendDone(TOS_MsgPtr msg, result_t success) { atomic ch_busy = FALSE; return SUCCESS; } //end of SendMsg.sendDone() event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m) { MsgCommMsg* data_buf = (MsgCommMsg*)m->data; dbg(DBG_USR1, “Receiving from [%d] with data [%d]\n”, data_buf->src, data_buf->reading); atomic msg_buf.src = data_buf->src; atomic msg_buf.reading = data_buf->reading; post sendData(); return m; }// end of ReceiveMsg.receive() } // end of implementation MsgCommM.nc (3)

Multihop Routing in TinyOS Uses a shortest-path-first algorithm with a single destination node (the root) and active two-way link estimation MultiHopEngineM: the overall packet movement logic for multi-hop functionality (determines the next-hop path) MultiHopLEPSM the Link Estimation and Parent Selection(LEPS) mechanisms You can import your own link estimation and parent selection mechanism instead of using this module Works on real motes, not on TOSSIM MultiHopRouter: connects above two components Reference: 1.x/doc/multihop/multihop_routing.htmlhttp:// 1.x/doc/multihop/multihop_routing.html Multihop component : /opt/tinyos-1.x/lib/Route example application: Surge /opt/tinyos-1.x/apps/Surge

TinyOS Program Architecture NesC application: interfaces and components Concurrency Model: Two-level scheduling Component Development TinyOS installation Configuration file: wiring Module file: application code Running TinyOS code TOSSIM PowerTossim Next

Running on a PC: TOSSIM Why simulation? Sensor networks are new, event-driven, large, deployed in remote locations Simulation provides: controlled, reproducible testing environment means to explore and improve design space TOSSIM P. Levis, N. Lee, M. Welsh, and D. Culler, TOSSIM: Accurate and Scalable Simulation of Entire TinyOS Applications, ACM Conference on Embedded Networked Sensor Systems (SenSys), November 2003.TOSSIM: Accurate and Scalable Simulation of Entire TinyOS Applications,

Running on a PC: TOSSIM (cont.) TOSSIM TinyOS mote simulator Scales to thousands of nodes Compiles directly from TinyOS source Simulates network at bit level Replaces hardware with software components Hardware interrupts are modeled as simulator events Manual: /opt/tinyos-1.x/doc/nido.pdf

TOSSIM Architecture

Generate Makefile component name include../Makerules optional flags Compile and Run Change directory where your application is stored cd /opt/tinyos-1.x/apps/Blink Compile the application for use in TOSSIM simulation on the host pc make pc Enable debugging mode export DBG=usr1 Run an executable file./bulid/pc/main.exe [option] N Where N is the number of nodes in the simulation How to use TOSSIM? # Makefile for Blink COMPONENT=Blink # PFLAGS = -I%T/lib/Counters Include../Makerules

dbg Configuration of debugging output at run-time Example debugging statement dbg(DBG_BOOT, “AM Module initialized\n”); Available DBG_[mode] all, boot, clock, task, sched, sensor, led, crypto, route, am, crc, packet, encode, radio, logger, etc. usr1, usr2, usr3 user output mode 1,2,3 reserved for application components Debugging: dbg

Sensor network power limited, hard to reach locations (ex, battlefield), difficult and expensive to replace batteries  Need to simulate energy usage before deployment PowerTossim a power modeling extension to TOSSIM developed by Harvard University Models power consumed by TinyOS applications Integrated into TOSSIM in the TinyOS or above PowerTossim references PowerTossim

Enable power mode for dbg export DBG=power Run your application with the –p flag and save the output to a file./build/pc/main.exe –t=60 –p 2 > out.trace Run postprocess.py on the resulting trace $TOSROOT/tools/scripts/PowerTOSSIM/postprocess.py –sb=0 –em $TOSROOT/tools/scripts/PowerTOSSIM/mica2_energy_mo del.txt out.trace Then PowerTossim (cont.)

You will see PowerTossim (cont.)

Download MsgComm.tgz, upzip and compile it Let’s run MsgComm!

Run! Let’s run MsgComm! (cont.) ↙ Turn on DBG mode USR1 and POWER ← Compile on the PC ↙ Run with 10 motes for 60 seconds and save it into a file ↖ Get a power consumption summary by using PowerTOSSIM

10output.trace Let’s run MsgComm! (cont.) From DBG_POWER From DBG_USR1

10output.power Let’s run MsgComm! (cont.) Consumed energy summary for mote 0

TinyOS official Website: TinyOS Documentation Tutorial NesC Tossim PowerTossim Sample applications In tinyos directory, /opt/tinyos-1.x/apps TinyOS CVS repository Useful URL

Questions?

THANK YOU!