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

[Jan Hauer]

Thanks for commiting code, that makes it much easier to talk. I like
the interface definitions for AcquireData, AcquireDataNow and
AcquireDataBuffered and think all three should be provided by HIL. I
will just point out where I see difficulties.

You propose that the ADCC offers a parameterized AcquireData[Now] HIL
interface:

configuration ADCC {
  provides {
    interface Init;
    interface StdControl;
    interface Resource[uint8_t client];
    interface AcquireData[uint8_t port];
    interface AcquireDataNow[uint8_t port];
  }

I assume there is going to be something like a global enum defining
all possible platform independent 'port's.

Problem No. 1: Each chip's ADCM would perform the mapping of a 'port'
to the actual settings for the specific chip. These settings are,
however, platform dependent! E.g. two platforms using the same ADC,
e.g. telos and eyes, would map 'port' to different settings. But ADCM
is chip dependent (located in the msp430/chips/adc12 directory) and
has no knowledge about a certain platform. I.e. ADCM cannot perform
the mapping from port to platform settings. To make this clear, it is
maybe important to say that on msp430 a 'port' like CHANNEL_RSSI is
not exhaustively defined by an ADC channel (in contrast to the current
atmel implementation, BTW couldn't you set a sampling rate in
tinyos-1.x for the atmel ?), but also by e.g. reference voltage level
or sample-hold-time.

Problem No. 2: Let's assume a platform independent app wires to
ADCC.AcquireData[CHANNEL_RSSI] but the actual platform the application
is compiled for does not provide the RSSI on an ADC pin, i.e. there is
no CHANNEL_RSSI. The app would compile but all calls would return fail
or errors (because there is no corresponding port). Unfortunately this
is only detected at runtime...


Therefore I would suggest not to have a 'port'-parameterized HIL
interface for the ADC. I personally have come to the conclusion that
it is unlikely to have a platform independent representation of an ADC
in tinyos, because they differ in too many details (a common
denominator often does not exist). Instead we should provide an
extensive HAL (including the bind-mechanism) and on top wrappers per
Sensor/Channel/Port. These wrappers provide simple (non-parameterized)
AcquireData[Now,Bufferered] interface and have the semantics in their
naming (same approach as in tinyos-1.x, wiring to Temp, Light or
DemoSensorC). The wrappers (=HIL) would have the task to hide all the
chip AND platform specific intricacies from the application and would
therefore reside in the corresponding platform directory (or
platform specific sensorboard subdirectory?).


Some minor issues:
- In the AcquireData interface: Wouldn't it be simpler (easier for the
programmer) to have only one event
   event void AcquireData.dataReady(uint16_t data, uint16_t errorInfo)
and get rid of the AcquireData.error event instead of two different
events for data and errors ?

- The policy I had in mind when providing the Resource interface from
the HAL/HIL was that a "successful call to an HAL's Resource.request()
would reserve the ADC for the caller until he calls
Resource.release()", but an application would not be forced to call
Resource.request() prior to every call to getData(). If it didn't call
Resource.request(), then getData() could fail if the ADC (component)
was busy serving another request. But a simple call to getData() would
succeed, if the ADC was free. This is not as strict as your proposal.

Comments?

Jan




> On 5/9/05, David Gay <dgay42 at gmail.com> wrote:
>> > 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:
>>
>> I like this. We can save clients a bit of typing with:

> There's now an implementation of this for convenient access to the
> (proposed) ADC HIL, in the tos/system/ADCChannelC.nc and
> ADCNowChannelC.nc generic components. You can simply say

>   components new ADCChannel(CHANNEL_RSSI) as RSSIAdc;

>   MyStuff.AcquireData -> RSSIAdc.AcquireData;

> to get your own "private" AcquireData interface on the RSSI channel.

> It's built out of fairly generic subcomponents, so this can easily be
> made available for other data acquisition components or with a
> different arbiter (it's currently using RoundRobinArbiter).

> There is also a mica A/D HIL component (ADCC) following the proposed
> tep101 changes from this thread.

> David

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


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