David Culler, Jason Hill, Robert Szewczyk, Alec Woo

1
TinyOS Programming Boot CampPart II Tiny OS
Component Design and Tools

• David Culler, Jason Hill, Robert Szewczyk, Alec
  Woo
• U.C. Berkeley
• 2/9/2001

2
Networked Sensor System Challenge
sensors
actuators
storage
network

• Managing multiple concurrent flows
• some with real-time requirements
• Very limited I/O controller hierarchy
• process every bit, or perhaps byte in CPU
• Asynchronous and synchronous devices
• Limited storage and processing
• At very low power

3
TinyOS Execution Contexts
Tasks
events
commands
Interrupts
Hardware
4
TinyOS Storage Model

• Single shared stack
• Each component has a static frame
• only accessible locally (except msg buffers)
• Msg buffers allocated statically by components,
  but shared dynamically by ownership discipline

5
TinyOS Commands and Events
... status TOS_CALL_COMMAND(name)(args) ...
TOS_COMMAND(name)(args) ... return status
TOS_EVENT(name)(args) ... return status
... status TOS_SIGNAL_EVENT(name)(args) ...
6
Commands

• Function call across component boundary
• cause action to be initiated
• bounded amount of work
• cannot block
• always return status (0 gt error)
• component can refuse to perform command
• share call stack and execution context
• command body has access to local frame
• commands may post tasks or call commands
• commands may not signal events

7
Events

• Upcall to notify action has occured
• must do bounded (and small) amount of work
• cannot block
• access local frame, shares stack
• Lowest-level events triggered by hardware
  interrupts
• hardware abstraction components perform critical
  section and enable interrupts
• Events may signal events
• Events may call commands
• Entire event fountain must stay within overall
  application jitter tolerance

8
FSM Programming Style

• Most components are essentially FSMs
• Composed via events and commands
• non-blocking!

9
TASKS

• provide concurrency internal to a component
• longer running operations
• are preempted by events
• able to perform operations beyond event context
• may call commands
• may signal events
• not preempted by tasks

... TOS_POST_TASK(name) ...
void TOS_TASK(name) ...
10
Dynamics of Events and Tasks

• consecutive message sends
• event propagation
• generation of tasks, preempted by events

11
Typical application use of tasks

• event driven data acquisition
• schedule task to do computational portion

char TOS_EVENT(MAGS_DATA_EVENT)(int data)
struct adc_packet pack (struct
adc_packet)(VAR(msg).data) printf("data_event\
n") VAR(reading) data TOS_POST_TASK(FILTER
_DATA) ...
mags.c
12
Filter Magnetometer Data Task
TOS_TASK(FILTER_DATA) int tmp VAR(first)
VAR(first) - (VAR(first) gtgt 5) VAR(first)
VAR(reading) VAR(second) VAR(second) -
(VAR(second) gtgt 5) VAR(second) VAR(first)
gtgt 5 VAR(diff) VAR(diff) - (VAR(diff) gtgt
5) tmp VAR(first) - VAR(second) if(tmp lt
0) tmp -tmp VAR(diff) tmp
if((VAR(diff) gtgt 5) gt 85) TOS_CALL_COMMAND(MAG
S_LEDg_on)() VAR(led_on) 255
13
Tasks in low-level operation

• transmit packet
• send command schedules task to calculate CRC
• task initiated byte-level datapump
• events keep the pump flowing
• receive packet
• receive event schedules task to check CRC
• task signals packet ready if OK
• byte-level tx/rx
• task scheduled to encode/decode each complete
  byte
• must take less time that byte data transfer
• i2c component
• i2c bus has long suspensive operations
• tasks used to create split-phase interface
• events can procede during bus transactions

14
High-level use of tasks

• virtual machine interpreter schedules an
  interpretation task on clock event
• similar for data event
• may be a long running activity
• utilizes many low-level components
• reschedules itself on each virtual machine
  instruction

15
Scheduling

• current sched.c is simple fifo scheduler
• Bounded number of pending tasks
• When idle, shuts down node except clock
• Uses non-blocking task queue data structure

16
Programming tools
17
TOS compile time tools

• tools/desc2objs
• Generates the list of components that need to be
  compiled into an application
• Generates C header files from .comp files
• tools/mkheader
• tools/mksuper_desc
• Generates the super.h linkage file that wires
  components together
• tools/mk_amdisp
• Generates the mappings between handler IDs and
  handler function names for the AM_MSG macro

18
tools/mkheader

• Generates C header files from .comp files
• Usage
• mkheader component_file
• Example
• ./tools/mkheader APP.comp gt APP.h
• Looks for ACCEPTS, USES, SIGNALS, HANDLES section
  of comp files.

19
tools/desc2objs

• Generates the list of components that need to be
  compiled into an application
• Walks the graph of description files to determine
  which components are used by the application
• Looks at .comp files for IMPLEMENTED_BY
  directives
• Usage
• Desc2objs description_file
• Example
• ./tools/desc2objs apps/cnt_to_leds.desc gt
  Makefile.objs
• Output
• CUST_OBJS MAGS.o system/ADC.o system/AM.o
  system/CLOCK.o system/LEDS.o system/MAIN.o
  system/PACKETOBJ.o system/RFM.o
  system/SEC_DED_RADIO_BYTE.o
• HEADER_FILES MAGS.h system/ADC.h system/AM.h
  system/CLOCK.h system/LEDS.h system/MAIN.h
  system/PACKETOBJ.h system/RFM.h
  system/SEC_DED_RADIO_BYTE.h

20
tools/mksuper_desc

• Generates the super.h linkage file that wires
  components together
• Walks the graph of description files to determine
  which components are used by the application
• Looks at .comp files for IMPLEMENTED_BY
  directives and types for each function.
• Automatically generates fan-out code based on
  number and types of connections to each net.
• Wires components together with define.
• Usage mksuper_desc description_file
• ...

21
tools/mksuper_desc (cont.)

• Treats all of the wiring lines from all the
  description files together.
• Example Description file excerpt
• GENERIC_COMMCOMM_SEND_MSG_COMMAND AMAM_SEND_MSG
• CHIRPCHIRP_SEND_MSG GENERIC_COMMCOMM_SEND_MSG
• Example Output
• define COMM_SEND_MSG_COMMAND AM_SEND_MSG_COMMAND
• define CHIRP_SEND_MSG_COMMAND AM_SEND_MSG_COMMAND
  
• define AM_MSG_HANDLER_4_EVENT INT_READING_EVENT

22
tools/mk_amdisp

• Generates the mappings between handler IDs and
  handler function names for the AM_MSG macro
• Sends AM_DISPATCH.mapping through C preprocessor
  and determines the function names of the active
  message types that are being handled.
• Inserts macros that map from function name to
  handler number into am_dispatch.h
• Usage
• mk_amdisp
• Output
• define INT_READING_EVENT__AM_DISPATCH 4
• ? INT_READING_EVENT is handles message type 4.

23
All_headers.c

• Used to type check across all of the component
  descriptions.
• Compiled into a .o but not linked.
• Will reveal errors that arise from
• Wiring the wrong functions together
• Connecting incompatible components together
• Mistakes in .comp files

24
Listen and Inject

• tools/listen. tools/inject.
• Reads from the serial port and prints out packets
  to the screen
• Linux uses .c or .java versions, Windows uses
  .java versions
• Listen reads in packets from the UART and prints
  them out.
• Inject sends out a single packet out the UART and
  then proceeds to print out data that is returned.

25
MakefilePC

• You can compile TinyOS code to run on a PC
• Used as a debugging tool
• Verify application logic and state machine
  transitions before running code on Mote
• Trust me, its worth taking the time to run it on
  the PC!!!
• Can even debug networking applications

26
Project build a component

• Build a few nodes as sens_to_rfm to serve as data
  sources
• Build generic_base to forward all traffic it
  picks up to the host
• Using rfm_to_led as a starting point, construct a
  new application that will aggregate sensor
  readings and forward min,avg,max to the host
• new AGGREGATE.comp and AGGREGATE.c
• int reading handler might build a table of
  neighbor values
• on change or tick, post task to compute aggregate
  and send new active message with aggregate
• new agg.desc