How 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 components 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_frame TOS_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);

Lets code it….

Lets 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. Average Light 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 device 1)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=. 0x _edata=. 0x d _end=.