[Tinyos Core WG] Re: AdcConfigure and struct return

[David Gay]

On 9/23/06, Jan Hauer <jan.hauer at gmail.com> wrote:
> > > 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.
>
> OK, your "weak" HIL definition means: everyone knows the name
> (adc_config_t), but unless you know what the actual typedef is, it's
> not of much use, since you cannot access, for example, the struct
> members.

You can still store those values in variables, and pass them as
parameters. In the terminology of "weak/etc" HILs, not knowing the
type name makes it a "weaker" HIL, i.e., it's not really any different
than not knowing the definition of the interface.

FWIW, btw:
"weak HIL": you can write portable modules and configurations that
connects to the HIL
"weaker HIL": you can only write portable configurations that connect to the HIL

> > 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.
>
> When we deal with multiple ADCs it gets ugly :(
> One option is (like you say) to let the platform designer make a
> "weak" HIL representation of the default ADC (including the typedef of
> adc_config_t). But usually it is again the platform that will
> instantiate the AdcReadClientC and put, for example, a DemoSensorC on
> top of it. I don't know if we should say that a platform MUST
> implement an AdcReadClientC when only platform components will wire to
> it.
>
> Alternatively the ADC abstraction could end with components (names
> prefixed by the chip name, as you suggested) that provide Read and
> AdcConfigure with chip-specific types, e.g.:
>
>   #include <Msp430Adc12.h>
>   generic configuration Msp430AdcReadClientC() {
>     provides interface Read<uint16_t>;
>     uses interface AdcConfigure<const msp430adc12_channel_config_t*>;
>   }
>
> It is then up to the platform to build components on top (e.g. put
> DemoSensor on top of ADC1 and VoltageP on top of ADC2). As far as I
> have understood the previous discussion this would neither be called a
> "weak" nor "weaker" HIL nor an HAL2 - probably we'd need another name
> :) Comments ?

This would be the "HII" (hardware indepdendent interfaces) approach -
i.e., specify interfaces only and not component names or
specifications (+, in this case, some guidelines on how to name
components, but in fact nothing would break if some platform didn't
follow them...)

David