Large ADC Commit

[BogdanM]

> I did however, make the paradigm adjustment so that sample and burst never
> return anything other than errors (if encountered).  A separate function
> called getsamples is now used to pull things out of the buffer when they're
> ready.  getsamples takes channel_id and a count of samples desired.  If
> count is either 0 when passed, or let off (call just with the channel arg),
> then all samples that are in the buffer are returned.
>

Nice, let's leave it like this for now. You should probably also update the
Lua ADC interface (by removing the 'setmode' function).


> If the total number of samples that is being returned is 1, then an integer
> is returned.  If more than one sample is being returned, you get a table of
> integers.
>

This is a problem. Not because of your implementation, but because you have
to return a NEW table each time you call this function, which would quickly
exhaust memory. I'm thinking about ways to solve this, will come up with
some ideas later. One of them involves making my rotables not-so-ROM-only,
and allowing them to be accesses from RAM (under certain restrictions), in
which case one could simply use a buffer allocated via malloc() and return
it each time if the number of requested samples doesn't change (which I
suspect is the case with most applications). But this requires some changes
in LTR, and I'm not sure how well they'll work.

I've also updated adcscope.lua to be faster (using local actually sped
> things up about 3x) and to use the terminal to output results rather than
> the RIT display found on LM3S.
>

Cool, can't wait to check it out. Last night (about 16 hours ago) when I
checked adcscope.lua on my LM3S board, it didn't work. Let's see what
happens this time.

Best,
Bogdan

>
> On Feb 16, 2009, at 11:15 AM, James Snyder wrote:
>
> Hi -
>
> Thanks for the comments :-)
>
> ----- "Bogdan Marinescu" <bogdan.marinescu at gmail.com> wrote:
> > Hi,
> >
> > I still have to look at the code carefully and figure out what exactly
> you did there :), but for now a few simple observations:
> >
> > 1. it occured to me that since buf_init already expects a logarithmic
> parameter, it probably makes sense to make it expect two logarithmic
> parameters, so instead of this:
> >
> > int buf_set( unsigned resid, unsigned resnum, u8 logsize, size_t dsize )
> >
> > we'll have this:
> >
> > int buf_set( unsigned resid, unsigned resnum, u8 logsize, size_t *log*dsize
> )
>
> I was thinking about doing this, I'll make the change.
>
> >
> > 2. Since you did this:
> >
> >   pbuf->logsize = logsize + ( pbuf->logdsize );
> >
> > in buf_set, you probably need to modify this:
> >
> > #define BUF_MOD_INCR( p, m ) p->m = ( p->m + ( ( u16 )1 << p->logdsize )
> ) & ( ( ( u16 )1 << ( p->logsize + p->logdsize) ) - 1 )
> >
> > (because you add logdsize to logsize once again, and I don't think this
> is right).
>
> Ooops.  That would likely be the cause of some of the random crashes I was
> seeing :-)  (currently worked around somewhat)
>
> >
> > 3. The data size of an ADC is not always 16 bits, so we should add
> another (probably also logarithmic) parameter to elua_adc/adc_init_state.
>
> 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
>
> >
> > 4. As for the change you proposed, as I said I still have to figure out
> what exactly your code does :), but for now it makes sense. I'll get back to
> you with more information. Fortunately we don't really have a pre-existing
> paradigm, we just have some proposals, so we can change everything we don't
> like.
>
> 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.
>
> One way to handle this would be copying data so that the freshly resized
> buffer is coherent again.  Another would be to somehow grow the buffer in
> the space between the rptr and the wptr.  This, however, without moving data
> around, even if it were possible, would result in fragmentation.
>
> If I were to just do an implementation without further research it might
> look like this:
>
> 1. If wptr > rptr, just realloc.
> 2. If rptr > wptr, move all of the elements between buf (array start
> pointer) and wptr to space after the wrapping point of the original,
> smaller, buffer.
>
> If we could also grow the buffer at the starting end, maybe we could decide
> whether adding at the start or the end would result in more copying.
>
> I'm not as concerned about algorithms for downsizing the buffer to conserve
> space.  I think instead of dealing with copying in this case, the downsizing
> might just be done whenever the buffer runs dry, and if no new interesting
> requests are pending, drop down to some reasonable default size.
>
> Any thoughts or ideas would certainly be appreciated.
>
> >
> > 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
>
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> jbsnyder at fanplastic.org
> http://fanplastic.org/key.txt
> ph: [phone]
>
>
> _______________________________________________
> 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/027e4e0e/attachment-0001.html