Large ADC Commit

[Dado Sutter]

Hello,

On Tue, Feb 17, 2009 at 10:53, James Snyder <jbsnyder at fanplastic.org> wrote:

>
> ----- "Bogdan Marinescu" <bogdan.marinescu at gmail.com> wrote:
> >.............
>
> I suppose one could also pass an existing table to getsamples, and get it
> returned with the results in it?
>

I would also prefer that the functions return the same type on all cases (so
a table passed as a parameter would do just fine for both issues).
Do you think that the small overhead caused by the table manipulation
(instead of an number) justify the returning of a diferent type (a number)
for critical speed sampling apps ?

> Best,
> > Bogdan
>

Best
Dado

>
> >
>
>> >
>> >
>> > 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
>> >
>> >
>>
>
> >
> > _______________________________________________ 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/5185c6db/attachment.html