TinyOS Overview of TinyOS Industrial motivations behind TinyOS - - PDF document

TinyOS

Ankit Gupta Karan Mangla Lakshya Goel Nitin Jain

Overview of TinyOS

Industrial motivations behind TinyOS What is TinyOS? TinyOS vs. traditional OS TinyOS design models TinyOS structure

Industrial Motivations behind TinyOS

Low power wireless communication devices

Particularly wireless networked sensors;

Physical limitations

Computation ability Memory Power supply High-level concurrency

What is TinyOS?

An event-based operating system designed

for wireless networked sensors.

Designed to support concurrency-intensive

• perations required by networked sensors

with minimal hardware requirements.

Developed by the EECS Department of U.C.

Berkeley.

C and Assembly languages Source code size: 500KB, 16KB commented lines

TinyOS vs. Traditional OS

Special purpose (not general purpose) Resource constraint

4MHz ATMEL 8535 8bit MCU 512 byte RAM and 8K Flash

No dedicated I/O controller (missed deadline

means loss data)

One program at one time (no multi-programming) Thin-threads (tasks)

TinyOS Design Models

Component-based model (modularity)

Simple functions are incorporated in components with

clean interfaces;

Complex functions can be implemented by composing

components.

Event-based model

Interact with outside by events (no command shell) There are two kinds of events for TinyOS: External events : Clock events and message events; Internal events triggered by external events.

TinyOS Structure

Communication Actuating Sensing Communication Application Main (scheduler) Hardware Abstractions (ADC, CLOCK, I2C, LEDS, PHOTO, UART, RFM)

Consists of a scheduler and a graph of components.

Outline

Component Structure Concurrency Model TinyOS schedulers Memory Model

TinyOS Component Structure

A TinyOS Component:

Frame (storage) Tasks (computation & concurrency)

Time consuming computations; Have no hard real-time requirements;

Commands and events (interfaces)

Layout of an interface

Can use other interfaces Provide events

To be coded by the interface user

Provides commands

Coded by the interface provider

Tasks

Perform longer operations Can be preempted by hardware event

handler but not by other tasks

Declaration: task void <name>() { ... } Posting a task: post taskname();

Done from within command, event or another task

Commands

Function call across component boundary

cause action to be initiated bounded amount of work

cannot block

always return status (0 => error)

component can refuse to perform command

share call stack and execution context access to local frame commands may post tasks or call commands

Events

Upcall to notify action has occured

bounded (and small) amount of work access local frame, shares stack

Lowest-level events triggered by hardware

interrupts

hardware abstraction components perform critical

section and enable interrupts

May signal events or call commands Events may call commands

Concurrency Model

Two threads of execution

Tasks Hardware Event Handler – handles context switch

for multiple level interrupts

Both preemptable by asynchronous code Possibility of race condition

NesC warns while compiling Method of making a block atomic allowed

Concurrency Model (cont.)

Atomicity

Disable hardware interrupt handling thread while

atomic code is running

TinyOS schedulers (Cont.)

Task scheduler

Implement FIFO scheduler in sched.c

Data structure

• Circular queue

TOS_sched_entry_T TOS_queue[MAX_THREADS];

Functions

• TOS_sched_init();
• TOS_empty();
• TOS_post();
• TOS_schedule_task();

TOS_queue Any Component (e.g. SHELL) MAIN Component

Schedule next task in queue (TOS_schedule_task)

Post task into queue (TOS_post)

Memory Model

STATIC memory(except msg buffers)

No heap(malloc) No function pointers

Global variables

Available on a per-frame basis

Local variables

Saved on the stack Declared within a method

Msg buffers allocated statically by

components,nut shared dynamically by

• wnership discipline

Memory Requirement

One task at a time – non preemptive kernel No local variables in events Buffers for active messaging Stack copy not with each task – reduce

memory requirement – hence non preemptive

Active Messages

What are active messages?

Active Messages (AM) is a simple, extensible

paradigm for message-based communication.

Used in parallel and distributed computing

systems .

Centered on the concept of integrating

communication and computation, as well as matching communication primitives to hardware capabilities.

Why Not Standard Messaging Protocols ?

Low level networking protocols of legacy stacks

typically require :

Kilobytes of memory at a minimum And performance is dependent on a fast processing

component.

Routing protocols implemented above these are :

Complex Place bandwidth demands that become unatenable for

links with kilobits per second throughput.

Cont.

Sockets - Not well suited to the constrained

environment of tiny network devices.

Interfaces centered on “stop and wait”

semantics do not meet the power and agility requirements of these small devices such as Motes.

Why Active Messaging ?

Fundamental fit between the event based nature of network

sensor applications and the event based primitives of the Active Messages communication.

The lightweight architecture of Active Messages can be

leveraged to balance the need for an extensible communication framework while maintaining efficiency and agility.

Event based handler invocation model allows application

developers to avoid busy-waiting for data to arrive and allows the system to overlap communication with other activities such as interacting with sensors or executing other applications.

Event centric nature of Active Messages makes it a natural fit for

these devices.

Active Messaging Fundamentals

tos/system/AMStandard.nc Layers Involved

Specifying message data to send Specifying receiver’s address Determining when message’s memory can be

reused

Buffering Incoming message Processing Message

Handler ID required to be specified

A TinyOS Application Example

Communication

LedsC

BLINK Main (scheduler) Hardware Abstractions (CLOCK and LEDS)

TimerM HPLclock The above application is used to toggle a Led on the mote at fixed intervals.

• This is a configuration file which provides the top-level wiring of the

application

• Main is a special component which is used to initialize the system.
• The wiring consist of joining interfaces required by certain

components to those provided by other components that are being used.

Blink.nc configuration Blink { } implementation { components Main, BlinkM, SingleTimer, LedsC; Main.StdControl -> SingleTimer.StdControl; Main.StdControl -> BlinkM.StdControl; BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC; }

RealMain.nc

module RealMain { uses { command result_t hardwareInit(); interface StdControl; interface Pot; } } implementation { int main() __attribute__ ((C, spontaneous)) { call hardwareInit(); call Pot.init(10); TOSH_sched_init(); call StdControl.init(); call StdControl.start(); __nesc_enable_interrupt(); while(1) { TOSH_run_task(); } } }

• The above component is a module file ,which are used to define

implementations of components.

• It is used to initialize all application.
• Its Std Control interface is mapped onto that used by Main and

hence when it utilizes this interface it communicates with all components that are connected to the Main component. Most components have a Std Control interface as this is what initializes every component.

• When nesC compiles the application into C the main function

involves one call to Std Contol init followed by a call to Std Control start to start the application. This is then followed by starting the task scheduler.

• This function also consists of calls to Initialize the hardware and

power settings of the mote. These calls are wired to lower level components which directly interface with the device controllers for the system.

Implementation of Main Component

BlinkM.nc

module BlinkM { provides { interface StdControl; } uses { interface Timer; interface Leds; } } implementation { command result_t StdControl.init() { call Leds.init(); return SUCCESS; } command result_t StdControl.start() { // Start a repeating timer that fires every 1000ms 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; } }

• The previous slide gives us the code for the top-level component of

the Blink application.

• As we see it provides an interface Std Control which is provided by

all applications which must be initialized as startup.

• Further we see that it only requires one Timer and one Leds

interface for this application.

• The application basically waits for a timer event to signal a given

time period after which it toggles its Leds.

• No tasks are required for this particular application.
• The LedsC code which we use just runs a function which writes to

the register controlling the Leds to toggle the Led when the command Leds.redToggle is called.

TimerM.nc

task void signalOneTimer() { uint8_t itimer = dequeue(); if (itimer < NUM_TIMERS) signal Timer.fired[itimer](); } task void HandleFire() { uint8_t i; setIntervalFlag = 1; if (mState) { for (i=0;i<NUM_TIMERS;i++) { if (mState&(0x1<<i)) { mTimerList[i].ticksLeft -= (mInterval+1) ; if (mTimerList[i].ticksLeft<=2) { if (mTimerList[i].type==TIMER_REPEAT) { mTimerList[i].ticksLeft += mTimerList[i].ticks; } else {// one shot timer mState &=~(0x1<<i); } enqueue(i); post signalOneTimer(); }}}} adjustInterval(); } async event result_t Clock.fire() { post HandleFire(); return SUCCESS; }

• Here we have displayed a portion of the TimerM.nc module which

we use in this application.

• Now the BlinkM module requires a timer event to inform it when to

toggle its Leds.

• The above module file defines a timer component which maintains

multiple timers.

• We see that on receiving an alarm from the clock it checks which

timer has finished and post a task to signal a timer fired event for that timer.

• Note that for a single timer we could directly signal the event for

timer.fired within Clock.fire which would allow a more real time implementation of the system.

• However the extra calculations required for allowing multiple timers

means that the computation cannot be done inside an event handler and must be posted as a task.

Implementation of the SingleTimer component

HPLclock.nc TOSH_INTERRUPT(SIG_OUTPUT_COMPARE0) { atomic { if (set_flag) { mscale = nextScale; nextScale|=0x8;

• utp(nextScale, TCCR0);
• utp(minterval, OCR0);

set_flag=0; } } signal Clock.fire(); } Hardware.h #define TOSH_INTERRUPT(signame) \ void signame() __attribute__ ((interrupt, spontaneous, C))

• The above codes are platform specific files which define the

interface to the actual hardware.

• HPLclock.nc is a low level component containing code for

interfacing with the clock device driver on the mica2 platform.

• Hardware.h is the file that contains many primitive functions

defined in C which can be called by other higher level components. This is the file that varies from implementation to implementation. Let us look at how nesC allows us to define interrupt handlers.

• Vector table is predefined to point to interrupt routines with predetermined names
• By using the appropriate name, your routine will be called when the corresponding

interrupt occurs

• The extra code needed to allow context switching is enabled by tagging the interrupt

function with __attribute__((interrupt))

• Thus we see that the function TOSH_INTERRUPT(signame) can

be used to define interrupt handlers.

Hardware Interface of the application

Available Components

Application level Components Functionality AM_BEACON.c Application that periodically broadcasts out identity

• information. On each clock interrupt, it sends out a

predetermined packet of information AM_BOUNCER.c Equivalent to a ping handler. Accepts a packet coming in from the network and responds with a packet sent back to the

• riginal sender.

AM_ECHO.c A component that forwards data through a node. Essentially, this is a router for a source based routing algorithm.

Available components

Main level object Functionality MAIN.c Required component that initializes the system and starts the

• scheduler. All applications must include this component.

sched.c System Scheduler, must be included in all applications. This is a simple FIFO scheduler that is used to schedule the tasks. Active messaging layer AM.c When packet arrives, check address and dispatch message to appropriate message handler. AM_STANDARD.c Base station with UART forwarding. This component behaves same as AM.c component EXCEPT that if a packet is sent to the address 0x7e, it is directed to UART instead of radio.

Available components

Packet Transport Layer Functionality PACKETOBJ.c This component takes a pointer to a byte array to be sent down to the byte level component below it. It hands the bytes down to byte level component one at a time. CRCPACKETOBJ.c Checks for CRC validity. This component performs same function as basic PACKETOBJ.c component except that it transmits additional two bytes. UART_PACKET.c This packet level component is almost identical to PACKETOBJ.c component except it sends to UART instead of radio.

Available components

Radio Byte Engine (use one) Functionality RADIO_BYTE.c A byte level component used with RFM component. This component accepts bytes from packet layer component, encodes them for transmission, and passes the bits down to the RFM component one at a time. As bits arrive from the radio, it collects the bits together into a byte worth, decodes byte and then sends the decoded byte up to the packet layer. SEC_DED_RADIO_BY TE.c Provides Single error correction/Double error detection. Also detects preamble and start symbol detection. Also uses RFM for sending and receiving bits.

Available components

UART Transport Layer Functionality RADIO.c This component performs bit level control over the radio. Addtionally, it controls the amount of time per bit. UART.c Takes bytes 1 at a time and transmits them over UART. When the component is ready to handle another byte, it fires TX_DONE

• event. When a byte arrives from the UART, the component fires the

BYTE_ARRIVAL event. Lower level device Components CLOCK.c Signals periodic events. It initialized with the interval with which to fire event and then periodically fires CLOCK_EVENT at that rate. LEDS.c Controls the outputs of the LED's

Available components

Lower level device components Functionality ADC.c Provides A/D support for analog sensors (Asynchronous interface) MIC.c, PHOTO.c, SOUNDER.c, VOLTAGE.c Interface to Microphone Interface to Photosensor Interface to Sound Device Interface to Voltage sensors

References

www.tinyos.net

Source code Tutorials Bits about NesC