fastest ADC for raspberry Pi 2/3 or Orange PC ?

[kripton2035]

I would like to try to measure waveforms on a raspberry, making my own programs to calculate some measurments real time.
what would be the fastest adc one can implement on a Pi ? (or clone)
does a board with an adc (and DMA and/or fpga to make the acquisition ?) already exist ? (in a raisonable price)

with an arm processor, with software only acquisition, and considering the I/O speed, what acquisition speed can we
hope to achieve on these devices ?

thanks.

[suicidaleggroll]

The limitation is going to be how quickly you can get data to the CPU.  The fastest interface might be SPI, which on the Raspberry Pi can run up to 50 MHz I believe with minimal CS lag.  If you used a CPLD/FPGA for low-level timing and buffering and streamed to the Pi over SPI as quickly as possible, you could probably maintain about 4 MB/s.  How many samples that is depends on your bit depth, which depends on the resolution you want in your analog measurements.

On a system with a better USB controller you could switch to a USB interface IC which might let you push closer to 10-20 MB/s, but the Raspberry Pi is notoriously bad when it comes to USB speed.

[kripton2035]

I want to have a 8 bits, or at most 10 bits of resolution.

[kripton2035]

is it possible to make a adc that stores directly in Pi RAM the scanned results ? is it what is called DMA ?

[timb]

The limitation is going to be how quickly you can get data to the CPU.  The fastest interface might be SPI, which on the Raspberry Pi can run up to 50 MHz I believe with minimal CS lag.  If you used a CPLD/FPGA for low-level timing and buffering and streamed to the Pi over SPI as quickly as possible, you could probably maintain about 4 MB/s.  How many samples that is depends on your bit depth, which depends on the resolution you want in your analog measurements.

On a system with a better USB controller you could switch to a USB interface IC which might let you push closer to 10-20 MB/s, but the Raspberry Pi is notoriously bad when it comes to USB speed.

Using DMA you can toggle multiple GPIO at ~50MHz, so you could implement a parallel interface.

Alternatively, if you went with a BeagleBone Black, you could use one (or both) of the two built-in programmable MCU sub-processors to implement a *very* fast LVDS interface. You can push data at *very* high speeds that way.

[kripton2035]

around what value is "very" ?

[kripton2035]

are there any example around there for an implementation of a DMA on a Pi ?

[julianhigginson]

you get 40Ms/sec into a pi over USB, apparently?
http://www.bitscope.com/pi/

[suicidaleggroll]

you get 40Ms/sec into a pi over USB, apparently?
http://www.bitscope.com/pi/

Not according to this page:
http://www.bitscope.com/pi/blog/201309/?p=DI25A

BitScope can capture multiple analog and digital signals at very high sample rates (up to 40MSps in some cases) or it can stream continously at lower sample rates

So it can only burst at 40 MS/s.  Probably a limitation of the RPi's USB interface

[julianhigginson]

aaah.. that would make sense. :-)

[kripton2035]

well, for anyone interested, I've got an answer here :
https://github.com/hzeller/rpi-gpio-dma-demo

The resulting output wave on the Raspberry Pi 1 of 22.7Mhz, the Raspberry Pi 2 reaches 41.7Mhz and the Raspberry Pi 3 65.8 Mhz.

surprisingly, using the DMA chip gives slower results than direct CPU access !

[danadak]

In DSO design there is an inherent latency between acquisition and measurement.
That is "normal" flow is samples are acquired for the specific sweep, then measurements
made on sample set. This largey controls the update rate of the DSO. acquisition and
measurment.

http://cp.literature.agilent.com/litweb/pdf/5989-7885EN.pdf

http://www.epdtonthenet.net/article/14549/Why-gamble-with-DSO-update-rates-.aspx


The measurement phase is largely code execution. One starts to think of DSP engine for
the math handling.

Regards, Dana.

[XFDDesign]

In my own acquisition work, I found that not having a means of setting up interrupts or other means of Real-time response made for a bad time. I could pipe a lot of data very fast in a burst, but not at reliable intervals due to linux not being a RTOS.

"Real time" is going to be something of a snipe-hunt here because we don't have any actual information or context on the problem you're attempting to solve. I can technically attach a 2.5GSPS ADC to the thing, but won't get 'real-time' throughput on the thing. I could glue on a 1ksps ADC, and to very-much real-time work with it, if my signal processing is simply running a 64 point FIR filter. Knowing what you want to do is going to be far more useful than getting all the numbers of specs of the highest-end X possible.

[timb]

In my own acquisition work, I found that not having a means of setting up interrupts or other means of Real-time response made for a bad time. I could pipe a lot of data very fast in a burst, but not at reliable intervals due to linux not being a RTOS.

"Real time" is going to be something of a snipe-hunt here because we don't have any actual information or context on the problem you're attempting to solve. I can technically attach a 2.5GSPS ADC to the thing, but won't get 'real-time' throughput on the thing. I could glue on a 1ksps ADC, and to very-much real-time work with it, if my signal processing is simply running a 64 point FIR filter. Knowing what you want to do is going to be far more useful than getting all the numbers of specs of the highest-end X possible.

Right, this is why I recommended the OP look into a BeagleBone Black. The TI OMAP (or Sitara or whatever they're calling it this week) has two onboard sub-processors, which they call PRUSS (Programmable Real-time Unit Subsystem).

The PRUSS is composed of two PRUs, which are essentially little MCUs with direct access to the main CPU's I/O, a shared memory buffer (between both PRUs and between the PRUs and the CPU) plus dedicated interrupts. Each PRU is a custom 32-bit RISC core that can complete most instructions in 1 to 2 cycles.


When the BBB first came out, there was basically no information on the PRUs available, aside from a couple attempts to reverse engineer it and create a compiler from scratch. Fortunately, about two years ago TI released a bunch of information on it, including the official assembler package.

As of now, the assembler is very mature and works well; there's also a cross compiler available so you can program them in C! Once you enable the PRUs via a Device Tree Overlay, they can be programmed right from the command line, which is pretty slick.

There's also a few libraries available that grant you high speed GPIO/ADC access from C/Python/Node.JS/etc. via the PRUs without actually having to write code for the PRUs! (See: libpruio)

The takeaway here is that the PRUs allow real, hardware based realtime control from a non-realtime OS. The PRUSS can read/write GPIO at the main CPU's bus speed, which is 200MHz. If you combine that with an external parallel 8/10/12-bit ADC, you could certainly do some realtime sampling.

[Rasz]

Dont forget Pee camera interface. There is an open source univeral MIPI CSI driver for Pee. Afaik one mipi line goes up to 100MB/s, and you have two on ordinary Pees and four on industrial module.
Lattice offers free mipi csi interface IP for their fpgas = $20 chip could pump up to 200MB/s into Pee.

[XFDDesign]

:words:

This is all very fair, but we still don't know the actual problem we're trying to solve for the guy. I don't think he even knows the problem he's trying to solve, rather he has an idea of something and hasn't thought it all the way through.

[westfw]

is it possible to make a adc that stores directly in Pi RAM the scanned results ? is it what is called DMA ?

The RPi doesn't support the sort of "direct DMA" that you're talking about.  It has some internal DMA controllers that support the on-chip peripherals (including GPIO), but the example you found (GPIO output via DMA) is probably not going to work for triggered input from an external data source (and would certainly be slower than the output example.)

surprisingly, using the DMA chip gives slower results than direct CPU access !

It shouldn't be too surprising.  Direct CPU access will be accessing the cache memory, which is much faster than actual DRAM.