Large ADC Commit

[BogdanM]

> True..  Are you anticipating use of higher or lower bit depth?  There are
> certainly lower and higher ones out there, though I've not seen >16-bit ones
> built-in to uCs.  If we want to accomodate larger sizes, the return types
> for some things will need adjustment, perhaps by defining a type that
> reflects the maximum size that will be returned?  This type would be
> selected at compile time depending on the maximum bits-per-sample one might
> want to work with?
>
> Something like:
>
> #if MAX_ADC_BIT_RESOLUTION <= 8
> typedef u8 t_adc_data
> #elif MAX_ADC_BIT_RESOLUTION <= 16
> typedef u16 t_adc_data
> #elif MAX_ADC_BIT_RESOLUTION <= 32
> typedef u32 t_adc_data
> #else
> #error "No matching type for MAX_ADC_BIT_RESOLUTION, check your selected
> bit depth or add larger type"
> #endif
>

Something like this, but not at compile time, since one might have a system
that uses both an (hypothetical) internal 8-bit ADC, and an external 16-bit
SPI ADC. Let's keep it like this for now, seems to be generic enough for our
needs.

OK, sounds good.  The one midly complicated thing to make this approach work
> with dynamic buffer sizing is to have buf_set handle increasing buffer size
> gracefully.  I think the main case to handle is when wptr < rptr.  i.e. the
> write pointer has wrapped around to the beginning of the buffer, but the
> read ptr has not.  If one just adds space in this case, the read pointer
> will start going into as yet unwritten space thinking it is picking up valid
> data.
>

Sorry, I don't understand the problem here. Why not just stop the ADC
sequencer, call buf_set again with the new size, and restart it (which seems
to be what you're doing now)?  You want to change it with the ADC still
running? I think this is way too complex for thte benefits it provides. Or
maybe I'm missing the problem entirely? :)

Also, for now, it seems that using the ADC automatically implies using
buffers. This might be overkill for someone that just wants one ADC sample
per call of adc_sample. Need to find a way to deal with this easier.

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
>
>

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