[Tinyos Core WG] Re: AdcConfigure and struct return
Jan Hauer
jan.hauer at gmail.com
Sat Sep 23 06:35:27 PDT 2006
> > 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.
> 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 ?
Jan
More information about the Tinyos-2.0wg
mailing list