How to use TinyOS

1
How to use TinyOS
An event based execution environment for
Networked Sensors

• Jason Hill
• Rob Szewczyk
• Alec Woo
• David Culler

2
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

3
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.

4
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)()
5
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

6
Example Frame Declaration
Frame Declaration
define TOS_FRAME_TYPE AM_obj_frame TOS_FRAME_BEGI
N(AM_obj_frame) int addr char type
char state char data char
msgbuf30 TOS_FRAME_END(AM_obj_frame)
Use of frame Variables
VAR(state) 0
7
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
8
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)

9
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

10
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.

11
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

12
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.

13
State Machine Diagram
Get_Light
Light done event / Msg send command
Clock Event / Light Request Command
Send_Msg
Sleep
Msg sent event / Power down command
14
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)
15
Lets code it.
16
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.

17
State Machine Diagram
Calc. Average
Get_Light
Light done event / Post Task
Thread Schedule / Msg send command
Clock Event / Light Request Command
Send_Msg
Sleep
Msg sent event / Power down command
18
Cut to the code

• We need to add
• state management
• a task to perform the averaging

19
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.

20
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

21
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

22
Why these funky macros?

• For use with static verification tools
• Not yet developed
• We will be able to easily analyze event
  propagation dependencies

23
How do you know if you code will fit on the device

• GCC will complain at link time
• 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.