AnsweredAssumed Answered

IIO buffer and trigger mechanisms for ADAR7251 and AD7685

Question asked by HStoner on Sep 1, 2015
Latest reply on Sep 2, 2015 by larsc
Branched from an earlier discussion

If I may continue this thread, I'd like to focus it on some actual devices that we are using that I am currently having questions about. 

We have some SoCKit / ARRadio eval boards with AD9361 devices.

I am also currently trying to develop an IIO driver for the ADAR7251, which has no existing ADI device driver at this time.  I'm also working with an AD7685, which is supported by an existing ADI IIO driver, the AD7476 driver.


Although it looks like control will be relatively straightforward to implement within the IIO driver context, the data transfer mechanisms haven't been worked out for either of these devices yet, and I need to make sure we can hook in our fpga-based transfer mechanism with the linux IIO device drivers for these parts.


For both the ADAR7251 and the AD7685, we'll be using sample rates that range from ~200 kSPS (for the AD7685) to 1.2 MSPS (x4 channels, for the ADAR7251).


These are rates at which we don't want to try to implement an interrupt-per-sample approach.  What I believe will happen is that we'll want to set some registers in our fpga core to indicate:

- how many samples we want to collect in a buffer;

- what the trigger will be to start filling the buffer;

- what the fpga-generated interrupt will be to the processor when the transfer is complete.

The fpga will collect and store the samples in some SDRAM, hopefully in an exact format that is compatible with an IIO buffer.  Then we'd like to fill the IIO buffer from this memory, possibly mmap'd to the processor.


The only triggering mechanisms I have seen appear to rely on a one-interrupt per sample, where the trigger source generates the interrupt.

What I'd like to figure out is how this can be fit into the iio and libiio framework, to instead have a driver-based interrupt handler triggered only when the required number of samples has been collected, and then to be able to move the samples into the iio buffers, preferably without having to implement a sample-by-sample call to 'iio_push_to_buffer()'. 


For example, is it possible to have iio_push_to_buffer operate on a block of data rather than a sample at a time? 

Or what is a better way to do this blocked transfer to iio buffers? 

I don't know at this point whether we can count on a dma controller mechanism, or how straightfoward this will be to implement.   We likely don't need continuous streaming at this point (e.g. what the AD9361/4 drivers are doing), but will want to transfer blocks of 10's-to-100's of thousands of samples per collection request).


Currently for the ADAR7251 driver I started with the iio simple dummy driver in the staging area, and implemented the iio parameter control interfaces needed for the ADAR7251 device.   The fpga-based sample recording code still needs to be developed (by others), but I want to ensure that both I and the developers of the fpga have the requirements for us to make this fit within the IIO framework so that libiio can be used (currently it will be used entirely locally, but later perhaps networked) by application programs.