A Glance to Tiny OS

1. A Glance to Tiny OS Presented by Shanshan Chen OU-TCOM March, 2008

2. Outline • Introduction • NesC programming • TinyOS structure • A case study of sample code

3. Introduction

4. What is TinyOS • An open source Operation system for embedded system • Developed by UC Berkeley • Now mainly used in Wireless Sensor Networks • Component – Based Architecture

5. What is mote? Mote is known as a sensor node in wireless sensor networks (Chiefly North America)

6. Wireless Sensor Network

7. Hardware—Crossbow set Mica suite, Tranceiver Programming board AD converters Base-station node

8. Hardware setup

9. Hardware -- others Sentilla Moteiv Tmote Crossbow Cricket Mote A location aware version of the popular MICA2 low-power Processor/Radio module

10. Advantages of TinyOS • Essential Reason—Component based • Each core code can be less than 400 bytes which will be easily implemented in Sensor system with memory limits • Thus saving the room for the operation of management of the whole network • Does Open source count? – Definitely YES • Not a standard yet, but obviously widely spreaded

11. What is Crossbow’s business? • Over 10 different kinds of sensor system for various customer’s need • The consumers (mostly Engineering academic units) can focus on the application of the sensor system without being bothered by transmission issues • To buy or not to buy?

12. NesC programming

13. What is NesC A C-like language，an extension of C , and designed to embody the structuring concepts and execution model of TinyOS

14. Source file (.nc) type-- Component • Components : the basic building blocks for NesC applications • modules • configurations • Module— embody the code programming, providing and using interfaces • Configuration— combining components and modules together, can provide and use interfaces

15. Source file type (.nc) -- Interface • Interface: used to provide an abstract definition of the interaction of two components (the user and the provider) • An interface contains no actual code or wiring • Declares commands--that the interface's provider must implement, • Declares events -- interface's user must implement • NesC interfaces specify two directions

16. Common Components • - AD conversion • - Random numbers • - Cryptography - Routing • - File System • - Serial Communication • - LED control • - Timers • - Memory allocation • - Watchdog • - Data logging • - Sensor Board Input

17. Modules and configuration configuration Blink{ } implementation { components Main, BlinkM, TimerC, LedsC; Main.StdControl -> TimerC.StdControl; Main.StdControl -> BlinkM.StdControl; BlinkM.Timer -> TimerC.Timer[unique("Timer")]; BlinkM.Leds -> LedsC.Leds; } module BlinkM { provides { interface StdControl; } uses { interface Timer; interface Leds; } }

18. Implementation of BlinkM 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; } }

19. How to interface interface StdControl { command result_t init(); command result_t start(); command result_t stop(); } //provider • Timer.nc • interface Timer {command result_t start(char type, uint32_t interval); • command result_t stop(); •  event result_t fired();} //user

20. Is that all?(Things behind the source code) • Makefile include Makefile.component include $(TOSROOT)/apps/MakeXbowlocal include $(MAKERULES) • Makefile.component COMPONENT=Blink SENSORBOARD=mts310

21. Structure • A module implements an interface • Components provide and use interfaces • A configuration links or “wires” the internal and external interfaces • An application consists of a top-level configuration and all associated modules

22. TinyOS Structure

23. Actuating Sensing Active Message Communication Firmware structure Main (includes Scheduler) Application (User Components) ADC, CLOCK, I2C, LEDS, PHOTO, UART, RFM Mote Hardware

24. TinyOS scheduling • Concurrency model – two threads • Hardware event handler (higher priority) • Task (lower priority) • Tasks • Time flexible • Longer background processing jobs • Atomic with respect to other tasks (single threaded) • Preempted by event • Hardware event handlers • Time critical • Shorter duration (hand off to task if need be) • Interrupts task and other hardware handler. • Last-in first-out semantics (no priority among events) • executed in response to a hardware interrupt

25. Hardware Event Handler • Events must only do a small amount of work before completing, because events always run to completion and cannot be preempted • Hardware event handlers are executed in response to a hardware interrupt and also runs to completion, but may preempt the execution of a task or other hardware event handler. • Commands and events that are executed as part of a hardware event handler must be declared with the async keyword.

26. Event sample implementaion { result_t display(unit16_t value){ if (value &1) call Leds.yellowOn(); else call Leds.yellowOff(); if (value &2) call Leds.greenOn(); else call Leds.greenOff(); if (value &4) call Leds.redOn(); else call Leds.redOff(); return SUCCESS; } module SenseM { provides { interface Timer; interface ADC; interface StdControl as ADCControl; interface Leds; } }

27. Event Sample contd command result_tStdControl.init() { return rcombine(call ADCControl.init(),call Leds.init()); } command result_tStdControl.start() { return rcombine(call Timer.start(TIMER_REPEAT,500) } command result_tStdControl.stop() { return call Timer.stop(); }

28. Event Sample contd event result_tTimer.fired () { return call ADC.getData(); } async event result_t ADC.dataReady(unit16_t data) { display(7-((data>>7)&0x7)); return SUCCESS; } }

29. Task • Tasks are atomic with respect to other tasks • Run-to-completion semantic allows to have single stack for currently running process • Tasks simulate concurrency, they are asynchronous with respect to events • Tasks must never block or spin-wait • Tasks are usually used to perform longer processing operations, such as background data processing, that can be preempted by events.

30. Some time after the event completes (there may be other tasks pending for execution), the processData() task will run. It computes the sum of the recent ADC samples and displays the upper three bits of the sum on the LEDs. To dispatch a task for (later) execution, use the syntax post taskname(); Task • Task example task void processData() { int16_t i, sum=0; atomic { for (i=0; i < size; i++) sum += (rdata[i] >> 7); } display(sum >> log2size); } • SenseTaskM.nc // ADC data ready event handler • async event result_t ADC.dataReady(uint16_t data) • { • putdata(data); • post processData(); • return SUCCESS; • }

31. Query in TinyOS • TinyDB – Database in TinyOS • Need for data analysis in WSN (power, ) • All tasks related to data processing is the work of TinyDB • TinyDB is a query processing system for extracting information • Providing SQL-like interface

32. A Case study of sample code

33. A sensing code sample • a simple sensor application that takes light intensity readings (from the sensor board's photo sensor) • displays those readings on the LEDs • that reads a value from the light sensor and displays the lower 3 bits of the value on the LEDs. • The application configuration is found in Sense.nc and the implementation module in SenseM.nc.

34. SenseM.nc implementaion { result_t display(unit16_t value){ if (value &1) call Leds.yellowOn(); else call Leds.yellowOff(); if (value &2) call Leds.greenOn(); else call Leds.greenOff(); if (value &4) call Leds.redOn(); else call Leds.redOff(); return SUCCESS; } module SenseM { provides { interface Timer; interface ADC; interface StdControl as ADCControl; interface Leds; } }

35. SenseM.nccontd command result_tStdControl.init() { return rcombine(call ADCControl.init(),call Leds.init()); } command result_tStdControl.start() { return rcombine(call Timer.start(TIMER_REPEAT,500) } command result_tStdControl.stop() { return call Timer.stop(); }

36. SenseM.nc contd event result_tTimer.fired () { return call ADC.getData(); } async event result_t ADC.dataReady(unit16_t data) { display(7-((data>>7)&0x7)); return SUCCESS; } }

37. Sense.nc configuration configuration Sense { // this module does not provide any interface } implementation { components Main, SenseM, LedsC, TimerC, Photo; Main.StdControl -> SenseM; SenseM.ADC -> Photo; SenseM.ADCControl -> Photo; SenseM.Leds -> LedsC; SenseM.Timer -> TimerC.Timer[unique("Timer")]; }

38. Set up the coding environment • You can do it in linux/cygwin for sure • Also there are easier ways : Moteworks + Programmers Notepad • Install Moteworks • Configure the system variables • Meet some sample codes!

39. Now try the code! • (Makefile) • Compiling: Make Mica2/Micaz/Mica2 Dots/Micaz Dots • Code is compiled when you see “ writing TOS image” • Shell command: make <platform> re|install,<n> <programmer>,<port> • E.g. “make micaz install,38 mib510,com1” • Code is installed when you see “Uploading: flash” line complete without errors • NOTE: You need to be in the .nc of the app file you want to compile and program before you can execute shell commands from Programmer’s Notepad

40. Linux environment Convert NesC into C and compile to exec Modify exec with platform-specific options Set the mote ID Reprogram the mote

41. Conclusion • TinyOS is a runtime environment for NesC running on mote hardware • – Performs some resource management • – Selected components are linked into the program at compile time