Jan,
> As I said, an app does not actively configure the ADC but only
> provides an event handler returning its configuration. Your
> application could look like this:
>
> configuration MyAppC {
> } implementation {
> components AppC, new AdcReadClientC(), MyConfigC;
>
> AppC.Read -> AdcReadClientC;
> AdcReadClientC.AdcConfigure -> MyConfigC;
> }
>
> where MyConfigC returns the ADC configuration (analogous to
> Msp430InternalVoltageP) and AppC uses the Read interface to read out
> the data. AppC does not configure the ADC itself and it cannot change
> its ADC configuration, but every time it calls Read.read, the ADC is
> automatically configured to what MyConfigC returns (AppC could also
> implement the AdcConfigure event handler itself - I added such an
> example to CVS, see below).
>
> If an app wants to use different ADC configurations, it can
> instantiate multiple clients "assigning" to each a different ADC
> configuration:
>
> configuration MyAppC {
> } implementation {
> components AppC, new AdcReadClientC() as HumidityClient, HumidityConfigC;
> new AdcReadClientC() as TemperatureClient,
> TemperatureConfigC;
>
> AppC.ReadHumidity -> HumidityClient;
> HumidityClient -> HumidityConfigC;
> AppC.ReadTemperature -> TemperatureClient;
> TemperatureClient -> TemperatureConfigC;
> }
Thanks for the help - this has been very useful. I modified the
Oscilloscope application to use AdcReadClient, and I'm using configs like:
const msp430adc12_channel_config_t config = {
inch: INPUT_CHANNEL_A1,
sref: REFERENCE_AVcc_AVss,
ref2_5v: REFVOLT_LEVEL_NONE,
adc12ssel: SHT_SOURCE_ACLK,
adc12div: SHT_CLOCK_DIV_8,
sht: SAMPLE_HOLD_4_CYCLES,
sampcon_ssel: SAMPCON_SOURCE_SMCLK,
sampcon_id: SAMPCON_CLOCK_DIV_1
};
now, I have two, possibly lame questions. one is:
- what is the search path for components?
I'd like to create, as you write above, my own TemperatureClientC class,
HumidityClientC, for code-reuse and also for code clarity. If I just
create an TemperatureClientC.nc file, where do I have to put it so that
the build process finds it?
- I'm getting readings, but they are 'spiky'. please see the attached
image, but the basic pattern is something like this:
| |
| | |
.|./ .|.
that is, a lot of very low / zero reading between 'good' readings. is
this a sensor reading / hardware configuration issue? can this be cured
by playing around the channel config parameters as above? or do I have
to remove the bad part of the data / noise programmatically? if so, is
there existing nesC code to do so?
All help is very apprieciated,
> I added (to CVS) a simple ADC test app that does not use any sensor wrappers:
> tinyos-2.x/apps/tests/msp430/AdcSimple
Thank you! I'll take a look!
Akos
<<inline: brightness.jpg>>
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
