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

[Jan Hauer]

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

> Other settings: I think some of this discussion comes down to how
> useful it is to provide less-than-100%-portable higher level
> abstractions. I agree with you that it is too hard to provide a
> useful, 100% portable A/D abstraction, but I still think it's useful
> to say that if you have an A/D, then there should be an ADCC component
> with the interfaces described above. You're going to want this
> component to implement the various sensors built using this A/D at the
> very least; by specifying what ADCC looks like we can then provide
> useful things like the example ADCChannelC component (which is
> platform independent) in TinyOS.

[you can skip the first 3 paragraphs if you're not interested in the
background]

I totally agree with having the above interfaces provided by HIL. The
question is, whether to provide them by one platform independent HIL
component (ADCC) with parameterized interfaces or to provide them by
multiple platform dependent HIL components (Temp, Light, DemoSensorC
...) with single (i.e. unparametrized) interfaces - it comes down to a
structuring/design decision. I argue that for the msp430 the latter
makes more sense. Let me explain why...

I think we have come to the conclusion that HPL and HAL are platform
independent and chip dependent both in representation and
implementation and HIL will be a chip dependent implementation also.
Of course, HIL will also have a chip/platform independent
representation. If the HIL also was a platform independent
implementation (e.g. an ADCC component), then somewhere a mapping from
the 'port' interface ID to the actual ADC settings must occur. But
because all components inluding HIL and below are platform independent
the 'port' parameter must exhaustively define the settings in itself.

For the atmel this is easy, because it is a one-to-one translation.
For the msp430 not. Example: On the msp430 there are six different
reference voltages that you can select (plus an internal reference
voltage generator being switched to 1.5V or 2.5V) and obviously a
correct conversion result depends on choosing the correct reference
voltage. Because 'port' only defines the channel to be sampled the
reference voltage must be some default setting - what would you choose
as default setting for a reference voltage? (and this is only
talking about the msp430 ADC, there may be more complicated ADCs to
come). This could, so I argue, be solved by making the HIL platform
dependent. Then for each channel a wrapper with the desired settings
is written, each providing the AcquireData[...] interface.


... wait, I just came up with an idea for a compromise :) Let's have a
platform independent ADCC like you suggested, where the ADCM uses a
"hook" to get the actual settings it needs to configure the ADC for
the respective platform (similar to
tinyos-1.x/tos/platform/msp430/MSP430ClockInit written by Cory Sharp).
Each *platform* that has a more complex ADC would need to write just
one module, say MSP430ADC12SettingsM, implementing a chip specific
hook-interface, say MSP430ADC12Settings, which has only one event

interface MSP430ADC12Settings {
  event msp430adc12settings_t getPortSettings(uint8_t port);
}

The ADCM would signal this event for all 'port's it will be used for
and the platform specific MSP430ADC12SettingsM would hand over the
configuration details for the specific channel on this very platform.
There can also be a default MSP430ADC12SettingsM with default settings
(whatever that means :)) in the chips directory.
For the msp430:

configuration ADCC {
  provides {
    interface Init;
    interface StdControl;
    interface Resource[uint8_t client];
    interface AcquireData[uint8_t port];
    interface AcquireDataNow[uint8_t port];
  }
}
implementation {
  components MSP430ADC12C, ADCM, MSP430ADC12SettingsM;

  Init = MSP430ADC12C;
  StdControl = MSP430ADC12C;
  Resource = MSP430ADC12C;

  AcquireData = ADCM;
  AcquireDataNow = ADCM;

  ADCM.MSP430ADC12Single -> MSP430ADC12C;
  ADCM.MSP430ADC12Multiple -> MSP430ADC12C;
  ADCM.MSP430ADC12Settings -> MSP430ADC12SettingsM;
}

An application wiring to ADCC.AcquireData[CHANNEL_RSSI], would result
in ADCM signalling MSP430ADC12Settings.initPort(CHANNEL_RSSI) on the
first getData() to get the platform's specific ADC settings for this
channel. It would then bind MSP430ADC12Single/Multiple[CHANNEL_RSSI]
to these settings. All subsequent calls to AcquireData[Now] will use
the platforms settings. HPL, HAL and HIL stay platform independent.

Comments?

Jan



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