[Tinyos Core WG] Re: AdcConfigure and struct return

[Martin Turon]

Hi,

Yes the UCLA board is called MDA300 (mote data aquisition).  

It has an external 12-bit adc, while the mica atm128 has a 10-bit adc.

Martin


-----Original Message-----
From: tinyos-2.0wg-bounces at Mail.Millennium.Berkeley.EDU on behalf of David Gay
Sent: Fri 9/22/2006 9:51 AM
To: Jan Hauer
Cc: tinyos2
Subject: Re: [Tinyos Core WG] Re: AdcConfigure and struct return
 
On 9/22/06, Jan Hauer <jan.hauer at gmail.com> wrote:
> > in their chip-specific Adc.h file (which the TEP probably needs to
> > mention - one might want to use this adc_config_t type in random
> > places, so it needs to be in a well-defined .h file).
>
> Not sure, whether we need an Adc.h [see below]
>
> > Btw, I'm confused by the type argument stuff in the TEP101 draft
> > (there's some unbound size_type usages in section 4, I'm not sure why
> > AdcConfigure needs a type argument, and if it does, it's unclear if
> > adc_config_t in section 4 is an unbound type parameter or a reference
> > to a chip-specific type - in the latter case, it's a bad idea to use
> > the same name as in AdcConfigure's definition).
>
> I thought about two alternatives for a tos/interfaces/AdcConfigure
> interface. Either
>
>   #include <Adc.h>
>   interface AdcConfigure {
>     async command adc_config_t getConfiguration();
>   }
>
> or
>
>   interface AdcConfigure<adc_config_t>{
>     async command adc_config_t getConfiguration();
>   }
>
> In the second option I can see two advantages: we don't make every
> platform write an "Adc.h". And we can deal with multiple ADCs on the
> same platform (don't know how likely this is, though). Can you see any
> disadvantages ?

Mica2/z's with the UCLA sensor board (MTS300?) have two ADCs.

> The TEP was not good at describing this. What I wanted to say in
> section 4 is that an AdcReadClient provides two standard interfaces -
> Read and AdcConfigure - and the respective "weak" HIL defines what the
> data types for the conversion result (e.g. Read<uint16_t>) and
> configuration (e.g. AdcConfigure<const msp430adc12_channel_config_t*>)
> are. I changed the type parameter to "config_type" - tell me, if it is
> still confusing (the updated TEP is attached). For example, on the
> MSP430 the AdcReadClient now has the following signature:
>
>   generic configuration AdcReadClientC() {
>     provides interface Read<uint16_t>;
>     uses interface AdcConfigure<const msp430adc12_channel_config_t*>;
>   }

If you do want to write portable ("weak HIL") above-the-ADC code, you
need to know the name of the type argument of AdcConfigure, so need a
typedef for it, hence the request for Adc.h.

If you want multiple ADC support, you can't call this AdcReadClientC.
And to make life more fun, you can't have a file named Adc.h in each
ADC, or a global type named adc_config_t, etc. I think you end up
where the radio is - each chip prefixes all its names (even for HIL
stuff) with <ChipName>, and the platforms with multiple ADCs pick a
distinguished one to be the "default" HIL. Apps that care use the
specific names.

David, not convinced we have a very good multiple-instance-of-the-same-TEP story
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20060922/007c2ddf/attachment.htm