[Tinyos-beta-commits]
CVS: tinyos-1.x/beta/teps/txt tep109.txt, 1.3, 1.4
Phil Levis
scipio at users.sourceforge.net
Wed Jul 6 13:06:03 PDT 2005
Update of /cvsroot/tinyos/tinyos-1.x/beta/teps/txt
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv11035
Modified Files:
tep109.txt
Log Message:
Updated with SHOULDs, MUSTs, etc.
Index: tep109.txt
===================================================================
RCS file: /cvsroot/tinyos/tinyos-1.x/beta/teps/txt/tep109.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -d -r1.3 -r1.4
*** tep109.txt 6 Jul 2005 06:58:18 -0000 1.3
--- tep109.txt 6 Jul 2005 20:06:00 -0000 1.4
***************
*** 1,4 ****
============================
! Sensorboards
============================
--- 1,4 ----
============================
! Sensor Boards
============================
***************
*** 8,12 ****
:Status: Draft
:TinyOS-Version: 2.x
! :Author: David Gay, Wei Hong, Phil Levis, and Joe Polastre
:Draft-Created: 19-Apr-2005
--- 8,12 ----
:Status: Draft
:TinyOS-Version: 2.x
! :Author: David Gay, Phil Levis, Wei Hong, and Joe Polastre
:Draft-Created: 19-Apr-2005
***************
*** 25,39 ****
====================================================================
! This memo documents how sensor boards are organised in TinyOS, and the
! general principles followed by the components that give access to
! a particular board's sensors.
1. Introduction
====================================================================
! This document defines the default organisation of a sensor board in
! TinyOS. There will undoubtably be sensor boards which cannot conform
! to this specification, but such boards SHOULD attempt to follow its
! spirit as closely as possible.
This document assumes that sensors return uninterpreted 16-bit values, and,
--- 25,39 ----
====================================================================
! This memo documents how sensor boards are organized in TinyOS, and the
! general principles followed by the components that provide access to
! its sensors.
1. Introduction
====================================================================
! This document defines the default organization of a sensor board in
! TinyOS. There likely will be sensor boards that cannot conform
! to this specification, but following as closely to its spirit as possible
! will simplify generic applications that use a range of sensor boards.
This document assumes that sensors return uninterpreted 16-bit values, and,
***************
*** 42,79 ****
(current) scope of this document.
! 2. Directory Organisation
====================================================================
! - A sensor board should 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 should have its own directory named SBOARD; default TinyOS
! sensor boards will be 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. Future versions of this TEP
are likely to discuss TinyDB attributes.
! - Finally, the sensor board can 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
--- 42,79 ----
(current) scope of this document.
! 2. Directory Organization
====================================================================
! - 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. 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
***************
*** 90,99 ****
components. Please select reasonable names\ldots
! A sensor board component must provide:
- An `Init' interface.
- A `StdControl' or `SplitControl' interface for power management.
! - A non-empty set of `Sensor' 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
--- 90,99 ----
components. Please select reasonable names\ldots
! A sensor board component MUST provide:
- 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:
- Some `CalibrationData' interfaces for obtaining calibration data.
A calibration interface for a sensor accessed via interface X should
***************
*** 103,138 ****
- Any other appropriate interface.
! The `Sensor' and `CalibrationData' interfaces are shown below, `ADCSingle'
! and `ADCMultiple' are in TEP 101. The `Sensor' 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
! just provide basic access to the physical sensors and not attempt to do
calibration, signal processing, etc. If such functionality is desired, it
! should be provided in separate components.
!
! interface Sensor {
! /* Sensor is for sensors which will not be sampled at high rates */
!
! /** Request sensor sample
! * @return SUCCESS if request accepted, FAIL if it is refused
! * dataReady or error will be signaled if SUCCESS is returned
! */
! command result_t getData();
!
! /** Return sensor value
! * @param data Sensor value
! * @return Ignored
! */
! event result_t dataReady(uint16_t data);
!
! /** Signal that the sensor failed to get data
! * @param info error information, sensor board specific
! * @return Ignored
! */
! event result_t error(uint16_t info);
! }
interface CalibrationData {
--- 103,116 ----
- 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
! just provide basic access to the physical sensors and SHOULD NOT attempt to do
calibration, signal processing, etc. If such functionality is desired, it
! SHOULD be provided in separate components.
interface CalibrationData {
***************
*** 157,166 ****
Some common setups for sensor board components are:
! - A single `Sensor' 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 `Sensor' 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
--- 135,144 ----
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
***************
*** 170,179 ****
provides {
interface StdControl
! interface Sensor as AccelX;
interface ADCSingle as AccelXSingle;
interface ADCMultiple as AccelXMultiple;
interface CalibrationData as AccelXCalibration;
! interface Sensor as AccelY;
interface ADCSingle as AccelYSingle;
interface ADCMultiple as AccelYMultiple;
--- 148,157 ----
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;
***************
*** 182,190 ****
}
! - A parameterised `Sensor' 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 `Sensor' interface. For instance,
a general purpose sensor board with multiple A/D channels might provide an
! `Sensor' interface parameterised by the A/D channel id.
- In all of these examples, if high-speed sampling makes sensor for the
--- 160,168 ----
}
! - 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
***************
*** 194,199 ****
'ADCSingle' and 'ADCMultiple' interfaces.
! Sensor board components are expected to respect the following conventions
! on the use of the `Init', `StdControl', `SplitControl' and `Sensor'
interfaces. These are given assuming `StdControl' is used, but the
behaviour with `SplitControl' is identical except that `start' and `stop'
--- 172,177 ----
'ADCSingle' and 'ADCMultiple' 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'
***************
*** 219,230 ****
signaled) is undefined.
- 4) `Sensor.getData': get a sample from a sensor.
-
- 5) `Sensor.dataReady': signals the sample value to the application.
-
- 6) `Sensor.error': reports a sensing problem to the application (not all
- sensors will report errors). The error values are sensor-board
- specific.
-
`.sensor' File
====================================================================
--- 197,200 ----
***************
*** 232,237 ****
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 can modify the following perl
! variables:
- @new_args: This is the array of arguments which will be
--- 202,207 ----
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
! variables, and MUST NOT modify any others:
- @new_args: This is the array of arguments which will be
***************
*** 261,265 ****
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 Sensor interface on a single component. Some
sensors, such as the magnetometer and microphone, have additional
functionality provided through sensor-specific interfaces.
--- 231,235 ----
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.
***************
*** 289,291 ****
--- 259,271 ----
|
| email - david.e.gay at intel.com
+ |
+ | Philip Levis
+ | 358 Gates Hall
+ | Computer Science Department
+ | 353 Serra Mall
+ | Stanford, CA 94305
+ |
+ | phone - +1 650 725 9046
+ |
+ | email - pal at cs.stanford.edu
More information about the Tinyos-beta-commits
mailing list