[API] Buffered IIO reads for ADC

[arfoll]

Instead of hardcoding an IIO file for the ADC we should really iterate on the IIO devices of type ADC and then use that. Secondly it should be possible to ask for a number of AIO reads instead of one read.

[alext-mkrs]

I'm thinking about taking this one on, so let me try to understand the idea better.

It looks like we can't just convert the existing read functions to be able to return several values without breaking the API. Do we care? I presume we do, so the next best seems to be introducing a pair of additional functions for this sort of reading, say mraa_aio_read_buffered() and mraa_aio_read_float_buffered(). Do you think that's viable? Any other ideas?

[alex-ter]

@arfoll, @tingleby, ping 😃

[tingleby]

pong!
Yes it would be wise not to break the existing API. Not at this point at least ;)

[arfoll]

Yes having a _buffered() or _block() functions. Tbh the trick is working out ow to do this from IIO which is tricky, the function names can be worked out afterwards :)

[alex-ter]

Thank you both!

Yeah, there's apparently more to it than just defining the names, but I want to lay the foundations right from the very beginning 😃

[arfoll]

If you manage to do this tbh you can call them mraa_aio_read_alex_is_awesome() for all I care!

[tingleby]

I was reading about IIO for something else today. Perhaps this will help.
http://wiki.analog.com/software/linux/docs/iio/iio
http://events.linuxfoundation.org/sites/events/files/slides/iio_high_speed.pdf

Some might be out of date, not even attempted anything with it.

[alext-mkrs]

Thanks, that could be useful.

[alext-mkrs]

Just wanted to let you know gentlemen that I'm still on this one, just got thrown back by some private stuff - but I'm back now (better late than never 😃 ).

[arfoll]

Assigned ;-) You're on the hook now ehehe

[alext-mkrs]

Some information on buffered reads which I'd like to run by you, @arfoll and @tingleby

After exploration on IIO in general and ADC driver implementations on Galileo and Edison in particular my understanding is that using IIO triggered buffer, which is theoretically the natural way of doing what the enhancement request entails, is meaningless and result-wise is not really different than implementing it by calling existing MRAA mraa_aio_read() in a loop.

Neither of the two drivers seem to support the automatic buffer population in a continuous manner and does not by default expose the trigger interface. By using iio-trig-sysfs module I was able to setup the whole necessary chain for a triggered buffer, but even in such setup we need to trigger the reading manually and it's one-shot (i.e. one trigger activation yields one result in the buffer, to have several I have to trigger it several times) - making it essentially the same as we do today, i.e. readings the <...>_raw sysfs file several times in a row.

So if you have any ideas or know more than I found out so far - I'm all ears. This is my first deep dive into IIO, so I may be missing something even though I've quite scrupulous in doing my homework before asking 😃

Let me also try to pull Dave Hunt in here, who is listed as the author of the Edison's ADC driver and his colleague from Emutex is the author of the one for Galileo.

@climberhunt - Dave, could you please comment on this? Is my undertstanding correct? If not, I'd be grateful for any pointers. I see both drivers actually have the <...>_trigger_handler function implemented, which sort of suggests the functionality should be working or at least partially implemented, but I don't see any way to launch that "trigger launched polling to ring buffer" as the comment in Edison's driver states.

What we're after here is a mode when MRAA user would ask for a number of samples to return and my understanding of IIO is that there is a mode where we can just ask the subsystem for a buffer of a respective length, then "push" the trigger and IIO+driver+ADC itself will populate the buffer with requested number of samples - though it looks like it's inaccessible on Edison and Galileo.

[arfoll]

That's a bit dissapointing, I haven't looked in enough detail but that sounds reasonable. Weird that you can get the trigger to be done by the kernel at least and not userspace. I guess we'll leave it open and hopefully someone will show us how wrong we are :)

[alext-mkrs]

Yeah, looks like that's the best option as of today.

BTW as far as automatic discovery of ADC-type devices is concerned, that looks infeasible too :) Generally, there's no "type" for the device in IIO, only a device's channel type, which theoretically could be used for that (there's a "voltage" type, which is generally teh one used for ADCs). But then what would we do when there are two devices with channels of type "voltage"? E.g. Edison's PMIC has one, so it's listed as iio:device0 with one "voltage" channel. And the actual ADC is iio:device1 with eight "voltage" channels. So we'd need to either make some assumptions based onnumber of channels or device names or something like that - all of which look equally inelegant to me :) So IMHO current way of using the specific device name is actually the best as it leaves no room for hitting a wrong device (at least until device numbering is predictable).