[Tinyos-host-mote-wg] [Tinyos-2.0wg] Aligning TEP 101 (ADC) with TEP 108 (Resource Arbitration) and 109 (Sensorboards)

[Jan Hauer]

There has not been much input in the ADC discussion lately, I'd like
to summarize what we have and make a proposal for the TEP that takes
other related TEPs (TEP 108,109) better into consideration.


1. HPL and HAL

We have agreed that HPL and HAL are platform independent in
implementation and representation and should offer all ADC specific
functionality including a reservation mechanism. Reservation of the
ADC is needed for precise timing and will also be provided on HIL
level (therefore the HAL must also provide support for reservation).
Currently reservation on HAL is done via platform specific primitives,
e.g..

MSP430ADC12Multiple.reserve(uint16_t *buf, uint16_t length, uint16_t
jiffies);

To align the HAL with TEP108 I would suggest to instead of platform
dependent reserve commands provide the Resource interface introduced
in TEP108. A successful call to an HAL's Resource.request() would
reserve the ADC for the caller until he calls Resource.release(). For
time critical sampling an additional platform dependent command e.g.
MSP430ADC12Multiple.prepare(uint16_t *buf, uint16_t length, uint16_t
jiffies) is provided that sets up ADC registers so that a subsequent
MSP430ADC12Multiple.getData() will start the sampling process
immediately with these settings.


2. HIL

As far as I understand our last conclusion was that an HIL will
provide one lean ADC interface with only a getData() command and the
Resource interface (see TEP108). The idea was to have a HIL component
(wrapper) per channel (sensor). On top of multiple HIL components a
service like round robin could be built.

To align HIL with TEP109 I would like to provide the "Sensor" and
"QSensor" as well as the "CalibrationData" interface by the HIL
(wrapper) instead of providing a separate "ADC", "ADCSingle" or
"ADCMultiple" interface. The Sensor interface already has the same
commands as the suggested lean "ADCSingle" or "ADC" interface.
"QSensor" is for async requests and "CalibrationData" to return
calibration data, both should be provided optionally.

For platform indepent access to the ADC/Sensors I think TEP101 (ADC)
and TEP109 (Sensorboards) complement one another in the sense that
TEP101 defines the HPL and HAL and TEP109 defines the HIL. Our
experience has shown that there cannot be a platform independent
interface for the ADC HIL that provides more than simple
get[Single/Multiple]Data commands and a reservation mechanism. Even
for the msp430 and atmel it is too cumbersome to find a unifying
platform independent representation for the bind process, because e.g.
reference voltages or sample-hold-times are very specific to the MCU
and cannot be merged efficiently into a single interface. An HIL
interface as the common denominator for msp430 and atmel would only
allow settings supported by both ADCs, resulting in a very small or
even empty subset of possible hardware settings.

The TEP for the ADC would therefore consist of only HPL and HAL.
Direct access to an ADC is only possible in a chip-specific way. The
platform independent representation of an ADC channel is the sensor
interface. As explained in TEP109 there is one component per Sensor
providing a StdControl and Sensor interface (optionally also QSensor
and CalibrationData).


3. "Services"

Services are built on top of the wrappers that represent a Sensor. A
service component wires to a single or multiple wrappers and extends
or combines the functionality of these wrappers. Examples are a round
robin service or a service returning multiple samples taken at precise
points in time. Services are (mostly) platform independent. Example
configuration:

    configuration ADCRoundRobinServiceC
    {
      provides interface StdControl;
      provides interface Sensor as RoundRobinSensor[uint8_t id];
      uses interface Sensor as SimpleSensor[uint8_t id];
    }
    implementation
    {
      components ADCRoundRobinServiceM;
      
      StdControl = ADCRoundRobinServiceM;
      RoundRobinSensor = ADCRoundRobinServiceM;
      SimpleSensor =  ADCRoundRobinServiceM;
    }


and a client configuration:

  configuration RoundRobinClientC
  {
  }
  implementation
  {
    enum {
      TEMP_SENSOR = unique("ADCRoundRobinService")
    };
    components ADCRoundRobinServiceC, RoundRobinClientM,
    InternalTempC, Main;

    Main.StdControl -> ADCRoundRobinServiceC;
    Main.StdControl -> RoundRobinClientM;
    RoundRobinClientM.TempSensor -> ADCRoundRobinServiceC.RoundRobinSensor[TEMP_SENSOR];

    ADCRoundRobinServiceC.SimpleSensor[TEMP_SENSOR] -> InternalTempC;
  }

In the example there can be up to 256 clients each specifying through
their wiring which actual sensor they want to sample. The round robin
component can perform a simple mapping of in- and out-going interfaces
because the IDs are identical, i.e. a call to
RoundRobinSensor.getData[X]() will result in an event
SimpleSensor.dataReady[X]() from InternalTempC and both interfaces X
are reserved for the same client.
    
4. Directory structure

HPL and HAL components will be placed in the corresponding
tinyos-2.x/tos/chips/[MCU/ADC] subdirectory.

Wrappers for the sensors on sensorboards will be placed in the
tinyos-2.x/tos/sensorboards subdirectory as explained in TEP109.

The wrappers for internal ADCs that provide access to internal channels
(e.g. the msp430 ADC can sample an internal temperature sensor, it can
measure the internal voltage level etc.) should be placed in the
corresponding tinyos-2.x/tos/chips/[MCU/ADC] subdirectory. (Or should
there be some subdirectory like
tinyos-2.x/tos/sensorboards/msp430onchip/ (slightly contradicting)
where all internal sensor components are placed, so all sensor
components can be kept in the same subdirectory ?)

The wrappers for onboard sensors (e.g. the eyesIFX node famliy has a
temperature and light sensor on the node) should be placed in the
corresponding tinyos-2.x/tos/platform/ subdirectory.

The service components should be placed in tos/system.


Comments ? I will start to change TEP101 accordingly if there is no
objection.

Jan




_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
http://Mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-2.0wg