Large ADC Commit

[BogdanM]

> That said, this isn't essential, and it may just be a bit of a luxury.  It
> depends on how people might use it.  Maybe I'm trying to make this too much
> like ADC one might expect on a desktop :-)
>

I still didn't understand your use case completely, but I think what we have
right now is more than enough for an ADC subsystem.

I've thought about this issue, a bit.  I'm planning on making a version that
> will do a single sample at a time that doesn't require the buffer.  This
> will mean that burst wouldn't be available.
>

Sure, as sometimes it isn't needed.

Best,
Bogdan

>
> > > >
>> > > Best,
>> > > Bogdan
>> > >
>> > > On Mon, Feb 16, 2009 at 3:12 AM, 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
>> >
>> >
>
>
> >
> > _______________________________________________ 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/20090217/28c86b52/attachment-0001.html