[Tinyos-beta-commits] CVS: tinyos-1.x/beta/teps/txt tep1.txt, 1.5, 1.6 tep101.txt, 1.16, 1.17 tep102.txt, 1.16, 1.17 tep106.txt, 1.13, 1.14 tep107.txt, 1.7, 1.8 tep108.txt, 1.6, 1.7 tep109.txt, 1.6, 1.7 tep110.txt, 1.4, 1.5 tep111.txt, 1.2, 1.3 tep112.txt, 1.5, 1.6 tep113.txt, 1.1, 1.2 tep3.txt, 1.11, 1.12

[Phil Levis]

Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/txt
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14086/txt

Modified Files:
	tep1.txt tep101.txt tep102.txt tep106.txt tep107.txt 
	tep108.txt tep109.txt tep110.txt tep111.txt tep112.txt 
	tep113.txt tep3.txt 
Log Message:
Updates.




Index: tep102.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep102.txt,v
retrieving revision 1.16
retrieving revision 1.17
diff -C2 -d -r1.16 -r1.17
*** tep102.txt	11 Oct 2005 19:32:17 -0000	1.16
--- tep102.txt	31 Oct 2005 22:31:28 -0000	1.17
***************
*** 110,113 ****
--- 110,114 ----
  * LocalTime
  * Timer
+ * TimerMilliC (for OSKI support)
  
  LocalTime and Timer are HIL versions of Counter and Alarm.
***************
*** 117,125 ****
  primarily by user applications and use a fixed width of 32-bits.
  
- This HAL component MUST also exist:
- 
- * HalTimerMilliC
- 
- 
  Precision and Width
  ====================================================================
--- 118,121 ----
***************
*** 174,178 ****
  wire to any timer in the system trivially.
  
! One sample set of HPL level interfaces follows:
   
    interface HplTimer<timer_size>
--- 170,174 ----
  wire to any timer in the system trivially.
  
! One sample set of HPL level interfaces follows::
   
    interface HplTimer<timer_size>
***************
*** 689,701 ****
  
  
! HalTimerMilliC
  --------------------------------------------------------------------
  
! HalTimerMilliC MUST provide Init and Timer<TMilli> as
! TimerMilli[uint8_t num].  HalTimerMilliC is used by OSKI to
! implement the generic component TimerMilliC that allocates a new,
! virtual timer with each instantiation.  ::
  
!   configuration HalTimerMilliC
    {
      provides interface Init;
--- 685,697 ----
  
  
! TimerMilliC
  --------------------------------------------------------------------
  
! TimerMilliC MUST provide Init and Timer<TMilli> as TimerMilli[uint8_t
! num].  TimerMilliC is used by OSKI to implement the generic component
! TimerMilliC that allocates a new, virtual timer with each
! instantiation.  ::
  
!   configuration TimerMilliC
    {
      provides interface Init;



Index: tep108.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep108.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** tep108.txt	6 Jul 2005 23:22:03 -0000	1.6
--- tep108.txt	31 Oct 2005 22:31:28 -0000	1.7
***************
*** 74,90 ****
  
  - Resource reservation: the service must be reserved before use, via the
! Resource interface. This approach is described in Section 3.  Because many
! services will have similar approaches to resource sharing (e.g.,
! round-robin, or priority-based), TinyOS includes default arbiters
! implementing various resource sharing policies. These arbiters are
! described in Section 4.
  
  - Request queuing: requests from different clients are queued and handled
! in some (service-dependent) order. This approach is described in Section 5.
  
  - Resource virtualisation: the service is virtualised so as to support an
! arbitrary number of clients - a typical example is the Timer service. From
! a programming perspective, this behaves similarly to resource queuing and
! is therefore also described in Section 5.
  
  Note that request queuing and resource virtualisation may need to store
--- 74,90 ----
  
  - Resource reservation: the service must be reserved before use, via the
!   Resource interface. This approach is described in Section 3.  Because many
!   services will have similar approaches to resource sharing (e.g.,
!   round-robin, or priority-based), TinyOS includes default arbiters
!   implementing various resource sharing policies. These arbiters are
!   described in Section 4.
  
  - Request queuing: requests from different clients are queued and handled
!   in some (service-dependent) order. This approach is described in Section 5.
  
  - Resource virtualisation: the service is virtualised so as to support an
!   arbitrary number of clients - a typical example is the Timer service. From 
!   a programming perspective, this behaves similarly to resource queuing and
!   is therefore also described in Section 5.
  
  Note that request queuing and resource virtualisation may need to store
***************
*** 100,139 ****
  The resource interface is defined as follows:
  
!   interface Resource {
!     /**
!      * Request access to a shared resource. You must call release()
!      * when you are done with it.
!      * @return SUCCESS Request accepted. The granted() event will
!      *           be signaled when you have the resource.
!      *         EBUSY You have already requested this resource via this
!      *           interface.    
!      */
!     async command error_t request();
! 
!     /**
!      * Request immediate access to a shared resource. You must call 
!      * release() when you are done with it. 
!      * @return SUCCESS You now have the resource.
!      *         EBUSY The resource is busy.
!      */
!     async command error_t immediateRequest();
! 
!     /**
!      * You have received access to this resource. Note that this event
!      * is NOT signaled when immediateRequest() succeeds.
!      */
!     event void granted();
! 
!     /**
!      * Release a shared resource you previously acquired.
!      */
!     async command void release();
! 
!     /**
!      * Some other component has requested this resource. You might
!      * want to consider releasing it.
!      */
!     event void requested();
!   }
  
  This Resource interface is offered as a parameterised interface by services
--- 100,139 ----
  The resource interface is defined as follows:
  
! |  ``interface Resource {``
! |    ``/**``
! |     ``* Request access to a shared resource. You must call release()``
! |     ``* when you are done with it.``
! |     ``* @return SUCCESS Request accepted. The granted() event will``
! |     ``*           be signaled when you have the resource.``
! |     ``*         EBUSY You have already requested this resource via this``
! |     ``*           interface.``
! |     ``*/``
! |    ``async command error_t request();``
! |
! |    ``/**``
! |     ``* Request immediate access to a shared resource. You must call``
! |     ``* release() when you are done with it.``
! |     ``* @return SUCCESS You now have the resource.``
! |     ``*         EBUSY The resource is busy.``
! |     ``*/``
! |    ``async command error_t immediateRequest();``
! |
! |    ``/**``
! |     ``* You have received access to this resource. Note that this event``
! |     ``* is NOT signaled when immediateRequest() succeeds.``
! |     ``*/``
! |    ``event void granted();``
! |
! |    ``/**``
! |     ``* Release a shared resource you previously acquired.``
! |     ``*/``
! |    ``async command void release();``
! |
! |   ``/**``
! |    ``* Some other component has requested this resource. You might``
! |    ``* want to consider releasing it.``
! |    ``*/``
! |    ``event void requested();``
! |  ``}``
  
  This Resource interface is offered as a parameterised interface by services
***************
*** 144,171 ****
  like this:
  
!   #include "I2CPacketC.h"
!   configuration I2CPacketC {
!     provides {
!       /**
!        * For reserving the I2C bus. 'id' is the client id, obtained
!        * via unique(I2C_RESOURCE)
!        */
!       interface Resource[uint8_t id];
! 
!       /**
!        * Actual I2C packet interface. 'busId' is the I2C
!        * bus identifer of the device you wish to use.
!        */
!       interface I2CPacket[uint8_t busId];
!     }
!   } ...
  
  where I2CPacketC.h contains the #define for the resource:
-   #ifndef I2CPACKETC_H
-   #define I2CPACKETC_H
- 
-   #define I2CPACKET_RESOURCE "I2CPacket.Resource"
  
!   #endif
  
  The #define for the unique string must be placed in a separate file
--- 144,172 ----
  like this:
  
! |  ``includes I2CPacketC;``
! |  ``configuration I2CPacketC {``
! |    ``provides {``
! |      ``/**``
! |       ``* For reserving the I2C bus. 'id' is the client id, obtained``
! |       ``* via unique(I2C_RESOURCE)``
! |       ``*/``
! |      ``interface Resource[uint8_t id];``
! |
! |      ``/**``
! |       ``* Actual I2C packet interface. 'busId' is the I2C``
! |       ``* bus identifer of the device you wish to use.``
! |       ``*/``
! |      ``interface I2CPacket[uint8_t busId];``
! |    ``}``
! |  ``} ...``
  
  where I2CPacketC.h contains the #define for the resource:
  
! |  ``#ifndef I2CPACKETC_H``
! |  ``#define I2CPACKETC_H``
! |
! |  ``#define I2CPACKET_RESOURCE "I2CPacket.Resource"``
! |
! |  ``#endif``
  
  The #define for the unique string must be placed in a separate file
***************
*** 175,192 ****
  
  Clients of the I2C service would use it as follows:
-   module I2CUserM {
-     uses interface Resource as I2CResource;
-     uses interface I2CPacket;
-   } ...
- 
  
!   #include "I2CPacketC.h"
!   configuration I2CUserC { }
!   implementation {
!     components I2CUserM, I2CPacketC;
! 
!     I2CUserM.I2CResource -> I2CPacketC.Resource[unique(I2C_RESOURCE)];
!     I2CUserM.I2CPacket -> I2CPacket.I2CPacket[0x73]; // using I2C device 0x73
!   }
  
  A final note: in some cases, resource reservation will correspond to
--- 176,193 ----
  
  Clients of the I2C service would use it as follows:
  
! |  ``module I2CUserM {``
! |    ``uses interface Resource as I2CResource;``
! |    ``uses interface I2CPacket;``
! |  ``} ...``
! |
! |  ``includes I2CPacketC;``
! |  ``configuration I2CUserC { }``
! |  ``implementation {``
! |    ``components I2CUserM, I2CPacketC;``
! |
! |    ``I2CUserM.I2CResource -> I2CPacketC.Resource[unique(I2C_RESOURCE)];``
! |    ``I2CUserM.I2CPacket -> I2CPacket.I2CPacket[0x73]; // using I2C device 0x73``
! |  ``}``
  
  A final note: in some cases, resource reservation will correspond to
***************
*** 208,229 ****
  This could be done as follows (the UART and SPI components are omitted, they
  are similar to I2CC):
  I2CC.nc (a low-level I2C component):
- #define I2C_RESOURCE MSP_BUS_RESOURCE
- configuration I2CC {
-   provides interface Resource[uint8_t clientId];
-   provides interface I2C;
- }
- implementation {
-   components MspBusC, I2CM;
  
!   Resource = MspBusC.Resource;
!   I2C = I2CM.I2C;
! }
  
  MspBusC (the arbiter for the MSP bus):
! #define MSP_BUS_RESOURCE "MspBus.Resource"
! configuration {
!   provides interface Resource[uint8_t clientId];
! } ...
  
  4. Default arbiters
--- 209,233 ----
  This could be done as follows (the UART and SPI components are omitted, they
  are similar to I2CC):
+ 
  I2CC.nc (a low-level I2C component):
  
! | ``#define I2C_RESOURCE MSP_BUS_RESOURCE``
! | ``configuration I2CC {``
! |    ``provides interface Resource[uint8_t clientId];``
! |    ``provides interface I2C;``
! | ``}``
! | ``implementation {``
! |  ``components MspBusC, I2CM;``
! |
! |  ``Resource = MspBusC.Resource;``
! |  ``I2C = I2CM.I2C;``
! | ``}``
  
  MspBusC (the arbiter for the MSP bus):
! 
! | ``#define MSP_BUS_RESOURCE "MspBus.Resource"``
! | ``configuration {``
! |   ``provides interface Resource[uint8_t clientId];``
! | ``} ...``
  
  4. Default arbiters
***************
*** 238,254 ****
  current set of resource allocation:
  
! interface ResourceUser {
!   /**
!    * Check whether resource is allocated.
!    * @returns TRUE if the resource is currently allocated, FALSE otherwise.
!    */
!   command bool inUse();
! 
!   /**
!    * Return id of client currently using the resource. Meaningless if
!    * inUse() returns FALSE.
!    */
!   command uint8_t user();
! }
  
  ResourceUser can be used by the service implementation, e.g., to refuse
--- 242,258 ----
  current set of resource allocation:
  
! | ``interface ResourceUser {``
! |  ``/**``
! |   ``* Check whether resource is allocated.``
! |   ``* @returns TRUE if the resource is currently allocated, FALSE otherwise.``
! |   ``*/``
! |   ``command bool inUse();``
! | 
! |   ``/**``
! |    ``* Return id of client currently using the resource. Meaningless if``
! |    ``* inUse() returns FALSE.``
! |    ``*/``
! |   ``command uint8_t user();``
! | ``}``
  
  ResourceUser can be used by the service implementation, e.g., to refuse
***************
*** 257,267 ****
  
  The RoundRobinArbiter provides round-robin arbitration:
- generic component RoundRobinArbiter {
-   provides interface Resource[uin8_t id];
-   provides interface ResourceUser;
- }
  
! [[There will be other arbiters here, I presume. For instance, priority-based.
!   Or for services which support >1 outstanding request.]]
  
  5. Request queuing and resource virtualisation
--- 261,273 ----
  
  The RoundRobinArbiter provides round-robin arbitration:
  
! | ``generic component RoundRobinArbiter {``
! |   ``provides interface Resource[uin8_t id];``
! |   ``provides interface ResourceUser;``
! | ``}``
! 
! There is also a First-Come-First-Served (Fcfs) arbiter. RoundRobin
! grants the resource based on a fixed order (ids), while Fcfs grants it
! based on request order.
  
  5. Request queuing and resource virtualisation
***************
*** 277,297 ****
  As an example, the Timer services looks as follows:
  
! #define TIMER_SERVICE "TimerC"
! configuration TimerC {
!   provides interface Timer<TMilli>[uint8_t id];
!   provides interface Timer<TM32khz>[uint8_t id];
! } ...
  
  and clients use it as follows:
! module TimerUserM {
!   uses interface Timer<TMilli> as MyTimer;
! } ...
! 
! configuration TimerUserC { }
! implementation {
!   components TimerUserM, TimerC;
  
!   TimerUserM.MyTimer -> TimerC.Timer[unique(TIMER_SERVICE)];
! }
  
  The difference between queuing of requests and virtualisation is only
--- 283,301 ----
  As an example, the Timer services looks as follows:
  
! | ``configuration TimerMillicC {``
! |   ``provides interface Timer<TMilli>[uint8_t id];``
! | ``} ...``
  
  and clients use it as follows:
! | ``module TimerUserM {``
! |   ``uses interface Timer<TMilli> as MyTimer;``
! | ``} ...``
  
! | ``configuration TimerUserC { }``
! | ``implementation {``
! |   ``components TimerUserM, TimerC;``
! |
! |   ``TimerUserM.MyTimer -> TimerC.Timer[unique(TIMER_SERVICE)];``
! | ``}``
  
  The difference between queuing of requests and virtualisation is only
***************
*** 303,312 ****
  requests.  Such components will use the same id for their service and
  resource interfaces, e.g.:
! #define ADC_RESOURCE "Adc.resource"
! #define ADC_SERVICE ADC_RESOURCE
! configuration ADCC {
!   provides interface ADC[uint8_t id];
!   provides interface Resource[uint8_t id];
! } ...
  
  
--- 307,317 ----
  requests.  Such components will use the same id for their service and
  resource interfaces, e.g.:
! 
! | ``#define ADC_RESOURCE "Adc.resource"``
! | ``#define ADC_SERVICE ADC_RESOURCE``
! | ``configuration ADCC {``
! |   ``provides interface ADC[uint8_t id];``
! |   ``provides interface Resource[uint8_t id];``
! | ``} ...``
  
  
***************
*** 331,340 ****
  |
  | Philip Levis
! | 467 Soda Hall
! | UC Berkeley
! | Berkeley, CA 94720
  |
! | phone - +1 510 290 5283
! | email - pal at cs.berkeley.edu
  |
  | Kevin Klues
--- 336,345 ----
  |
  | Philip Levis
! | 358 Gates Hall
! | Stanford University
! | Stanford, CA 94305-9030
  |
! | phone - +1 650 725 9046
! | email - pal at cs.stanford.edu
  |
  | Kevin Klues

Index: tep109.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep109.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** tep109.txt	19 Oct 2005 21:35:25 -0000	1.6
--- tep109.txt	31 Oct 2005 22:31:28 -0000	1.7
***************
*** 45,83 ****
  ====================================================================
  
! - A sensor board MUST have a unique name, composed of letters, numbers and
! underscores. Case is significant, but two sensor boards MUST differ in more
! than case. This is necessary to support platforms where filename case 
! differences are not significant. We will use SBOARD to denote the sensor board
! name in the rest of this document.
  
  - Each sensor board MUST have its own directory named SBOARD; default TinyOS
! sensor boards are placed in tinyos-2.x/tos/sensorboards, but
! sensor board directories can be placed anywhere as long as the nesC compiler
! receives a `-I' directive pointing to the sensor board's directory.
  
! - Each sensor board directory MUST contain a `.sensor' file. This file
! is a perl script which contains any additional compiler settings needed for
! this sensor board (this file will be empty in many cases). 
  
  - If the sensor board wishes to define any C types or constants, it SHOULD
! place these in a file named SBOARD.h in the sensor board's directory.
  
  - The sensor board directory SHOULD contain sensor board components
! for accessing each sensor on the sensor board. The conventions for these
! components are detailed in Section 3.
  
  - A sensor board MAY include additional components providing alternative or
! higher-level interfaces to the sensors (e.g., for TinyDB). These components
! are beyond the scope of this document. 
  
  - Finally, the sensor board MAY contain any number of components,
! interfaces, C files, etc for internal use. To avoid name collisions, all
! externally visible names (interface types, components, C constants and
! types) used for internal purposes SHOULD be prefixed with SBOARD. All such
! components should end in P.
  
! A simple example: the basic sensor board is named `basicsb', it's directory
! is `tinyos-2.x/tos/sensorboards/basicsb'. It has no `basicsb.h' file and
! its `.sensor' file is empty. It has two components, `Photo'C and `TempC'
  representing its light and temperature sensors.
  
--- 45,83 ----
  ====================================================================
  
! - A sensor board MUST have a unique name, composed of letters, numbers
!   and underscores. Case is significant, but two sensor boards MUST
!   differ in more than case. This is necessary to support platforms where
!   filename case differences are not significant. We will use SBOARD to
!   denote the sensor board name in the rest of this document.
  
  - Each sensor board MUST have its own directory named SBOARD; default TinyOS
!   sensor boards are placed in tinyos-2.x/tos/sensorboards, but
!   sensor board directories can be placed anywhere as long as the nesC compiler
!   receives a `-I` directive pointing to the sensor board's directory.
  
! - Each sensor board directory MUST contain a `.sensor` file. This file
!   is a perl script which contains any additional compiler settings needed for
!   this sensor board (this file will be empty in many cases). 
  
  - If the sensor board wishes to define any C types or constants, it SHOULD
!   place these in a file named SBOARD.h in the sensor board's directory.
  
  - The sensor board directory SHOULD contain sensor board components
!   for accessing each sensor on the sensor board. The conventions for these
!   components are detailed in Section 3.
  
  - A sensor board MAY include additional components providing alternative or
!   higher-level interfaces to the sensors (e.g., for TinyDB). These components
!   are beyond the scope of this document. 
  
  - Finally, the sensor board MAY contain any number of components,
!   interfaces, C files, etc for internal use. To avoid name collisions, all
!   externally visible names (interface types, components, C constants and
!   types) used for internal purposes SHOULD be prefixed with SBOARD. All such
!   components should end in P.
  
! A simple example: the basic sensor board is named `basicsb`, it's directory
! is `tinyos-2.x/tos/sensorboards/basicsb`. It has no `basicsb.h` file and
! its `.sensor` file is empty. It has two components, `PhotoC` and `TempC`
  representing its light and temperature sensors.
  
***************
*** 91,109 ****
  
  A sensor board component MUST provide:
! - An `Init' interface.
! - A `StdControl' or `SplitControl' interface for power management.
! - A non-empty set of `AcquireData' interfaces for sampling.
  
  A sensor board component MAY provide:
! - Some `CalibrationData' interfaces for obtaining calibration data.
    A calibration interface for a sensor accessed via interface X should
    be called XCalibration.
! - Some `AcquireDataNow' and `AcquireDataBuffered' interfaces, for high-speed 
    or low-latency data acquisition.
  - Any other appropriate interface.
  
! The `CalibrationData' interface is shown below, while `AcquireData',
! `AcquireDataNow' and `AcquireDataBuffered' are in TEP 101. The
! `AcquireData' interface returns uinterpreted 16-bit data. This might
  represent an A/D conversion result, a counter, etc. The optional
  calibration interface returns uninterpreted, arbitrary-size data.
--- 91,115 ----
  
  A sensor board component MUST provide:
! 
! - An `Init` interface.
! 
! - A `StdControl` or `SplitControl` interface for power management.
! 
! - A non-empty set of `AcquireData` interfaces for sampling.
  
  A sensor board component MAY provide:
! 
! - Some `CalibrationData` interfaces for obtaining calibration data.
    A calibration interface for a sensor accessed via interface X should
    be called XCalibration.
! 
! - Some `AcquireDataNow` and `AcquireDataBuffered` interfaces, for high-speed 
    or low-latency data acquisition.
+ 
  - Any other appropriate interface.
  
! The `CalibrationData` interface is shown below, while `AcquireData`,
! `AcquireDataNow` and `AcquireDataBuffered` are in TEP 101. The
! `AcquireData` interface returns uinterpreted 16-bit data. This might
  represent an A/D conversion result, a counter, etc. The optional
  calibration interface returns uninterpreted, arbitrary-size data.
***************
*** 114,205 ****
  SHOULD be provided in separate components.
  
!   interface CalibrationData {
!     /* Collect uninterpreted calibration data from a sensor */
! 
!     /** Request calibration data
!      *  @return SUCCESS if request accepted, FAIL if it is refused
!      *    data error will be signaled if SUCCESS is returned
!      */
!     command result_t get();
! 
!     /** Returns calibration data
!      * @param x Pointer to (uinterpreted) calibration data. This data
!      *   must not be modified.
!      * @param len Length of calibration data
!      * @return Ignored.
!      */
!     event result_t data(const void *x, uint8_t len);
!   }
! 
  
  Some common setups for sensor board components are:
  
! - A single `AcquireData' interface. This is probably the most common case,
! where a single component corresponds to a single physical sensor, e.g., for
! light, temperature, pressure and there is no expectation of high sample
! rates.
! 
! - Multiple `AcquireData' interfaces. Some sensors might be strongly
! related, e.g., the axes of an accelerometer.  A single component could then
! provide a sensor interface for each axis. For instance, a 2-axis
! accelerometer which can be sampled at high speed, and which has some
! calibration data might be declared with:
  
!   configuration Accelerometer2D {
!     provides {
!       interface StdControl
!       interface AcquireData as AccelX;
!       interface AcquireDataNow as AccelXSingle;
!       interface AcquireDataBuffered as AccelXMultiple;
!       interface CalibrationData as AccelXCalibration;
  
!       interface AcquireData as AccelY;
!       interface AcquireDataNow as AccelYSingle;
!       interface AcquireDataBuffered as AccelYMultiple;
!       interface CalibrationData as AccelYCalibration;
!     }
!   }
  
! - A parameterised `AcquireData' interface. If a sensor board has multiple
! similar sensors, it may make sense to provide a single component to access
! all of these, using a parameterised `AcquireData' interface. For instance,
! a general purpose sensor board with multiple A/D channels might provide an
! `AcquireData' interface parameterised by the A/D channel id.
  
  - In all of these examples, if high-speed sampling makes sensor for the
! sensor (e.g., a microphone), and the sensor is connected in a way that
! supports high-frequency and/or low-latency access (e.g., via an 
! on-microcontroller A/D converter), the component should offer 
! 'AcquireDataNow' and 'AcquireDataBuffered' interfaces.
  
  Sensor board components MUST respect the following conventions
! on the use of the `Init', `StdControl',  and `SplitControl' 
! interfaces.  These are given assuming `StdControl' is used, but the
! behaviour with `SplitControl' is identical except that `start' and `stop'
! are not considered complete until the `startDone' and `stopDone' events are
  signaled. The conventions are:
  
! 1) `Init.init': must be called at mote boot time.
  
! 2) `StdControl.start': ensure the sensor corresponding to this component is
      ready for use. For instance, this should power-up the sensor if
!     necessary. The application can call `getData' once `StdControl.start'
      completes.
  
      If a sensor takes a while to power-up, the sensor board implementer can
!     either use a `SplitControl' interface and signal `startDone'
!     when the sensor is ready for use, or delay `dataReady' events
      until the sensor is ready. The former choice is preferable.
  
! 3) `StdControl.stop': put the sensor in a low-power mode. 
! `StdControl.start' must be called before any further readings 
! are taken. The behaviour of calls to `StdControl.stop' during
! sampling (i.e., when an `dataReady' event is going to be
! signaled) is undefined.
  
! `.sensor' File
  ====================================================================
  
! This file is a perl script which gets executed as part of the `ncc'
  nesC compiler frontend. It can add or modify any compile-time options 
  necessary for a particular sensor board. It MAY modify the following perl
--- 120,210 ----
  SHOULD be provided in separate components.
  
! |  ``interface CalibrationData {``
! |    ``/* Collect uninterpreted calibration data from a sensor */``
! |
! |    ``/** Request calibration data``
! |     ``*  @return SUCCESS if request accepted, FAIL if it is refused``
! |     ``*    data error will be signaled if SUCCESS is returned``
! |     ``*/``
! |    ``command result_t get();``
! |
! |   ``/** Returns calibration data``
! |    ``* @param x Pointer to (uinterpreted) calibration data. This data``
! |    ``*   must not be modified.``
! |    ``* @param len Length of calibration data``
! |    ``* @return Ignored.``
! |    ``*/``
! |   ``event result_t data(const void *x, uint8_t len);``
! | ``}``
  
  Some common setups for sensor board components are:
  
! - A single `AcquireData` interface. This is probably the most common case,
!   where a single component corresponds to a single physical sensor, e.g., for
!   light, temperature, pressure and there is no expectation of high sample
!   rates.
  
! - Multiple `AcquireData` interfaces. Some sensors might be strongly
!   related, e.g., the axes of an accelerometer.  A single component could then
!   provide a sensor interface for each axis. For instance, a 2-axis
!   accelerometer which can be sampled at high speed, and which has some
!   calibration data might be declared with:
  
! |  ``configuration Accelerometer2D {``
! |    ``provides {``
! |      ``interface StdControl``
! |      ``interface AcquireData as AccelX;``
! |      ``interface AcquireDataNow as AccelXSingle;``
! |      ``interface AcquireDataBuffered as AccelXMultiple;``
! |      ``interface CalibrationData as AccelXCalibration;``
! |
! |      ``interface AcquireData as AccelY;``
! |      ``interface AcquireDataNow as AccelYSingle;``
! |      ``interface AcquireDataBuffered as AccelYMultiple;``
! |      ``interface CalibrationData as AccelYCalibration;``
! |    ``}``
! |  ``}``
  
! - A parameterised `AcquireData` interface. If a sensor board has multiple
!   similar sensors, it may make sense to provide a single component to access
!   all of these, using a parameterised `AcquireData` interface. For instance,
!   a general purpose sensor board with multiple A/D channels might provide an
!   `AcquireData` interface parameterised by the A/D channel id.
  
  - In all of these examples, if high-speed sampling makes sensor for the
!   sensor (e.g., a microphone), and the sensor is connected in a way that
!   supports high-frequency and/or low-latency access (e.g., via an 
!   on-microcontroller A/D converter), the component should offer 
!   `AcquireDataNow` and `AcquireDataBuffered` interfaces.
  
  Sensor board components MUST respect the following conventions
! on the use of the `Init`, `StdControl`,  and `SplitControl` 
! interfaces.  These are given assuming `StdControl` is used, but the
! behaviour with `SplitControl` is identical except that `start` and `stop`
! are not considered complete until the `startDone` and `stopDone` events are
  signaled. The conventions are:
  
! 1) `Init.init`: must be called at mote boot time.
  
! 2) `StdControl.start`: ensure the sensor corresponding to this component is
      ready for use. For instance, this should power-up the sensor if
!     necessary. The application can call `getData` once `StdControl.start`
      completes.
  
      If a sensor takes a while to power-up, the sensor board implementer can
!     either use a `SplitControl` interface and signal `startDone`
!     when the sensor is ready for use, or delay `dataReady` events
      until the sensor is ready. The former choice is preferable.
  
! 3) `StdControl.stop`: put the sensor in a low-power mode. 
!    `StdControl.start` must be called before any further readings 
!    are taken. The behaviour of calls to `StdControl.stop` during
!    sampling (i.e., when an `dataReady` event is going to be
!    signaled) is undefined.
  
! `.sensor` File
  ====================================================================
  
! This file is a perl script which gets executed as part of the `ncc`
  nesC compiler frontend. It can add or modify any compile-time options 
  necessary for a particular sensor board. It MAY modify the following perl
***************
*** 208,213 ****
  - @new_args: This is the array of arguments which will be
    passed to nescc. For instance, you might add an include directive
!   to @new_args with 
!       push @new_args, '-Isomedir'
  - @commonboards: This can be set to a list of sensor board names which
    should be added to the include path list. These sensor boards must be
--- 213,218 ----
  - @new_args: This is the array of arguments which will be
    passed to nescc. For instance, you might add an include directive
!   to @new_args with push @new_args, `-Isomedir`
! 
  - @commonboards: This can be set to a list of sensor board names which
    should be added to the include path list. These sensor boards must be
***************
*** 221,238 ****
  the mts310:
  
! Name          | Component | Sensor Interfaces | Other Interfaces
! ----------------------------------------------------------------
! Accelerometer | AccelC    | AccelX            | 
!               |           | AccelY            | 
! Magnetometer  | MagC      | MagX              | MagSetting
!               |           | MagY              |  
! Microphone    | MicC      | MicADC            | Mic
!               |           |                   | MicInterrupt 
! Light         | PhotoC    | PhotoADC          | 
! Temperature   | TempC     | TempADC           |
  
  Each physical sensor is represented by a separate component. Specific
  sensors that have more than one axis of measurement (AccelC and MagC)
! provide more than one `AcquireData' interface on a single component. Some
  sensors, such as the magnetometer and microphone, have additional
  functionality provided through sensor-specific interfaces.
--- 226,256 ----
  the mts310:
  
! +------------------------------------------------------------------+
! 
! | Name          | Component | Sensor Interfaces | Other Interfaces |
! 
! +===============+===========+===================+==================+
! 
! | Accelerometer | AccelC    | AccelX            |                  |
! 
! |               |           | AccelY            |                  |
! 
! | Magnetometer  | MagC      | MagX              | MagSetting       |
! 
! |               |           | MagY              |                  |
! 
! | Microphone    | MicC      | MicADC            | Mic              |
! 
! |               |           |                   | MicInterrupt     |
! 
! | Light         | PhotoC    | PhotoADC          |                  |
! 
! | Temperature   | TempC     | TempADC           |                  |
! 
! +------------------------------------------------------------------+
  
  Each physical sensor is represented by a separate component. Specific
  sensors that have more than one axis of measurement (AccelC and MagC)
! provide more than one `AcquireData` interface on a single component. Some
  sensors, such as the magnetometer and microphone, have additional
  functionality provided through sensor-specific interfaces.



Index: tep112.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep112.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** tep112.txt	26 Oct 2005 17:25:51 -0000	1.5
--- tep112.txt	31 Oct 2005 22:31:28 -0000	1.6
***************
*** 285,288 ****
--- 285,296 ----
  ====================================================================
  
+ | Robert Szewczyk
+ | Moteiv Corporation
+ | 2168 Shattuck Ave, Floor 2
+ | Berkeley, CA 94704
+ |
+ | email - rob at moteiv.com
+ |
+ |
  | Philip Levis
  | 358 Gates


Index: tep3.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep3.txt,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** tep3.txt	3 Aug 2005 17:45:13 -0000	1.11
--- tep3.txt	31 Oct 2005 22:31:28 -0000	1.12
***************
*** 97,101 ****
         hardware-independent abstractions.  Expected to be heavily
         used not just by `tos/system` but throughout all other code.
!        `tos/interfaces' should only contain interfaces named in TEPs.
      - `tos/platforms/`.  Contains code specific to mote platforms, but
         chip-independent.
--- 97,101 ----
         hardware-independent abstractions.  Expected to be heavily
         used not just by `tos/system` but throughout all other code.
!        `tos/interfaces` should only contain interfaces named in TEPs.
      - `tos/platforms/`.  Contains code specific to mote platforms, but
         chip-independent.
***************
*** 151,159 ****
      global C names. These prefixes may sometimes be common to multiple
      packages. Examples:
        - All hardware presentation layer names start with Hpl (this is
          an example of a shared prefix).
        - Chip-specific hardware abstraction layer components and interfaces
          start with the chip name, e.g., Atm128 for ATmega128.
!       - The Maté virtual machine uses the Mate to prefix all its names.
        - Core TinyOS names (e.g., the timer components, the Init interface) 
          do not use a prefix.
--- 151,160 ----
      global C names. These prefixes may sometimes be common to multiple
      packages. Examples:
+ 
        - All hardware presentation layer names start with Hpl (this is
          an example of a shared prefix).
        - Chip-specific hardware abstraction layer components and interfaces
          start with the chip name, e.g., Atm128 for ATmega128.
!       - The Maté virtual machine uses the Mate to prefix all its names.
        - Core TinyOS names (e.g., the timer components, the Init interface) 
          do not use a prefix.