How to use TinyOSHow to use TinyOS™™

Jason Hill

Rob Szewczyk

Alec Woo

David Culler

An event based execution environment for Networked Sensors

Keep in mind the goals:

Support high levels of concurrency Provide efficient modularity Support ‘Network Sensor’ regime

– Real time requirements– Small memory size– Low CPU speed– Power efficiency is critical

A Component has:

Internal, fixed size storage frame. List of Commands it handles and Events it

fires.– Similar to the interface it provides

List of Commands it uses and Events if handles.– Similar to the interfaces it uses.

Bundle of tasks that perform work.

A Messaging Component Definition:

//ACCEPTS:char TOS_COMMAND(AM_send_msg)(int addr,

int type, char* data);void TOS_COMMAND(AM_power)(char mode);char TOS_COMMAND(AM_init)();

//SIGNALS: char AM_msg_rec(int type, char* data);char AM_msg_send_done(char success);

//HANDLES:char AM_TX_packet_done(char success);char AM_RX_packet_done(char* packet);

//USES:char TOS_COMMAND(AM_SUB_TX_packet)(char* data);void TOS_COMMAND(AM_SUB_power)(char mode);char TOS_COMMAND(AM_SUB_init)();

Storage Frame:

Contains all permanent state for component (lives across events, commands, and threads)

Threads, events, and commands execute inside the component’s frame

Only one per component – Like static class variables, not internal class variables.

Fixed size Allocated at compile time

Example Frame Declaration:#define TOS_FRAME_TYPE AM_obj_frameTOS_FRAME_BEGIN(AM_obj_frame) { int addr; char type; char state; char* data; char msgbuf[30];}TOS_FRAME_END(AM_obj_frame);

VAR(state) = 0;

Frame Declaration:

Use of frame Variables:

Commands:

void TOS_COMMAND(command_name)(arguments);– Commands can call lower level commands and post tasks.– USE: TOS_POST_COMMAND(BEACON_SUB_power)(0);

void event_name(arguments);– Events can call lower level commands, post tasks and fire higher

level events.

These restrictions prevents cycles in the event/command chain.

Events:

Tasks:

Tasks perform work that is computationally intensive. They run to completion. Can be temporarily interrupted by events. Task declaration: TOS_TASK(task_name){….} Posting a task:

– Asynchronous call to schedule the task for later execution– USE: TOS_POST_TASK(avg_task);

Sample Application

A identity broadcast application:– Sleep for a majority of the time– Wake up periodically and check light sensor

value– Send out identity and light reading– Go back to sleep

Your application must be structured around events: You must ask yourself:

– How will I get the execution context?1) Through the init command.

– Bad idea! Implies you can never sleep.

2) From a command– Good for subcomponents, but not applications.

3) From an event– Good idea!!– This could be a timer event, a message arrived event, a

sensor read completion event, or a hardware interrupt.

Components you will build your application on: Light sensor object (light.h)

– To collect values from the light sensing hardware

Active messaging component (AM.h)– To interface with the network

Clock component (Clock.h) – To provide periodic events

Where to start….

Initializing components– All components implement initialization

methods that are invoked at startup

High level components are required to initialize all subcomponents that they use

We initialize, Photo, AM, and Clock components.

State Machine Diagram

Get_Light

Send_MsgSleep

Clock Event / Light Request Command

Light done event / Msg send command

Msg sent event / Power down command

Declaration of Application//ACCEPTS:char TOS_COMMAND(init)();

//SIGNALS:

//HANDLES:char AM_msg_send_done(char success);void light_done(int reading);void clock_event();

//USES:char TOS_COMMAND(AM_init)();char TOS_COMMAND(AM_send_msg)(int addr,

int type, char* data);void TOS_COMMAND(AM_power)(char mode);void TOS_COMMAND(Photo_init)();void TOS_COMMAND(Photo_read)();void TOS_COMMAND(Clock_init)(char interval);

Let’s code it….

Let’s add a task….

We will also transfer the running average of light readings.

The calculation of this average is computationally intensive and needs to be placed in a task.

We also need to add state to keep track of past average.

State Machine Diagram

Get_Light

Send_MsgSleep

Clock Event / Light Request Command

Thread Schedule / Msg send command

Msg sent event / Power down command

Calc. AverageLight done event / Post Task

Cut to the code…

We need to add:– state management– a task to perform the averaging

How do you ever debug this thing? Run it on your PC!!! The ‘#ifdef FULLPC’ is used to allow the

code to be executed on a PC. Lower levels of networking and UART

components are ‘faked out’ using UNIX networking.

FULLPC_DEBUG is commonly used to print out debugging information.

How do we wire the components together? Currently set-up for use with the Work View

CAD tools Each components has a symbol with pins

corresponding to the events and command it uses or handles

Components are connected by connecting their pins

Structural VHDL is exported and used at compile time

“super.h” is produced from the structural VHDL

How does our messaging protocol work? To send use: char TOS_COMMAND

(AM_send_msg)(int addr,int type, char* data);

To receive messages you must register your event handler in AM_dispatch.c– This function performs the dynamic

dispatching.– Eventually, this function will be automatically

generated based on the handlers you link in

Why these funky macros?

For use with static verification tools– Not yet developed

We will be able to easily analyze event propagation dependencies

How do you know if you code will fit on the device1) GCC will complain at link time

2) Img.file will show you the breakdown of memory usage for your program.

Output of make:

Max text: 0x2000, Max data: 0x200

0x00000c0a _etext=. 0x00800064 _edata=. 0x0080015d _end=.