Large ADC Commit

[BogdanM]

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
)

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

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.

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090216/fba18a46/attachment.html