How to use TinyOS Jason Hill Rob Szewczyk Alec Woo David Culler An event based execution environment...
-
Upload
jenna-maher -
Category
Documents
-
view
226 -
download
5
Transcript of How to use TinyOS Jason Hill Rob Szewczyk Alec Woo David Culler An event based execution environment...
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=.