TinyOS

Sandeep Gupta

Operating System (OS)

What is an OS?

Main functions Process management Memory management Resource management

Traditional OSs are monolithic.

Sensors

Sensor consists of Processor Limited memory (128kb) Transceiver Peripheral devices (eg. LED) Limited battery and Sensing module

Deployed for specific application process and resource management not required

TinyOS Introduction Written using a component based language called

NesC (Nested C). Hardware devices are represented using

components. For example: LedsC for LED Interrupt driven Only one application runs on sensors. Application contains the OS code. Code to control

hardware devices. Application does not contain the whole OS. To avoid problems due to invalid memory access

does not allow dynamic memory allocation.

Components

Each component will provide a set of services (atleast stdcontrol).

stdcontrol provides commands for initializing, starting and stopping the component.

Services provided by a component can be used via interfaces.

Components can use interfaces provided by other components.

Each component is like a state machine.

Interface Interface is like a header file that defines APIs using which components

will interact. Interfaces are bidirectional. Interface consists of commands and events. Commands:

Issued by component that uses an interface provided by another component. Component that provides an interface will have the implementation for

commands. Events:

Issued by component that provides an interface to a component that uses an interface.

Component that uses an interface will have the implements for events. Example: LedsC component provides Leds interface to switch on and

off the LEDs.

Split-phase operation

To avoid delay in response long latency function calls are executed in split-phase.

For example: Sending a packet. The application issues a send call which will schedule the

actual sending process to be executed at a later time Upon transmission the application is notified regarding the

successful transmission. Accomplished using commands, events and tasks. Long latency functions are called tasks.

What are tasks? Requirement of realtime OS: bounded delays

between events. Event handler should run to completion within a

short duration. If a lot of computation is involved in an event

handler we defer execution. How? Implementing it as a task and scheduling it for later

execution. TinyOS has simple FIFO scheduler using which

tasks are scheduled. Upon occurrence of an event a task that is

executing is preempted.

Configuration and Modules

Configuration: Each application will have a main configuration file that wires

components together. Wiring?

Wiring is attaching two components together and specifying the interface using which they will exchange information.

Eg.BadgeM.Leds LedsC.Leds;The arrow direction indicates the command calling and event signalling flow. Here BadgeM will call commands on LedsC and LedsC will signal events to BadgeM.

Modules: Each application might contain implementation specific to it.

TinyOS Application Consists of a set of components and a scheduler A configuration file represents an application. Interrupt driven. List of interrupts handled depend on list of hardware components

included in the application (e.g. clock and receiver). Waits for interrupts. On occurrence of interrupt, calls interrupt

handler. Two threads of execution

Scheduler thread (lower priority) Interrupt thread (higher priority)

HardwareInterrupts ISR Interrupt

Handler

invokes Calls

Example Application Badge

Components Main BadgeM TimerC GenericComm Leds

Badge application sends a beacon message out every 1000ms BadgeM contains our application code. Main is the entry point to any application. All other components will be wired to Main directly or indirectly. Main will initially init all components and then call their start functions. Interrupts used

Clock Transmitter

Wiring of components

BadgeM

TimerC

HPLClock

Hardware Clock

Set InterruptSpecific parameters

ISR calls clock firedEvent handler

Clock InterfaceHPLClock provides the interface for Setting timer interrupt parameters TimerC implements the event handler for fired event

Timer InterfaceTimerC provides the interface forSetting timer interrupt parametersBadgeM implements the event handler for fired event

GenericComm

SendMsg InterfaceGenericComm provides interface to send a messgas and BadgeM implements the sendDone event handler.

.

.

.

.

.

.

Transceiver

MainstdControl InterfaceBadgeM implements stdControl interface

Entry point

All wiringsBelow this arepredetermined

Event and Commands in BadgeM

FIFOScheduler

Clock ISR(TOSH_INTERRUPT)

HPLClock

TimerM

BadgeM

Fired

Fired

Fired

Fired event handler posts sendBadge task

Task sendBadgeSchedulesThe task

GenericComm

Send

Transmitter

.

.

.

.

.

Send

Send SendDone

SendDone

SendDone

Leds

.

.

.

.

.

greenOnredOff

Main Starts FIFO

StartStart

CommandEvent

Function

Tasks

Start

setInterval

TimerInterface Leds

Interface

SendMsgInterface

stdcontrolInterface

stdcontrolInterface

Compilation Phase1. NesC compiler first converts the application

into a c file (app.c. present in build directory of each application).

2. All commands and events are replaced with function.

3. Code for clock interrupt service routine is generated. (handout 1).

4. C file is compiled into an exe format.5. avr-objcopy application converts it into a

flash programmable format.

Execution phase1. Main calls start of BadgeM.2. BadgeM sets time interval for timer interrupt via TimerM and HPLClock

components. (handout 1)3. Main then enables the interrupts.4. Main starts the scheduler.5. Steps 6 through 11 are repeated every time timer interrupts.6. Timer interrupt calls the event handler in BadgeM via HPLClock and TimerM.

(handout 1) 7. BadgeM fired event handler schedules (posts) a sendBadge task. (handout 3)8. Scheduler schedules sendBadge when there are no events to be serviced.9. sendBadge then calls the send command part of SendMsg interface provided by

GenericComm. (handout 3)10. send methods transmits the packet. 11. When packet transmission is complete, sendDone event is sent to BadgeM

component. (handout 3)

Problems

If components are not initialized then they will initialize at an arbitrary state which will lead to unpredictable results. e.g. if BadgeM’s stdControl is not wired to Main

then the clock will start generating interrupts at 1ms intervals.

Debugging

Leds are used for debugging applications. JTAG can also be used for debugging

applications loaded onto the motes.

Handout 1BlinkM initiates the ISR registration and so BlinkM will be the handler for timer interrupt.

BlinkM command result_t StdControl.start() { call Timer.start(TIMER_REPEAT, 250); (Execution Phase: Step 2)…. }

TimerM command result_t Timer.start (char type, uint32_t interval) {…..…..….. call Clock.setInterval(mInterval); (Execution Phase: Step 2)…..…..….. }

HPLClock async command void Clock.setInterval(uint8_t value) (Execution Phase: Step 2) { outp(value, OCR0); }(ISR defined in HPLClock) (Compilation Phase: Step 2) TOSH_INTERRUPT(SIG_OUTPUT_COMPARE0) {….….…. signal Clock.fire(); }

Handout1 cont.BadgeMevent result_t Timer.fired()(Execution Phase: Step 6){ post sendBadge(); return SUCCESS;} No Code here in TimerM. But how does fired event in BadgeM get called? (Code is inserted by the NesC compiler based on the wiring)

TimerMdefault event result_t Timer.fired[uint8_t id]() (Execution Phase: Step 6){ return SUCCESS;}

HPLClockdefault async event result_t Clock.fire() { return SUCCESS; }(ISR defined in HPLClock)

TOSH_INTERRUPT(SIG_OUTPUT_COMPARE0) {….….…. signal Clock.fire(); (Execution Phase:

Step 6) }

Handout 2

Configuration fileincludes Badge;configuration Badge {} implementation { components Main, BadgeM, TimerC, GenericComm as Comm, LedsC as Leds, HPLCC1000M; Main.StdControl -> BadgeM; (step 2) Main.StdControl -> TimerC; BadgeM.Timer -> TimerC.Timer[unique("Timer")]; BadgeM.SendMsg -> Comm.SendMsg[AM_BADGEMSG]; BadgeM.Leds -> Leds; BadgeM.HPLChipcon -> HPLCC1000M;}

Handout 3BadgeM implementationincludes Badge;module BadgeM { provides interface StdControl; uses interface Timer; uses interface SendMsg; uses interface Leds; uses interface HPLCC1000 as HPLChipcon;} implementation { uint16_t cur_seqno = 0; BadgeMsg *badge_msg; TOS_Msg send_msg; bool sendBusy = FALSE; uint8_t counter; uint16_t seqNum = 0; task void sendBadge(); // Called when the application is initialized. command result_t StdControl.init() { badge_msg = (BadgeMsg *)send_msg.data; counter++; return SUCCESS; } // Also called when the application is initialized, but after // all modules have had StdControl.init() invoked. command result_t StdControl.start() { call Timer.start(TIMER_REPEAT, 250); call Leds.greenOn(); return SUCCESS; } // Called if another module wishes to stop this one. This will never // happen in practice, but, we still stop the timer here. command result_t StdControl.stop() { call Timer.stop(); return SUCCESS; }

Handout 3 cont.// Send a radio badge. task void sendBadge() { call Leds.greenOn(); call Leds.redOff(); if (!sendBusy) { badge_msg->sourceaddr = TOS_LOCAL_ADDRESS; badge_msg->seqNo = seqNum++; sendBusy = TRUE; if (!call SendMsg.send(TOS_BCAST_ADDR, sizeof(BadgeMsg), &send_msg)) (Step 9) {

sendBusy = FALSE;// Can't send messagecall Leds.redOn();return;

} else {// Message send completedreturn;

} } else { // Can't send message - still sending previous!? call Leds.redOn(); return; } } // Called when the previous message been sent. event result_t SendMsg.sendDone(TOS_MsgPtr msg, result_t success) (Step 11) { call Leds.greenOff(); sendBusy = FALSE; return SUCCESS; } event result_t Timer.fired() { post sendBadge(); (Step 7) return SUCCESS; }}