TinyOSDisclaimer: a.Information included in this slides came from multiple sources. We have tried our best to cite the sources. Please refer to the Table of References slide (#2) to learn about the sources, when applicable.b.The slides should be used only for academic purposes (e.g., in teaching a class) and should not be used for commercial purposes.

Slides Source5 http://en.wikipedia.org/wiki/TinyOS

6 www.cs.virginia.edu/~cl7v/cs851-talks/tinyos_chenyang.ppt

7-13 www.telematica.polito.it/wsn/ppt/WSN2_TinyOS.pdf

15-17 http://www.pages.drexel.edu/~kws23/tutorials/motes/motes.html

18-29 • http://www.cmi.ac.in/~sdatta/SE/doc/tutorial/lesson1.html• http://www.tinyos.net/dist-2.0.0/tinyos-2.x/doc/html/tutorial/lesson1.html

Table of References

TinyOS

2

Agenda• Why was TinyOS needed?• Introduction to TinyOS• Goals/Objectives behind TinyOS• Requirements of WSN for Operating System• TinyOS as a Solution• TinyOS Model

▫Data Model▫Thread Model▫Programming Model▫Component Model▫Network Model

• Example Application

3

TinyOS

Need of TinyOS•Problems with traditional OS

▫Multithreaded Architecture not useful▫Large Memory Footprint▫Does not help to conserve energy and power

•Requirements for Wireless Sensor Networks▫Efficient utilization of energy and power▫Small Footprint▫Should support diversity in design and usage▫More emphasis on Concurrent execution

4

TinyOS

Introduction to TinyOS•TinyOS began as a collaboration

between University of California, Berkeley and Intel Research.[4]

•It is a free open source operating system designed for wireless sensor networks.

•It is an embedded operating system written in NesC

•It features a component based architecture.

5

TinyOS

TinyOS as a Solution•Component based architecture allows

frequent changes while still keeping the size of code minimum.

•Event based execution model means no user/kernel boundary and hence supports high concurrency.

•It is power efficient as it makes the sensors sleep as soon as possible.

•Has small footprint as it uses a non-preemtable FIFO task scheduling.

6

TinyOS

TinyOS Models

•TinyOS models-▫Data Model▫Thread Model▫Programming Model▫Component Model▫Network Model

7

TinyOS

Data Memory Model• Static Memory Allocation

▫ No Heaps or any other dynamic structures used.

▫ Memory requirements determined at compile time.This increases the runtime efficiency.

• Global variables▫ Allocated on per frame basis.

• Local Variables▫ Saved on the stack▫ Defined in the function/method

8

TinyOS

Thread Model•Power-Aware Two-levels Scheduling

▫ Long running tasks and interrupt events▫Sleep unless tasks in queue, wakeup on

event• Tasks

▫Time-flexible, background jobs▫Atomic with respect to other tasks▫Can be preempted by events

• Events▫Time-critical, shorter duration▫ Last-in first-out semantic (no priority)▫ Can post tasks for deferred execution

9

TinyOS

Programming Model• Separation construction/composition•Construction of Modules

▫ Modules implementation similar to C coding▫Programs are built out of components▫ Each component specifies an interface▫ Interfaces are “hooks” for wiring components

• Composition of Configurations▫Components are statically wired together▫Increases programming efficiency (code

reuse) an runtime efficiency (static defs.)

10

TinyOS

Component Model•Components should use and provide

bidirectional interfaces.

•Components should call and implement commands and signal and handle events.

•Components must handle events of used interfaces and also provide interfaces that must implement commands.

11

TinyOS

Component Model : Hierarchy• Commands

▫ Flow downwards▫ Non Blocking requests▫ Control returns to caller

• Events▫ Flow upwards▫ Post task, signal higher level events, call lower level cmds▫ Control returns to signaler

• To avoid cycles▫ Events can call commands▫ Commands can NOT signal events

12

TinyOS

Network Model

13

TinyOS

nesC

•nesC (network embedded system C) is a language used to build applications in TinyOS.

• It is designed such a way to exhibit the concepts and execution model of TinyOS.

•Refer the tutorial given below to see a simple program in nesC.

http://docs.tinyos.net/index.php/The_simplest_TinyOS_program

14

TinyOS

•In the diagram on next slide the module BC.nc provides the interface Bint.

• The implementation for the module defines a command Bint.Bcmnd and an event Bint.Bevnt.

•To access command Bint.Bcmnd in the declaration of our module we would say it uses the interface Bint.

•A.nc is the configuration file which wires the interface of module AM.nc to the interface of module BC.nc

Example application

15

TinyOS

Ref:http://www.pages.drexel.edu/~kws23/tutorials/motes/motes.html

16

TinyOS

•Module AM.nc has access to all of the commands provided by BC.nc

•The implementation might also contain a task where it uses the command from C.nc

•Also the fundamental rule of nesC states that any module that uses a command from another module must address all of the events provided by the other module.

•Therefore AM.nc must also contain code to address the event Bint.Bevnt.

Continued..

17

TinyOS

Blink.nc configuration Blink {

}implementation {

  components Main, BlinkM, SingleTimer, LedsC;

  Main.StdControl -> BlinkM.StdControl;  Main.StdControl -> SingleTimer.StdControl;  BlinkM.Timer -> SingleTimer.Timer;  BlinkM.Leds -> LedsC;}

Note:Please refer to the tutorial on the TinyOS website to get more information

Example Application - Blink

18

TinyOS

•In the Blink.nc file you can see it consists of the configuration Blink.

•A configuration can have uses and provides clauses.

•The real configuration is written in implementation section and the components line specifies the components it references i.e. in this case Main, BlinkM, SingleTimer, and LedsC.

Blink.nc Module19

TinyOS

•Main is a component that is executed first in a TinyOS application.

•Main.StdControl.init() command is the first command executed in TinyOS followed by Main.StdControl.start().

•Therefore, a TinyOS application must have Main component in its configuration.

•StdControl is a common interface used to initialize and start TinyOS components.

Blink.nc Module..Continued

20

TinyOS

•StdControl.nc

interface StdControl {

  command result_t init();  command result_t start();  command result_t stop();}

Std Control module

21

TinyOS

• We see that StdControl defines three commands:▫ init()-called when component is first initialized▫start()-when it is executed for first time▫stop()-when the device is powered off

• The following 2 lines in Blink configuration Main.StdControl -> SingleTimer.StdControl;

  Main.StdControl -> BlinkM.StdControl; wire the StdControl interface in Main to the

StdControl interface in both BlinkM and SingleTimer.

Std Control module

22

TinyOS

• SingleTimer.StdControl.init() and BlinkM.StdControl.init() will be called by Main.StdControl.init() and in same way for the start() and stop() commands.

• The BlinkM module uses the interface Leds, so Leds.init() is called explicitly in BlinkM.init().

• “->” binds an interface on left to an implementation on right.

• For e.g.  BlinkM.Timer -> SingleTimer.Timer is used to wire the Timer interface used by BlinkM

to the Timer interface provided by SingleTimer.

Std Control module

23

TinyOS

BlinkM.ncmodule BlinkM {

  provides {    interface StdControl;  }  uses {    interface Timer;    interface Leds;  }}

BlinkM module

24

TinyOS

•The BlinkM module provides the interface StdControl also therefore BlinkM implements StdControl interface.

•The BlinkM module also uses two interfaces: Leds and Timer

•The Leds interface defines several commands like redOn(),redOff(), and so forth, which turn the different LEDs ON and OFF.

BlinkM module

25

TinyOS

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();  }

  event result_t Timer.fired()  {    call Leds.redToggle();    return SUCCESS;  }}

BlinkM module continued..26

TinyOS

• BlinkM module implements the StdControl.init(), StdControl.start(), and StdControl.stop() commands, since it provides the StdControl interface.

• The init() command in the implemented StdControl interface simply initializes the Leds subcomponent with the call to Leds.init().

• The start() command invokes Timer.start() to create a repeat timer that expires every 1000 ms. stop() terminates the timer.

• Each time Timer.fired() event is triggered, the Leds.redToggle() toggles the red LED.

BlinkM module

27

TinyOS

Timer.nc interface Timer {

  command result_t start(char type, uint32_t interval);  command result_t stop();  event result_t fired();}

Timer module

28

TinyOS

• Timer interface defines the start() and stop() commands, and the fired() event.

• The start() command is used to specify the type of the timer and the interval at which the timer will expire.

• An event function i.e. in this case fired() will signal when specified interval of time is passed.

• Such a interface is also known as a bidirectional interface as it provides commands that can be called by users of the interface and also signals events that call handlers in the user

Timer module29

TinyOS

References• http://docs.tinyos.net/index.php/TinyOS_Tutorials• http://csl.stanford.edu/~pal/pubs/tinyos-programming.pdf• http://www.tinyos.net/• http://en.wikipedia.org/wiki/TinyOS• http://www.princeton.edu/~wolf/EECS579/imotes/tos_tutorial.pdf• http://www.pages.drexel.edu/~kws23/tutorials/motes/motes.html • http://www.cmi.ac.in/~sdatta/SE/doc/tutorial/lesson1.html

30

TinyOS