On 01/16/2017 03:23 PM, Matthias Klumpp wrote: > 2017-01-14 18:49 GMT+01:00 Lars-Peter Clausen <lars@xxxxxxxxxx>: >> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
