Large ADC Commit

[jbsnyder]

----- "Bogdan Marinescu" <bogdan.marinescu at gmail.com> wrote:
>
>
>

>
> 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, I've not put this in yet, but I'll get it on a next pass.

>
>



> 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? :)

Well, this depends on what one wants. The buf starts with only 2 slots for ADC. If I only every use one or two slots and always pick up my samples, this is fine. If I instead want to capture 8 before I pull them in, perhaps I want my buffer a bit larger. This could be done by making the default buffer size larger, or by growing it a bit on the fly. The only major problem with growing on the fly is if the read pointer is further down the buffer than the write pointer. If the array grows before the read pointer has caught back up, then I might pull in newly allocated buffer space instead of the samples I expect. Here's an example:

buffer of length 8:
| | | wptr | | | | rptr | |

so there are 4 samples here that i can still pick up..

if I want to grow this buffer to 16:
| | | wptr | | | | rptr | | | | | | | | | |

now I won't get what I expect, unless I copy the first couple samples from the old buffer into the new buffer space.

I don't think I would resize the buffer while the ADC is collecting samples, since that could get messy. I would only do resizing on sample requests.

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

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

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.

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

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