Programming Motes

Programming Motes A TinyOS and TOSSIM Tutorial By: Brent Rood

The monsters: Programming Board MICA2 MOTE

TinyOS Overview • Operating system developed at UC Berkeley for use with sensor motes • Support sensor motes and ease development of sensor applications • Event-driven architecture • Utilizes new programming language called nesC • Currently the standard in sensor OS

TinyOS features • Extensibility • Allows components to be “wired” together thereby allowing for flexibility and ease of development through use of a wide array of components able to be wired in many configurations • Specifically designed for use in sensors • Low power overhead • Requires little processing power • Small memory footprint

What TinyOS does not provide… • In order to accommodate the unique resource requirements of sensors, TinyOS has sacrificed: • Kernel – programmer deals with hardware directly • Process Management – only one process • Multiple stacks – only a single shared stack • Virtual Memory – physical memory used • Dynamic Memory Allocation – assigned at compile time

TinyOS program architecture • A program consists of a set of components “wired” together • Each component can provide “interfaces” which can be wired to and allow use of that component’s functions (it exports these functions) • The component can also export events to which a component wired to it can respond to • Note: These components are statically wired together at compile time

TinyOS Components can provide... • Events • An event is a “happening” that is produced by a component and that can be responded to by any components wired to this component • Events are generated in response to a given happening and can call other commands, generate other events or post a task • Commands • Provided by a component, these provide functionality into that component • A command of a component may be invoked by a component wired to it and is akin to a member function of a class • Can also call other commands, trigger events or post tasks

Tasks in TinyOS and Scheduling • Tasks • A function that once called is put in a FIFO queue awaiting execution • Usually used for longer processing errands because these can be preempted (by an incoming event for example) • Scheduling • Commands and Tasks (FIFO queued) are non-blocking and non-preemptive (tasks cannot preempt each other) • Events are preemptive and blocking • Hence, responses to events must be kept as short as possible (e.g. post a task and return)

Download and Install TinyOS http://www.tinyos.net/tinyos-1.x/doc/install.html Windows: Uses Cygwin environment to simulate Linux environment More complex than Linux installation (this took some time) WARNING: TinyOS has problems with newer versions of Cygwin and prefers older versions for proper functioning Linux: Preferred as it’s native and faster; Easier setup Simply involves installing several RPMs (for Red Hat) Note that nesc-1.1-1.i386.rpm should be used (the recommended nesc-1.1.2b-1.i386.rpm gives many compiler errors) TinyOS development

TinyOS installation notes • Installs • nesC compiler and AVR package (processor dependant) • Java JDK and Communications package • TinyOS software/modules • TinyOS installation (Red Hat) can be found in /opt/tinyos-1.x/ • /opt/tinyos-1.x/apps contains example components (such as Blink) • /opt/tinyos-1.x/tools/java contains many java applications that will be useful later • /opt/tinyos-1.x/tools/scripts contains toscheck which can be used to check installation for correctness • Also ensure that you change your PATH variable to include

Component Development • Components consist of two files • Configuration file (e.g. mycomponent.nc) • Specifies how and to which other components this particular component is wired to • Also allows the component to “provide” various interfaces to other components (that can wire to it) • Module file (e.g. mycomponentM.nc) • This is the actual implementation of the component itself • Deals with event handling, command implementation, task posting, etc.

Blink: A component example Blink.nc consists of: configuration Blink {}implementation { components Main, BlinkM, SingleTimer, LedsC; Main.StdControl -> BlinkM.StdControl; Main.StdControl -> SingleTimer.StdControl; BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC;}

Code walkthrough • configuration Blink { } • Specifies this is a configuration file whose name is Blink • implementation { • Indicates that this is where we specify the actual configuration of the component • components Main, BlinkM, SingleTimer, LedsC; • A listing of the set of components that this configuration file references (makes use of)

Code walkthrough continued… • Main.StdControl -> SingleTimer.StdControl; Main.StdControl -> BlinkM.StdControl; • Main is a component and StdControl is an interface it uses • -> symbol indicates that the component on the left “is wired to” (OR the component on the left “uses”) the component on the right and carries with it two conditions: • The component on the right must implement all the functions provided by the component’s interface on the left • The component on the left must implement event handlers for all the events that the component on the right exports • Hence, Main’s StdControl interface uses (is wired to) the StdControl interfaces provided by (implemented by) both BlinkM and SingleTimer

StdControl Interface • Anyone who provides the StdControl Interface must implement the following 3 functions: • StdControl.init(), StdControl.start() and StdControl.stop() • When a mote is started, the first two functions called are Main.StdControl.init() and Main.StdControl.start() • Any modules who implement this interface and are wired to Main in such a way also have their init and start functions called • The last function called is Main.StdControl.stop() and it will call all the stop functions it is wired to

Code walkthrough continued pt2… • BlinkM.Timer -> SingleTimer.Timer; • Indicates the BlinkM module is wired to the SingleTimer.Timer interface and hence can utilize all the commands it provides and now as the obligation to respond to any events it exports • BlinkM.Leds -> LedsC; • Similar to the Timer interface, through this line, BlinkM is now able to utilize the Leds interface (commands that can control the LED lights on the mote)

BlinkM.nc – module implementation • module BlinkM { provides { interface StdControl; } uses { interface Timer; interface Leds; }}// Code continued on next slide... • Indicates this is a module file (an implementation) that: • Provides the StdControl interface (the init(), start() and stop() functions) • Uses the interfaces Timer and Leds (allows it to utilize the commands and respond to the events generated by those interfaces)

BlinkM.nc continued… • 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(); } //Code continued on next slide… • This is the implementation of the module • Init() is called when the module is first initialized. It initializes the Led lights • Start() is called when the module is first started. It starts a timer function that will fire every 1000 milliseconds and repeats doing this till the stop command is called. • Stop() is called when the module is shut off and this stops the timer function.

BlinkM.nc continued pt2… • event result_t Timer.fired() { call Leds.redToggle(); return SUCCESS; } }//end implementation • Since BlinkM uses the timer interface, it must also provide event handlers for the events that Timer exports • Every time the timer fires, we call a command provided by the Leds interface (a command which toggles the red LED) • Hence, we have created a module that blinks the red LED light on the mote once every second!

Running TinyOS code - TOSSIM • cd /opt/tinyos-1.x/apps/Blink - where the Blink application example is stored • make pc – compile the module for use in TOSSIM simulation on the host pc • ./build/pc/main.exe N -run simulation where N is the number of nodes in the simulation • OR ./build/pc/main.exe –rf=lossy.txt N – where lossy.txt specifies the topology of the nodes • By default, in TOSSIM, the nodes are all placed in virtual reach of each other

Debugging • Debugging • Place debug lines in code such as: • dbg(DBG_USR1, "processingRecieve from %d”, source) • export DBG=usr1 • This will enable all dbg lines with DBG_USR1 to be outputted to the screen during simulation runs

TinyViz – A visualization program • Add /opt/tinyos-1.x/tools/java/net/tinyos/sim to the PATH environment variable • tinyviz –run ./build/pc/main.exe N • Will run the simulation in visual mode • Following slide shows TinyViz with Radio Links extension enabled • Blue circles: Broadcasts • Red arrows: Directed message sends

TinyViz

Mica2 module uploading • Create Makelocal file in /opt/tinyos-1.x/apps with the following: PFLAGS += -DCC1K_DEF_FREQ=916700000 DEFAULT_LOCAL_GROUP=0x01 MIB510=/dev/ttyS0 • Attach serial cable from PC to programming board and mica2 to board. Switch mica2 on. • Switch to the Blink directory • make mica2 install.<id> - where id is the node id that you want that particular sensor to have (the IP address of that node) • Your sensor should now Blink…It’s alive!

…And they all lived happily ever after QUESTIONS?!

Programming Motes