Part 2 Tiny OS and nes C Programming

Part 2 Tiny. OS and nes. C Programming Selected slides from: Wireless Sensor Networks Hardware/Software Tiny OS & Nes. C Programming borrowed from Turgay Korkmaz

What is Tiny. OS? • Operating system developed by UC Berkeley • Open Source development environment – System, library and applications written in nes. C • nes. C (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 nes. C • Separation of construction and composition • Programs are built out of components

Components provides • 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 Std. Control Timer Component Clock uses Std. Control. nc interface Std. Control { command result_t init(); command result_t start(); command result_t stop(); } Clock. nc interface Clock { command result_t set. Rate( char interval, char scale); event result_t fire(); }

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 Component Commands Events Provide Must implement Can signal Use Can call Must implement

Commands and Events • commands – deposit request parameters into the frame – are non-blocking {. . . status = call Cmd. Name(args). . . } – need to return status – postpone time consuming work by posting a task command Cmd. Name(args) {. . . return status; } – can call lower level commands • events – can call commands, signal events, post tasks event Evt. Name(args) {. . . return status; } – can Not be signaled by commands – preempt tasks, not vice-versa – interrupt trigger the lowest level events – deposit the information into the frame {. . . status = signal Evt. Name(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

Component Syntax - module Forwarder. M { provides { interface Std. Control; } uses { interface Std. Control as Comm. Control; interface Receive. Msg; interface Send. Msg; interface Leds; } } implementation { code implementing all provided commands used events, and tasks } uses provides Comm. Control Receive. Msg Std. Control Forwarder. M Send. Msg Leds interface Std. Control { command result_t init(); command result_t start(); command result_t stop(); } interface Send. Msg{ command result_t send(uint 16_t address, uint 8_t length, TOS_Msg. Ptr msg); event result_t send. Done(TOS_Msg. Ptr msg, result_t success); }

Component implementation Command imp. (interface provided) Event imp. (interface used) module Forwarder. M { //interface declaration } implementation { command result_t Std. Control. init() { call Comm. Control. init(); call Leds. init(); return SUCCESS; } command result_t Std. Control. start() {…} command result_t Std. Control. stop() {…} event TOS_Msg. Ptr Receive. Msg. receive(TOS_Msg. Ptr m) { call Leds. yellow. Toggle(); call Send. Msg. send(TOS_BCAST_ADDR, sizeof(Int. Msg), m); return m; } event result_t Send. Msg. send. Done(TOS_Msg. Ptr msg, bool success) { call Leds. green. Toggle(); return success; } }

Component Syntax - Configuration Component Selection Wiring the Components together Forwarder configuration Forwarder { } implementation { components Main, Leds. C; components Generic. Comm as Comm; components Forwarder. M; Main. Std. Control -> Forwarder. M. Std. Control; Forwarder. M. Comm. Control -> Comm; Forwarder. M. Send. Msg -> Comm. Send. Msg[AM_INTMSG]; Forwarder. M. Receive. Msg -> Comm. Receive. Msg[AM_INTMSG]; Forwarder. M. Leds -> Leds. C; } uses provides Std. Control Comm. Control Main Std. Control Receive. Msg Std. Control Forwarder. M Receive. Msg Send. Msg Generic. Comm Send. Msg Leds. C

Lab 3 • The lab is done on the computer : • csmisc 19. cs. chalmers. se • To get a username and password: • do an empty submission in Fire! • Tiny. OS 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.