Re: Using IIO for high-speed DAQ

[Lars-Peter Clausen <lars@metafoo.de>]

On 01/16/2017 03:23 PM, Matthias Klumpp wrote:
> 2017-01-14 18:49 GMT+01:00 Lars-Peter Clausen <lars@metafoo.de>:
>> On 01/14/2017 06:18 PM, Matthias Klumpp wrote:
>>>> The IIO framework itself does not impose a limit on the maximum sampling
>>>> rate. It's all a matter of what the hardware is capable of handling. We have
>>>> systems where we do 3-digit MSPS continuous transfers and GSPS oneshot
>>>> transfers.
>>>
>>> Since this is the first time I touched this area: Is there a group of
>>> chips which you would recommend that samples with 200ksps, has a 16bit
>>> bit-depth and bipolar mode and is accessible at that speed via IIO?
>>> I'll look around a bit to find a solution for this issue.
>>
>> Unfortunately this is often as  much about the AP as it is about the
>> converter. In the setups we have we use a AP+FPGA combination where the AP
>> runs Linux with IIO and the FPGA is responsible for handling the SPI flow
>> control during the acquisition phase. For this we've developed the
>> SPI-Engine framework[1]. It is compatible with most ADI single-channel SAR
>> and Sigma-Delta ADCs[2].
>> [...]
> 
> Thanks!
> I was already looking into this, but also tried to access the BCM2835
> on my Raspberry Pi test device directly (someone wrote a nice helper
> library for that at [1]).
> Turns out that using this library, I can easily achieve my desired
> speed of 200ksps (it also turned out that with a few changes on the
> setup, 6ksps can be just enough...).

This is basically the dedicated CPU approach I described. Your application
is spinning on the SPI registers and not using interrupts. This means a lot
of CPU time is used for busy-waiting. If you are issuing one transfer after
another CPU utilization will go to 100%.

One issue with doing this in Linux userspace is that your application will
still get interrupted occasionally, either to run interrupts or potentially
schedule other applications for a short duration on the CPU. When this
happens there is a good chance that you'll loose a few sample and have a
discontinuity in your signal. Which will show itself in strange glitches
when you are processing the data.