Part 2 TinyOS and nesC Programming Selected slides from: Wireless Sensor Networks Hardware/Software Tiny OS & NesC Programming borrowed from Turgay Korkmaz 1

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 2

Programming Model Basic concept behind nesC Separation of construction and composition Programs are built out of components 3

Components A component is a black box specified by interface(s) Timer Component StdControl Timer Clock provides uses 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 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(); 4

Components (cont’d)‏ A component Components must implement 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 signal Must implement Provide Can call Use Events Commands Component

Commands and Events commands events 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; } event EvtName(args) { ... return status; } { ... status = signal EvtName(args)‏ }

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 7

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 8

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, and tasks 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); } 9

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)‏ 10

Component Syntax - Configuration configuration 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; } Component Selection Wiring the Components together ForwarderM StdControl ReceiveMsg provides uses CommControl SendMsg Leds Main LedsC GenericComm Forwarder 11

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.