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

[David Gay]

On 5/12/05, Jan Hauer <hauer at tkn.tu-berlin.de> wrote:
> For the atmel this is easy, because it is a one-to-one translation.

Actually the atmel also has a choice of reference voltages.

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

At least for the mica, I think it makes sense to have the HAL use the
"same" (well a mica version) interface, but not wire it to anything.
The HAL would include a default implementation of getPortSettings
which returns the "default" settings. Components representing access
to a particular sensor (especially those connected to an external
sensor board) would then wire the HAL settings interface for their
port and return the settings they need. This allows all the behaviour
for a particular port/sensor to be placed in a single component.

David

_______________________________________________
Tinyos-2.0wg mailing list
Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg