A Few Models For Dealing With ADC Samples

[jbsnyder]

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

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
call function again to get samples from the sampling period, and start next set of sampling

Advantages:
- Samples collected in the background, can do other work while samples are collected.
- Samples are collected using fairly deterministic timer-based interrupt system.
- Time gap between blocks of samples can be minimized because next set of samples can be requested as last set is returned

Disadvantages:
- Slightly more complicated buffering
- Initial call returns nothing, but subsequent calls return samples
- There will always be samples "left over" because each call requests more (unless some option is passed to indicate it is the last call)


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

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


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

Bogdan, Dado, Jeusus or anyone else: Thoughts/ideas would be appreciated :-)

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