TinyOS

1. TinyOS Disclaimer: 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. The slides should be used only for academic purposes (e.g., in teaching a class) and should not be used for commercial purposes.

2. Table of References TinyOS

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

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

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

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

7. TinyOS Models • TinyOS models- • Data Model • Thread Model • Programming Model • Component Model • Network Model TinyOS

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

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

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

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

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

13. Network Model TinyOS

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

15. Example application • 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 TinyOS

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

17. Continued.. • 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. TinyOS

18. Example Application - Blink 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 TinyOS

19. Blink.nc Module • 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. TinyOS

20. Blink.nc Module..Continued • 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. TinyOS

21. Std Control module • StdControl.nc interface StdControl {  command result_t init();  command result_t start();  command result_t stop();} TinyOS

22. Std Control module • 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. TinyOS

23. Std Control module • 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. TinyOS

24. BlinkM module BlinkM.nc module BlinkM {  provides {    interface StdControl;  }  uses {    interface Timer;    interface Leds;  }} TinyOS

25. BlinkM module • 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. TinyOS

26. BlinkM module continued.. 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;  }} TinyOS

27. BlinkM module • 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. TinyOS

28. Timer module Timer.nc interface Timer {  command result_t start(char type, uint32_t interval);  command result_t stop();  event result_t fired();} TinyOS

29. Timer module • 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 TinyOS

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