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

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

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

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

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

6. 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)‏ }

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

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

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

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

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

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

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

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