A Few Models For Dealing With ADC Samples

[Dado Sutter]

Hello you all,

On Wed, Feb 18, 2009 at 01:08, James Snyder <jbsnyder at fanplastic.org> wrote:

> > I'm still inclined to keep initiation of sampling and picking up of
> samples separate though, unless there is a way to seriously reduce the
> number of microseconds each function call takes.  If channels:getsamples(10)
> does both initiation and collection of samples back to lua, the timing
> between samples collected might be deterministic, but if you're doing that
> repeatedly, the time in between each call will not be :-)
>
>
> Let me rephrase the above a little bit with regards to determinisim.  This
> isn't really an argument against or for this alternate approach for setting
> up and getting values from the ADC module (I really like the ability to tie
> sampling on multiple channels to one another, as well as the different
> linguistic style. Both would be excellent!), it's more about some of the
> complexity that's now present.  I think there should be at least the ability
> to separate initiation of sampling from the command to get those samples
> because if they're the same you get a few main options (if getting samples
> must be tied to a function):
>
> Single Function to Request and Return:
> 1. Simple Model
> call function to start sampling
> function waits for sampling to finish
> function returns samples
>
> Advantages:
> - Simple.
> - No complex buffering issues.
> - No background resource usage
>
> Disadvantages
> - Can't do any work while you wait, regardless of sampling rate
> - If you just need one sample per loop, timing may vary 10s to 100s of
> microseconds between each sample.
> - If you ask for multiple samples, timing between samples may be
> consistent, but there will be gaps between each time the function is called.
>

... - And even here timing be between samples can be inconsistent, if the
business logic forces gc in some inpredictable ways.

2. Non-blocking Model (this was present in an earlier version of the ADC
> module)
> call function to start sampling, function returns
> do some other stuff
>

- ask adc if it has data ready for us (ok, we can dismiss it if we're shure
we've worked longer than the sampling period (but not too much, as we may
get a buffer overflow))

call function again to get samples from the sampling period, and start next
> set of sampling
>

You mean, call the _same_ function to getsamples and to start another
sampling cycle ?
This could speed up things a bit on the but it dimms the advantages of your
two-functions scheme for sampling and reading data.


> Advantages:
> - Samples collected in the background, can do other work while samples are
> collected.
> - Samples are collected using fairly deterministic timer-based interrupt
> system.
>

Yes, nice ! Preferably real tmr channels here for tight timming and low
latency.

- Time gap between blocks of samples can be minimized because next set of
> samples can be requested as last set is returned
>

Same comment above, for the two/one function scheme.

Disadvantages:
> - Slightly more complicated buffering
>

Coding doesn't seem to be an issue for you :) :)


> - Initial call returns nothing, but subsequent calls return samples
>

Can be done consistent for reading loops or, in the future (when we have a
generic INT module), a good ISR callback system even in Lua (I still have no
idea on the performance aspects of this).

- There will always be samples "left over" because each call requests more
> (unless some option is passed to indicate it is the last call)
>

Not a big deal neither, as the main program knows what it wants. It can
simply stop sampling and flush the buffer (if really needed) after the last
required sampling cycle.


Separate Request & Return Functions:

> 3. Separated Request/Return Model
> call function to start sampling, function returns
> do other work
> use another function to get samples in the buffer (this can be done while
> sampling is still happening)
>
> Advantages:
> - samples collected in the background, other work can be done while samples
> are collected
> - samples collected using fairly deterministic timer-based interrupt system
> - longer deterministic periods can be used where one can request 100
> samples, but only pull in 5 at a time while sampling is happening, while
> still getting low timing jitter
>

Low jitter here can be kind of fuzzy. Determinism should be 100%
deterministic no ?


> - could be extended to support indefinite periods of sampling with buffer
> wrapping if samples aren't pulled out fast enough, but when you do need
> samples you can pull out up to the length of the buffer and they're still
> pretty well-timed
>

Well _that_ seems harder to code but again, it doesn't seem to be an issue
for you :)
I like the (energy waste) ability to leave the sampling "on" and get
(current/last sampled !!!) data whenever we need. It can be usefull and
simplify some apps.
But for this we would need a way to specify/fix the buffer lenght right ?
(more sintatic issues :(  )

Disadvantages:
> - more complicated, including dealing with buffer sizes
> - multiple commands needed to initiate/get samples
>

yeap, yeap.

> One alternative that I've not mentioned here is that there be two
> functional models for getting samples.  If one wants, one could have a
> simple getsamples method that follows model 1, and a second pair that
> follows model 3. i.e.:
>
> channels = adc.channel(0, 3, 17, 21)
>
> -- Style 1: Simple Blocking Model
> a = channels:getsamples(count)
>
> -- Style 2: Separated Model
> channels:requestsamples(count, timer, frequency)
> channels:returnsamples(count)
>
> In any case, I think there are a few more discussions to have, and I'll
> hold off for a little bit with code commits until we settle things a little
> more :-)
>

Now that seems to be the real problem. Not only to refine the models but to
have to chose one (two?) among them :)
Thank you very much for this clear and concise explanation !! It will
surelly help a lot for others to share opinions too.


> Bogdan, Dado, Jeusus or anyone else:
>

Unfair competition here :-o
(Sorry !!! I just could't resist :) :)


>   Thoughts/ideas would be appreciated :-)
>

Definetely.

-jsnyder
>

Best
Dado











>
>
> _______________________________________________
> 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/20090218/c36edbcd/attachment-0001.html