Large ADC Commit

[jbsnyder]

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 

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