[Tinyos-beta-commits] CVS: tinyos-1.x/beta/teps/txt tep109.txt, 1.5, 1.6

Wed Oct 19 14:35:29 PDT 2005

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

Modified Files:
	tep109.txt 
Log Message:
update interface names and misc cleanup

Index: tep109.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep109.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** tep109.txt	6 Jul 2005 23:22:03 -0000	1.5
--- tep109.txt	19 Oct 2005 21:35:25 -0000	1.6
***************
*** 40,44 ****
  optionally uninterpreted, arbitrary-size calibration data. Conversion of
  sensor values to something with actual physical meaning is beyond the
! (current) scope of this document.

  2. Directory Organization
--- 40,44 ----
  optionally uninterpreted, arbitrary-size calibration data. Conversion of
  sensor values to something with actual physical meaning is beyond the
! scope of this document.

  2. Directory Organization
***************
*** 69,83 ****
  - 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. Future versions of this TEP
! are likely to discuss TinyDB attributes.

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

  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' and `Temp'
  representing its light and temperature sensors.

--- 69,83 ----
  - 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.

***************
*** 93,97 ****
  - An `Init' interface.
  - A `StdControl' or `SplitControl' interface for power management.
! - A non-empty set of `DataAcquire' interfaces for sampling.

  A sensor board component MAY provide:
--- 93,97 ----
  - 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:
***************
*** 99,111 ****
    A calibration interface for a sensor accessed via interface X should
    be called XCalibration.
! - Some `ADCSingle' and `ADCMultiple' interfaces, for high-speed or
!   low-latency data acquisition.
  - Any other appropriate interface.

! The `CalibrationData' interface is shown below, while `DataAcquire',
! `ADCSingle' and `ADCMultiple' are in TEP 101. The `DataAcquire' 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.

  A sensor board component SHOULD be as lightweight as possible - it should
--- 99,111 ----
    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.

  A sensor board component SHOULD be as lightweight as possible - it should
***************
*** 135,168 ****
  Some common setups for sensor board components are:

! - A single `DataAcquire' 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 `DataAcquire' 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 DataAcquire as AccelX;
!       interface ADCSingle as AccelXSingle;
!       interface ADCMultiple as AccelXMultiple;
        interface CalibrationData as AccelXCalibration;

!       interface DataAcquire as AccelY;
!       interface ADCSingle as AccelYSingle;
!       interface ADCMultiple as AccelYMultiple;
        interface CalibrationData as AccelYCalibration;
      }
    }

! - A parameterised `DataAcquire' 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 `DataAcquire' interface. For instance,
  a general purpose sensor board with multiple A/D channels might provide an
! `DataAcquire' interface parameterised by the A/D channel id.

  - In all of these examples, if high-speed sampling makes sensor for the
--- 135,169 ----
  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
***************
*** 170,174 ****
  supports high-frequency and/or low-latency access (e.g., via an 
  on-microcontroller A/D converter), the component should offer 
! 'ADCSingle' and 'ADCMultiple' interfaces.

  Sensor board components MUST respect the following conventions
--- 171,175 ----
  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
***************
*** 213,247 ****
    in tinyos-2.x/tos/sensorboards.

! Example: micasb
  ====================================================================

! The mica sensor board (micasb) has five sensors (and one actuator, the
! sounder):
  Name          | Component | Sensor Interfaces | Other Interfaces
  ----------------------------------------------------------------
! Accelerometer | Accel     | AccelX            | 
                |           | AccelY            | 
! Magnetometer  | Mag       | MagX              | MagSetting
                |           | MagY              |  
! Microphone    | Mic       | MicADC            | Mic
                |           |                   | MicInterrupt 
! Light         | Photo     | PhotoADC          | 
! Temperature   | Temp      | TempADC           |

  Each physical sensor is represented by a separate component. Specific
! sensors that have more than one axis of measurement (e.g., Accel and
! Mag) provide more than one `DataAcquire' interface on a single component. Some
  sensors, such as the magnetometer and microphone, have additional
  functionality provided through sensor-specific interfaces.

! Although light and temperature are represented by separate components,
! in reality they share a single ADC pin. The two components Photo and
! Temp sit on top of the PhotoTemp component, which controls access to
! the shared pin, and orchestrates which sensor is currently connected
! to it. From a programmer's perspective, they appear as individual
! sensors, even though their underlying implementation is a bit more
! complex.

! The board's micasb.h file contains private configuration data
  (pin usage, ADC ports, etc).

--- 214,249 ----
    in tinyos-2.x/tos/sensorboards.

! Example: mts3x0
  ====================================================================

! The mica sensor board (mts300/mts310) has five sensors (and one actuator,
! the sounder) -- the accelerometer and magnetometer are only present on 
! 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.

! Although light and temperature are represented by separate components, in
! reality they share a single microcontroller pin. The two components PhotoC
! and TempC sit on top of the PhotoTempP component, which controls access to
! the shared pin, and orchestrates which sensor is currently connected to
! it. From a programmer's perspective, they appear as individual sensors,
! even though their underlying implementation is a bit more complex.

! The board's mts3x0.h file contains private configuration data
  (pin usage, ADC ports, etc).

***************
*** 261,271 ****
  |
  | Wei Hong
! | 2150 Shattuck Ave, Suite 1300
! | Intel Research
  | Berkeley, CA 94704
  |
! | phone - +1 510 495 3058
! |
! | email - wei.hong at intel.com
  |
  | Philip Levis
--- 263,270 ----
  |
  | Wei Hong
! | Arched Rock
  | Berkeley, CA 94704
  |
! | email - wei.hong at gmail.com
  |
  | Philip Levis