Get Start with TinyOS From technique perspective Tian He CS851 LSDEN

Road Map TinyOS overview How TinyOS works Programming the mote Programming environment guide

Traditional OS Architectures VM I/O Scheduler Application 1 Application 2 Monolith-kernel HW NFS I/O Scheduler Application 1 Micro-kernel HW IPC VM Problem with Large Scale Deeply embedded system.. Large memory & storage requirement Unnecessary and overkill functionality ( address space isolation, complex I/O subsystem , UI ) for our scenario. Relative high system overhead ( e.g, context switch ) Require complex and power consuming hardware support.

Which OS architecture we want Extremely small footprint. Extremely low system overhead. Extremely low power consumption Only thing we need , nothing we don’t

TinyOS Architecture Overview (1) Scheduler TinyOS Application Component I/O COMM . ……. NO Kernel Direct hardware manipulation NO Process management Only one process on the fly. NO Virtual memory Single linear physical address space NO Dynamic memory allocation Assigned at compile time NO Software signal or exception Function Call instead Goal: to strip down memory size and system overhead.

TinyOS Architecture Overview (2) Characteristic of TinyOS No UI, power constrained Unusually application specific HW and SW Multiple flows, concurrency intensive bursts Extremely passive vigilance ( power saving ) Tightly coupled with the application. Main (includes Scheduler) Application (User Components) Simplified TinyOS Architecture Actuating Sensing Active Message Communication Mote Hardware

Road Map TinyOS overview How TinyOS works Programming the mote Programming environment guide

How it works : Scheduling Two-level scheduling ( Event and Task ) Single shared stack ( used by both interrupt and function call) Scheduler is simple FIFO with bounded number of pending task. Task can NOT preempt each other. Event has high priority than Task. Event can preempt task Event can preempt each other , once enabled When idle , scheduler shut down node except for clock Events preempt tasks, tasks do not Events can signal events or call commands Commands don’t signal events Either can post tasks

Simplified Main Loop int main() { TOS_CALL_COMMAND(MAIN_SUB_INIT)(); // initialize the subcomponents TOS_CALL_COMMAND(MAIN_SUB_START)(); //start the subcomponents while(1){ while(!TOS_schedule_task()) { }; //Run until no task in the FIFO Queue asm volatile ("sleep" ::); // save power }

Scheduler in main function int TOS_schedule_task (){ TOS_sched_entry_T TOS_queue[MAX_TASK]; if (EMPTY) return -1; TOS_queue[TOS_sched_full].tp(); TOS_queue[TOS_sched_full].tp = 0; TOS_sched_full = (TOS_sched_full +1 == MAX_TASKS ) ? 0 : TOS_sched_full +1 } int TOS_post ( task_function_pointer) { if( FULL) return –1 ; //Post the associated task to the next free slot TOS_queue[TOS_sched_free ].tp = task_function_pointer; TOS_sched_free = (TOS_sched_free +1 == MAX_TASKS) ? 0 : TOS_sched_free +1

Event implementation Event is independent of FIFO scheduler. Lowest level events are supported directly by Hardware interrupt Software events propagate from lower level to upper level through function call. INTERRUPT(_output_compare2_){ // Hardware Timer Event Handler … TOS_SIGNAL_EVENT(CLOCK_FIRE_EVENT)( ); //Software Event }

How it works: Sensor & Actuator Sensor stack Actuator stack Application Application LEDs Clock UART ADC RFM PHOTO interface Clock Inter. LED interface PHOTO.c Clock.c LED.c ADC Hardware Timer LED Hardware Sensor and actuator are achieved mainly through periodically polling

How it works : Communication Bit Encoding Manchester encoding (1b 2b) DC balancing (4b  6b) SEC_DED forward error correction (8b  17b) Error detection & correction SEC_DED Correct 1b Detect 2b Signal strength Each time a 1 bit is read in, the ADC samples the value of the BBOUT pin. CSMA Detect whether current channel is free to transmit, otherwise wait for random of clock ticks [12,75] clock rate (10kHZ) LFSR One byte message type used to direct packet to handlers Real implementation: if(msg.type == 0) val = Handler0(data); if(msg.type == 1) val = Handler1(data); …. if(msg.type == 255) val = Handler255(data); User need to redefine handler name #define Handler1 XXXX #define Handler5 NULL_FUNC Application Component H1 H2 H3 A simple profiling: If we want to send 60 Byte data, we need to invoke: Messaging layer 1 times Packet layer >2 times byte layer > 60 times RFM > 480 times Application Packaging Dividing/Combine Routing Echo ; Base_station Relay;…. Special address 0xff = Broadcast Address 0x7E = UART interface 30 Byte Fix length Packet CRC check 16 bit CRC check, Drops packet if fails Redundancy transmit transmitted 3 times Content-based routing Consensus algorithm Location Service Tracking Sensor data processing …… AM Dispatcher messaging Simplex transceiver We can Set Operation Mode (TX/RX) Set Sampling Rate Receive one Bit Transmit one Bit Notify TX/RX is finished Shut down RFM (1/10th) Messaging Radio Packet packet byte Radio byte bit RFM

Road Map TinyOS overview How TinyOS works Programming the mote Programming environment guide

Programming the Mote (1) Program = graph of components + FIFO scheduler. Graph of components = individual components + relations Individual components = command/event interface + behavior Behavior = Event + Command + Internal Tasks

Programming the Mote (2) Individual component Component interface (.comp) Commands that it accepts(implemented) Commands that it uses Events that it signals Events that it handles Component implementation (.c) Functions that implement interface Frame: internal state Tasks: internal concurrency Uses only internal namespace A typical TinyOS component Commands Events Internal Tasks Messaging Component Internal State

Programming the Mote (3) Relations Component dependence (.desc) Glue the components Denote the dependence among component. Mapping the interface between the component. MAIN COUNTER CLOCK LEDS

Declare and access variable TOS_FRAME_BEGIN, TOS_FRAME_END to declare a component frame example VAR(foo) to access a variable (foo) in the frame TOS_FRAME_BEGIN(COUNTER_frame) { char state; } TOS_FRAME_END(COUNTER_frame); Real implementation: #define TOS_FRAME_BEGIN(frame_type) typedef struct #define TOS_FRAME_END(frame_type) frame_type; static frame_type TOS_MY_Frame; #define VAR(x) TOS_MY_Frame.x

TinyOS Commands,Events and Tasks { ... status = TOS_CALL_COMMAND(name)(args) } Function Call TOS_EVENT(name)(args) { ... return status; } { ... status = TOS_SIGNAL_EVENT(name)(args) } Function call TOS_COMMAND(name)(args) { ... return status; } TOS_TASK(name)(args) { ... return status; } { ... TOS_POST_TASK(name)(args) } FIFO Queue Fun. Pointer Real implementation: #define TOS_COMMAND(command_name) TOS_CALL_COMMAND(command_name) #define TOS_EVENT(event_name) TOS_SIGNAL_EVENT(event_name)

TinyOS Application by Composition Application = graph of components + scheduler sensing application application Routing Layer routing Messaging Layer messaging Radio Packet UART Packet packet byte Radio byte UART byte Temp photo SW RFM HW bit ADC i2c clocks

Composing applications from components Simple counter program .c file implement the interface .desc file describe the relationships between the component Interfaces are defined through .COMP File generic init interface clock interface output interface CLOCK INT_TO_LEDS MAIN COUNTER main_sub_init counter_init main_sub_start counter_start counter_sub_clock_init clock_init clock_event clock_fire_event counter_sub_output_init int_to_leds_init counter_output int_to_leds_output

Files for this simple application Seven Files Describe the relation between compoents: cnt_to_led.desc Describe three components ( two files each) Counter.c Counter.comp Clock.c Clock.comp INT_TO_LED.c INT_TO_LED.comp

Composing applications from components Example: apps/cnt_to_led.desc include modules{ MAIN; COUNTER; INT_TO_LEDS; CLOCK; }; MAIN:MAIN_SUB_INIT COUNTER:COUNTER_INIT MAIN:MAIN_SUB_START COUNTER:COUNTER_START COUNTER:COUNTER_CLOCK_EVENT CLOCK:CLOCK_FIRE_EVENT COUNTER:COUNTER_SUB_CLOCK_INIT CLOCK:CLOCK_INIT COUNTER:COUNTER_SUB_OUTPUT_INIT INT_TO_LEDS:INT_TO_LEDS_INIT COUNTER:COUNTER_OUTPUT INT_TO_LEDS:INT_TO_LEDS_OUTPUT MAIN main_sub_init counter_init COUNTER apps/cnt_to_led.desc

.comp component interface file TOS_MODULE COUNTER; ACCEPTS{ char COUNTER_START(void); char COUNTER_INIT(void); }; HANDLES{ void COUNTER_CLOCK_EVENT(void); USES{ //need following service provide by other component char COUNTER_SUB_CLOCK_INIT(char interval, char scale); char COUNTER_SUB_OUTPUT_INIT(); char COUNTER_OUTPUT(int value); SIGNALS{ // no signal it will generate To be implemented in .c file COUNTER.comp

Implemention: COUNTER.c #include "tos.h" #include "COUNTER.h" //Frame Declaration #define TOS_FRAME_TYPE COUNTER_frame TOS_FRAME_BEGIN(COUNTER_frame) { char state; } TOS_FRAME_END(COUNTER_frame); //Events handled /* Clock Event Handler: */ void TOS_EVENT(COUNTER_CLOCK_EVENT)(){ VAR(state) ++; TOS_CALL_COMMAND(COUNTER_OUTPUT)(VAR(state)); /* update LED state */ } COUNTER.c

COUNTER.c - rudimentary event processing //Commands accepted char TOS_COMMAND(COUNTER_INIT)(){ VAR(state) = 0; /* initialize output component */ return TOS_CALL_COMMAND(COUNTER_SUB_OUTPUT_INIT)(); } char TOS_COMMAND(COUNTER_START)(){ /* initialize clock component and start event processing */ return TOS_CALL_COMMAND(COUNTER_SUB_CLOCK_INIT)(tick2ps);

More complicate example CLOCK MAIN COUNTER hardware.h AM PACKETOBJ SEC_DED_RADIO_BYTE RFM INT_TO_RFM Main.c sched.c Counter.c Counter.comp Clock.c Clock.comp INT_TO_RFM.c INT_TO_RFM.comp am.c am.comp PACKETOBJ.c PACKETOBJ.comp SEC_DED_RADIO_BYTE.c ...comp RFM.c ...comp Relationship description Cnt_to_rfm.desc

Low level Mote Programming Detail ATMEL 90S8535 can respond to 16 different interrupt sources. Avr-gcc pre-defines interrupt symbols and interrupt jump table

Low level Mote Programming Detail To establish interrupt hander: 1. include the following headers in your C file #include "io-avr.h" #include "signal.h" #include "interrupt.h” 2. Write following subroutine: INTERRUPT(_uart_recv_) { ... } // Preemptive Event SIGNAL(_uart_recv_) { ... } //non-preemptive Event Alternative : sei() and cei() macros can enable and disable interrupt

Low level Mote Programming Detail Vector jump table (16) SP

Road Map TinyOS overview How TinyOS works Programming the mote Programming environment guide

Programming Environment Lab Location: Olsson 018 Platform: cygwin on top of Windows 2000 Software: perl, gcc, java, atmel tools ,cygwin Mote-to-mote communication Program Code Mote-PC communication

Steps Write Component ( .c and .comp file ) Write Relation ( .desc file ) Run on Mote Modify makefile Set GROUP_ID redefine Macro: DESC = XXXXX.desc Build Make clean ; make Upload the image into Mote and run Make install_windows Run on PC Modify makefilePC Build: make clean ; make -f makefilePC Run: main < node_ID > Details to upload Image to Mote transcode your executable into Motorola S-record format: avr-objcopy --output-target=srec ledblink ledblink.srec erase the flash on the mote uisp -dapa -dno-poll --erase transfer the program to the mote uisp -dapa -dno-poll --upload if=ledblink.srec verify the flash uisp -dapa -dno-poll --verify if=ledblink.srec

Programming & debug Tools Makefile Create super.h from DESC and COMP file, then link all component into one single image that is executable by ATMEL AVR AT90S2343 processor. MakefilePC It’s for debug purpose and run on the PC gdb main <nod_ID> Serial Port listener -- monitor traffic between mote and PC.

RF_Simulation Tools Simulate Radio communication with ConnectionManager program RFM and UART replaced by sockets RFM connects to “127.0.0.1:9876” UART connects to “127.0.0.1:8765” add_conn(ID1, ID2) creates a bi-directional link between mote with ID1 and ID2 3 add_conn(1, 2); add_conn(2, 3); add_conn(3, 4); add_conn(4, 2); 1 2 4

Possible Project on Mote Test-Bed Redesign the FIFO scheduler Redesign MAC Layer from CSMA to …… Ultra-Sound Device for location service ? Distributed ConnectionManager for large scale Sim. New Ad Hoc network algorithm New application design (How to use mote novelty)

Related URL http://tinyos.millennium.berkeley.edu