CS199 Notes for 9/9/2004
Topic: TinyOS Programming II
Scribe:  William Watts
==================

1. Review from previous lectures
--------------------------------
nesC Compiler Path - you can change to TOSSIM with make pc, or to specific 
hardware platform 
make mica2 (mica2 motes), make telos (telos motes).

TinyOS - two kind of components - modules, configurations.  specification 
section declares how components interact with other components, and 
implementation section defines how the components interact with each other.

Short hand used in notes:
p - provides  i - interface  m - module  c - configuration  u - uses 


2. Multiple Wiring
--------------------------
Multiple wiring in the module for ease of coding can be used

example:

App.nc
c App {}

implementation {
   App.SubControl -> Sensor;
   App.SubControl -> Radio;
}


AppM.nc
m App {

    p i StdControl;
    u i StdControl as SubControl;     	
}

implementation {

   command result_t StdControl.init() {
      return call SubControl.init();
    }

   command result_t StdControl.start() {
      return call SubControl.start();
    }

   command result_t StdControl.stop() {
      return call SubControl.stop();
    }
}




3. Parameterisation Of Interfaces
----------------------------------

c Foo {

   p i X[uint8_t];     // this allows for interface X to be represented by 256 different parameters

}

note: the parameter must be an integer type enums are not allowed
command and event parameters are only allowed in component specifications, not within the interface definitions

example:  

c GenericComm {
   p i SendMsg[uint8_t];    // can send 256 different packets that belong to different protocols for instance
   p i ReceiveMsg[uint8_t]; 
}

In the case of an application that receives many different message protocols, may have to write an event handler
in the case that message recieved is not within range of protocol headers. 


m Foo {

   p i SendMsg;

}

implementation {

   command result_t SendMsg.send[uint8_t](...)

}



4. Fan-Out
--------------

A modules command that executes more than one implementation has fan-out.  
This is commonly used in StdControl; it's useful to be able to initialize
a bunch of components from a single call point, and to not have to
specify the number of sub-components in the specification (e.g., uses
StdControl as Sub1; uses StdControl as Sub2).  A 
FAIL may consist of failures on many levels of implementations, but the 
disadvantage of a fanout system is the inability to pinpoint problem 
from embedded application.


5. Timer Interface & uniqueCount
--------------------------------

Timer to control applications

i Timer {

   command result_t start(...);
		 	  stop ();
   event		  fired();		

}

TimerC {
   p i Timer[uint8_t];  // parametrized interface, but next introduce unique parameter
}

C1.Timer -> TimerC.Timer[x];
C2.Timer -> TimerC.Timer[y];
in this case could be hard to find right parameter

nesC has interesting parameter:

unique[char*]  <<<---------- starting at 0, with unique having unsigned integer range 0,....,n-1

int x = unique("test");
int y = unique ("test");
int c = unique ("test");

int x = 0;   // at compile time reserves a namespace, if no once calling test
int y = 1;
int c = 2;


int p = unique("bazaboo");
int q = unique("bazaboo");

int p = 0;
int q = 0;

uniqueCount returns the number n for the total number of parametrized instances
this number is used dimensioning arrays or other data structures that are indexed using numbers returned by unique
this could lead to a means to have dynamic allocation of timers


6. Concurreny issues with synchronous calls from within asynchronous events
---------------------------------------------------------------------------

As we know from previous notes tasks run to completion unless an async event sends up an interupt.  
Can't call a sync command from aysnc event if you want to manipulate data with that call, because tinyOS
will not schedule a sync command.  Thus one needs to post a task from within aysnc event, causing tinyOS to 
schedule the task for execution.  This is how one would manipulate data passed up from ADC hardware, for example


module App {

   u i Timer;
   u i ADC; 
}

implementation {

   task void stopTask() {
       call Timer.stop(); 
   }

   event result_t Timer.fired() {

    call ADC.getData();
   }

   async event restult_t ADC.dataReady(...) {

    post stoptask();  // couldn't call Timer.stop() here to manipulate data or some action call at above location
   }	

}