Large ADC Commit

classic Classic list List threaded Threaded
1 message Options
BogdanM BogdanM
Reply | Threaded
Open this post in threaded view

Large ADC Commit

> 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:
> typedef u8 t_adc_data
> typedef u16 t_adc_data
> 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

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
> >
> > On Mon, Feb 16, 2009 at 3:12 AM, James Snyder <jbsnyder at>
> 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
> > >
> > >
> >
> >
> > _______________________________________________ Elua-dev mailing list
> Elua-dev at
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at
-------------- next part --------------
An HTML attachment was scrubbed...