450 likes | 484 Views
Explore TinyOS program architecture, NesC application concepts, and two-level scheduling in this informative tutorial from February 7, 2007, by Jisu Oh. Learn about interfaces, components, and concurrent models. Detailed examples and installation guidance provided.
E N D
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
http://www.tinyos.net/tinyos-1.x/doc/index.html 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 (); }
Components • Configurations wiring • Assemble other components together • Connecting interfaces used by components to interfaces provided by others • Example: TimerC.nc configuration TimerC{ provides interface Timer[uint8_t id]; provides interface StdControl; } implementation{ components TimerM, ClockC; TimerM.Clock → ClockC; Timer = TimerM; }
Components • Modules • Provide application code • Implement one or more interface • Example CC1000RadioIntM.nc moduleCC1000RadioIntM{ 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(){} }
CC1000RadioIntM User StdControl TimerC Provider TimerControl Interface Timer WakeupTimer Provider, User and Interface interfaceTimer{ command result_t start(char type, uint32_t interval); command result_t stop(); event result_t fired(); } configurationTimerC{ provides interface Timer[uint8_t id]; provides interface StdControl; } moduleCC1000RadioIntM{ uses interface StdControl as TimerControl; uses interface Timer as WakeupTimer; }
Naming Conventions • http://www.tinyos.net/tinyos-1.x/doc/tutorial/naming.html • 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
Tasks Tasks Preempt POST FIFO Hardware Event handler events commands commands Interrupts Time Hardware Concurrency Model • 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
Tasks Preempt POST FIFO events commands commands Interrupts Time Hardware Concurrency Model (cont.) High • Scheduling priority summary Hardware event, async events and async command Events and commands Tasks Low
event 4 command 2 Preempt Task 1 Post Task 2 Post Task 1 command 1 event 1 event 2 event 5 event 3 Hardware interrupt 1 Hardware interrupt 2 Two-level scheduling FIFO … Time
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
TinyOS installation for windows • Install TinyOS 1.1.0 • Not TinyOS 1.1.15 or TinyOS 2.0 • Upgrade your Cygwin • Cygwin distributed with TinyOS 1.1.0 is not compatible with TinyOS 1.1.11 or above version • Upgrade nesc version >= 1.1.1 • Reboot your computer • Upgrade to TinyOS 1.1.15 CVS Snapshots to use PowerTossim • Check your installation • Link to installation instruction http://bingweb.binghamton.edu/~joh3/CS580S/tinyos_installation.html
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!
configuration Blink { } implementation { } Blink.nc – A frame of Configuration files Indicate that this is a configuration file Interfaces which this configuration provides or uses provide interfaces use interfaces A list of components which this configuration references components // wiring Connecting components
configuration Blink { } No interfaces are provided or used by Blink.nc //provides interfaces //uses interfaces implementation { } BIND interfaces implementation 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; 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(); }
module BlinkM { } Interfaces which this module provides or uses provides interfaces uses interfaces Application code implementation { } // implementation of commands, //events or any tasks if needed BlinkM.nc – A frame of Module files Indicate that this is a module file
module BlinkM { } provides interface StdControl ; uses interface Timer ; uses interface Leds ; Implementation needed BlinkM.nc – inside of Module part 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 }
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 • http://bingweb.binghamton.edu/~joh3/CS580S/MsgComm.tgz
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.) 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() • MsgCommM.nc (1)
MsgComm (cont.) 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() • 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: http://www.tinyos.net/tinyos-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.
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
How to use TOSSIM? # Makefile for Blink COMPONENT=Blink # PFLAGS = -I%T/lib/Counters Include ../Makerules • 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
Debugging: dbg • 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
PowerTossim • 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 1.1.10 or above • PowerTossim references • http://www.eecs.harvard.edu/~shnayder/ptossim/
PowerTossim (cont.) • 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_model.txt out.trace • Then
PowerTossim (cont.) • You will see
Let’s run MsgComm! • http://bingweb.binghamton.edu/~joh3/CS580S • Download MsgComm.tgz, upzip and compile it
← Compile on the PC ↙Turn on DBG mode USR1 and POWER ↙Run with 10 motes for 60 seconds and save it into a file ↖Get a power consumption summary by using PowerTOSSIM Let’s run MsgComm! (cont.) • Run!
From DBG_POWER From DBG_USR1 Let’s run MsgComm! (cont.) • 10output.trace
Consumed energy summary for mote 0 Let’s run MsgComm! (cont.) • 10output.power
Useful URL • TinyOS official Website: http://www.tinyos.net • TinyOS Documentation • http://www.tinyos.net/tinyos-1.x/doc/index.thml • Tutorial • http://www.tinyos.net/tinyos-1.x/tutorial/index.html • NesC • http://www.tinyos.net/tinyos-1.x/doc/nesc/ref.pdf • Tossim • http://www.tinyos.net/tinyos-1.x/doc/nido.pdf • PowerTossim • http://www.eecs.harvard.edu/~shnayder/ptossim/install.html • Sample applications • In tinyos directory, /opt/tinyos-1.x/apps • TinyOS CVS repository • http://sourceforge.net/cvs/?group_id=28656