Scribd
Upload
528 views26 pages

TinyOS Architecture and Programming Guide

The document describes the TinyOS operating system and nesC programming model for networked sensor nodes. Key points: - TinyOS uses an event-driven architecture with no kernel/memory management for small memory footprint and power efficiency. - Applications are built from modular components that provide/use interfaces of commands and events. Components are wired together in configurations. - nesC compiles applications into components and configurations. It supports concurrency through tasks and events with FIFO scheduling.

Uploaded by

Chaitanyareddy Mettu
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
528 views26 pages

TinyOS Architecture and Programming Guide

The document describes the TinyOS operating system and nesC programming model for networked sensor nodes. Key points: - TinyOS uses an event-driven architecture with no kernel/memory management for small memory footprint and power efficiency. - Applications are built from modular components that provide/use interfaces of commands and events. Components are wired together in configurations. - nesC compiles applications into components and configurations. It supports concurrency through tasks and events with FIFO scheduling.

Uploaded by

Chaitanyareddy Mettu
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd

System Architecture Directions for Networked Sensors

[Link], [Link], [Link], [Link], [Link], [Link]

CS 851 - Radu Stoleru

University of Virginia

TinyOS

application = scheduler + graph of components event-driven architecture single shared stack NO kernel, process/memory management, virtual memory

University of Virginia

Components

A component has:

Frame (internal state) Tasks (computation) Interface (events, commands) one per component statically allocated fixed size

Component
Tasks Frame

Frame :

Commands

Events

Commands and Events are function calls Applicaton: linking/glueing interfaces (events, commands)

University of Virginia

Commands/Events

commands:

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 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
University of Virginia 4

events:

Scheduler

two level scheduling: events and tasks scheduler is simple FIFO a task can not preempt another task events preempt tasks (higher priority)
Preempt events POST Tasks FIFO commands commands Interrupts Hardware Time

main { while(1) { while(more_tasks) schedule_task; sleep; } }

University of Virginia

Tasks

FIFO scheduling non-preemptable by other task, preemtable by events perform computationally intensive work handling of multiple data flows:

a sequence of non-blocking command/event through the component graph post task for computational intensive work preempt the running task, to handle new data

University of Virginia

Application
application Routing Layer sensing application routing

messaging

Messaging Layer

packet

Radio Packet

UART Packet

byte

Radio byte

UART byte

photo

Temp

SW HW
7

bit

RFM

clocks University of Virginia

ADC

i2c

Programming Environment

download, install and build:


cygwin ([Link] WinAVR ([Link] nesC ([Link] Java JDK ([Link] tinyOS distribution ([Link] code your components $ make mica2 install.1 $ make pc $ build/pc/[Link] 25
University of Virginia 8

build your application


debug your application with TOSSIM simulator:


nesC

the nesC model:

Application

interfaces:

Component D Component A

uses provides
Component C

components:

modules configurations
Component F configuration Component E

application:= graph of components

Component B

configuration

University of Virginia

nesC

naming conventions: nesC files suffix: .nc C stands for Configuration (Clock, ClockC) M stands for Module (Timer, TimerC, TimerM)

clarifications:

[Link] interface Clock { ... }

[Link] configuration ClockC { ... } implementation { } [Link] configuration TimerC { ... } implementation { } [Link] module TimerM { ... } implementation { }

C distinguishes between an interface and the component that provides it M when a single component has both: a configuration, a module

[Link] interface Timer { ... }

University of Virginia

10

Interfaces

used for grouping functionality, like:


split-phase operation (send, sendDone) standard control interface (init, start, stop)
TimerM

describe bidirectional interaction:


interface Clock { command result_t setRate (char interval, char scale); event result_t fired (); }

[Link]
ClockC

interface provider must implement commands interface user must implement events
University of Virginia 11

Interfaces

examples of interfaces:
interface Timer { command result_t start (char type, uint32_t interval); command result_t stop (); event result_t fired (); } [Link] interface ReceiveMsg { event TOS_MsgPtr receive (TOS_MsgPtr m); }

interface StdControl { command result_t init (); command result_t start (); command result_t stop (); } [Link] interface SendMsg { command result_t send (uint16_t addr, uint8_t len, TOS_MsgPtr p); event result_t sendDone (); } [Link]

[Link]
12

University of Virginia

Modules

implements a components specification with C code:


module MyComp { provides interface X; provides interface Y; uses interface Z; } implementation { // C code } [Link]

a thread of control crosses components only through their specifications


University of Virginia 13

Modules

parameterised interfaces:
module GenericComm { provides interface SendMsg [uint8_t id]; provides interface ReceiveMsg [uint8_t id]; } implementation { }

[Link]

i.e., it provides 256 instances of SendMsg and RecvMsg interfaces they are not strictly necessary the handler ID can be passed as an argument to the send method
University of Virginia 14

Modules

implementing the specification:

simple interfaces, (e.g. interface Std of type StdControl):


module DoesNothing { provides interface StdControl as Std; } implementation { command result_t [Link]() { return SUCCESS; } command result_t [Link]() { return SUCCESS; } command result_t [Link]() { return SUCCESS; }
University of Virginia

[Link]
15

Modules

calling commands and signaling events

simple interface:

module TimerM { provides interface StdControl; provides interface Timer[uint8_t id]; uses interface Clock; } implementation { command result_t [Link]() { call [Link](TOS_I1PS, TOS_S1PS); } }

[Link]

University of Virginia

16

Modules

posting tasks:
module BlinkM { } implementation { task void processing () { if(state) call [Link](); else call [Link](); } event result_t [Link] () { state = !state; post processing(); return SUCCESS; } [Link]
University of Virginia 17

Configurations

implements a component by wiring together multiple components:


configuration MyComp { provides interface X; provides interface Y; uses interface Z; } implementation { // wiring code } [Link]

wiring := connects interfaces, commands, events together


University of Virginia 18

Configurations

connected elements must be compatible (interfaceinterface, command-command, event-event) 3 wiring statements in nesC:

endpoint1 = endpoint2 endpoint1 -> endpoint2 endpoint1 <- endpoint2 (equivalent: endpoint2 -> endpoint1)

University of Virginia

19

Configurations

wiring example:

configuration GenericComm { provides interface StdControl as Control; command result_t activity(); } implementation { components AMStandard, LedsC; Control = [Link]; [Link] -> [Link]; activity = [Link]; [Link] }

AMStandard

LedsC

GenericComm

University of Virginia

20

Configurations

other examples:

configuration C { provides interface X as Xprovider; uses interface X as Xuser; } implementation { Xuser = Xprovider; [Link] } configuration D { provides interface X; } implementation { components C1, C2; X = C1.X; X = C2.X; }

C1

C2 D

[Link]
University of Virginia 21

Future

abstract components: allow components to be instantiated several times automatic wiring threadlets

University of Virginia

22

Example

Blink application

Blink Main

configuration Blink { } implementation { components Main, BlinkM, ClockC, LedsC; [Link]->[Link]; [Link]->ClockC; [Link]->LedsC; [Link]
ClockC

BlinkM

LedsC

University of Virginia

23

Example

BlinkM module:
command result_t [Link]() { return call [Link](128, 6); } command result_t [Link]() { return call [Link](0, 0); event result_t [Link]() { state = !state; if (state) call [Link](); else call [Link](); } [Link]
24

module BlinkM { provides interface StdControl; uses interface Clock; uses interface Leds; } implementation { bool state; command result_t [Link]() { state = FALSE; call [Link](); return SUCCESS; } [Link]

University of Virginia

Summary/Discussion

small memory footprint + concurrency intensive application, event-driven architecture + power conservation + modular, easy to extend + simplistic FIFO scheduling -> no real-time guarantees bounded number of pending tasks no process management -> resource allocation problems software level bit manipulation. HW implementation can provide speed up and power saving. no hardware timer support. It is done in software, which is lost during sleep. better OS race conditions support. University of Virginia 25

References
[1] [Link] et al. nesC Overview (and Summary of Changes), 06/2002 [2] [Link], [Link], [Link] nesC Language Reference Manual, 9/2002 [3] [Link] nesC: A Programming Language for Motes, 06/2002 [4] [Link] Welcome to the WeBS Retreat, 06/2002 [5] [Link] et al. Macroprogramming, 06/2002 [6] [Link] [7] [Link] [8] [Link] [9] [Link]

University of Virginia

26

You might also like