Part 2 TinyOS and nesC Programming Selected slides from:

Part 2 TinyOS and nesCProgramming Selected slides from: Wireless Sensor NetworksHardware/SoftwareTiny OS & NesC Programming borrowed from TurgayKorkmaz

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

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

provides Timer StdControl Timer Component Clock uses Components • 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(); }

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

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

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

uses provides CommControl ReceiveMsg StdControl SendMsg ForwarderM Leds Component Syntax - module moduleForwarderM { provides { interfaceStdControl; } uses { interfaceStdControl as CommControl; interfaceReceiveMsg; interfaceSendMsg; interfaceLeds; } } implementation { code implementing all provided commands used events, and tasks } interface StdControl { command result_t init(); command result_t start(); command result_t stop(); } interfaceSendMsg{ commandresult_t send(uint16_t address, uint8_t length, TOS_MsgPtrmsg); eventresult_tsendDone(TOS_MsgPtrmsg, result_t success); }

Component implementation moduleForwarderM { //interface declaration } implementation { commandresult_tStdControl.init() { callCommControl.init(); call Leds.init(); return SUCCESS; } commandresult_tStdControl.start() {…} commandresult_tStdControl.stop() {…} eventTOS_MsgPtrReceiveMsg.receive(TOS_MsgPtr m) { callLeds.yellowToggle(); callSendMsg.send(TOS_BCAST_ADDR, sizeof(IntMsg), m); return m; } eventresult_tSendMsg.sendDone(TOS_MsgPtrmsg, bool success) { callLeds.greenToggle(); return success; } } Command imp. (interface provided)‏ Event imp. (interface used)‏

uses provides StdControl CommControl ReceiveMsg GenericComm ReceiveMsg Main StdControl StdControl SendMsg SendMsg ForwarderM Leds LedsC Leds Component Syntax - Configuration configuration Forwarder { } implementation { components Main, LedsC; componentsGenericComm as Comm; componentsForwarderM; 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 Forwarder

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 micazsim • 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.

Part 2 TinyOS and nesC Programming Selected slides from: