1 / 45

TinyOS Tutorial

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

lorand
Download Presentation

TinyOS Tutorial

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

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

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

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

  5. 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 (); }

  6. 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; }

  7. 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(){} }

  8. Mica2 CC1000 Radio Stack Architecture

  9. 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; }

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

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

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

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

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

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

  16. 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!

  17. A component graph of Blink application

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

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

  20. 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(); }

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

  22. 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 }

  23. 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; } }

  24. Message Communication Example • A component “MsgComm” • A example application which shows a message communication in TinyOS • http://bingweb.binghamton.edu/~joh3/CS580S/MsgComm.tgz

  25. 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]; }

  26. 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)

  27. 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)

  28. 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)

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

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

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

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

  33. TOSSIM Architecture

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

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

  36. 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/

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

  38. PowerTossim (cont.) • You will see

  39. Let’s run MsgComm! • http://bingweb.binghamton.edu/~joh3/CS580S • Download MsgComm.tgz, upzip and compile it

  40. ← 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!

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

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

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

  44. Questions?

  45. THANK YOU!

More Related