Large ADC Commit

[Bittencourt]

Nice!

Thanks a lot =)

--Pedro Bittencourt


On Sun, Feb 15, 2009 at 11:19 PM, James Snyder <jbsnyder at fanplastic.org>wrote:

> One example is adcscope.lua in romfs.  This, along with the current version
> of the module itself, only works on the LM3S platform at the moment, since
> that's what I've got.  I'll make another example that outputs to the serial
> console shortly.
>
> As far as usage goes, here's a quick reference:
>
> channel_id refers to the adc channel being used (for lm3s this is 0-3)
> timer_id refers to a timer to be used in cases where exact timing is
> necessary (for lm3s this can be 0-3)
> frequency is in hertz
>
> adc.sample(channel_id) - returns a single integer value from the ADC
> adc.maxval(channel_id) - returns largest integer one can expect for this
> channel on a given platform (based on bit depth)
> adc.dataready(channel_id) - if running in non-blocking mode, this will
> indicate if all of the samples requested from the last sample or burst have
> been acquired and are waiting in the buffer
> adc.setmode(channel_id, mode) - mode: 0 sets mode to blocking (sample or
> burst will wait for requested samples to be captured before returning), 1
> sets non-blocking
> adc.setsmoothing(channel_id, length) - set the length of the smoothing
> filter, this must be a power of 2, currently between 0 and 128
> adc.getsmoothing(channel_id) - get the current smoothing length in use
> adc.burst( channel_id, count, timer_id, frequency) - request that (count)
> samples (limited to 128 total, also must be a power of 2) be requested from
> (channel_id), using (timer_id) at (frequency). results are returned as a
> table
>
> I'm aware currently that when large smoothing buffer sizes are requested,
> sometimes it blows up.  I'm investigating this, and I think I may have found
> a fix that's not in there yet. There may also be some other cases where it
> crashes.  I'll run it through its paces as much as possible in the coming
> days to nail down most of these issues.
>
> -jsnyder
>
> ----- "Pedro Bittencourt" <pedrobittencourt87 at gmail.com> wrote:
> > Hi James,
> >
> > Could you provide some examples about ADC module usage? (maybe the
> programs used for testing)
> >
> --Pedro Bittencourt
> >
> >
> > > On Sun, Feb 15, 2009 at 10:12 PM, James Snyder <
> jbsnyder at fanplastic.org> wrote:
> >
>>
>> > Hi -
>> >
>> > I've dropped in another large ADC commit.  I've mentioned most of what
>> was done in the commit message, but here's a rundown:
>> >
>> > - When samples are available from ADC, they're initially copied into an
>> elua buf.
>> > - buf length is adjusted according to number of expected samples coming
>> in (when burst is requested, buf is resized to accomodate the number of
>> burst samples, size is dropped back down when single samples are requested)
>> > - if smoothing is enabled, and has no samples, smoothing buffer (not an
>> elua buf) is filled first to warm up the filter, then samples begin to
>> accumulate in the main buffer.
>> > - a flush function has been added to manually clear out both smoothing
>> and primary buffers in case one doesn't want old samples or old smoothing
>> data being used for future measurements
>> >
>> > Also, I forgot to mention one thing in the commit message:  As per a
>> discussion with Bogdan, the type checking on buf_write and buf_read have
>> been pulled out.
>> >
>> > One adjustment that I'd like to consider before the 0.6 freeze is to
>> remove the option for blocking and non-blocking as it applies to sample and
>> burst functions (used to initiate sampling) and to instead make these always
>> non-blocking, and never have them return any samples (only errors, if
>> needed).  A separate function, say getsamples would pull in data collected
>> using either mode.  Right now, if one uses non-blocking mode, samples will
>> always be returned for the last time you ran sample or burst.  This means
>> that if you want to get the data already requested, you also have to always
>> request new samples, even if you don't want them.
>> >
>> > I should be able to make this change with minimal code changes, but I
>> haven't done it yet because it changes the pre-existing paradigm, and I
>> wanted to get these changes in sooner rather than later :-)
>> >
>> > I think it might just take me another hour or so to get adjustments
>> along those lines working.  There wouldn't be as long of a delay as this ADC
>> commit.
>> >
>> > Suggestions/comments are welcome :-)
>> >
>> > -jsnyder
>> > _______________________________________________
>> > Elua-dev mailing list
>> > Elua-dev at lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>> >
>>
>
> >
> > _______________________________________________ Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090215/ce346cb7/attachment.html