fastest ADC for raspberry Pi 2/3 or Orange PC ? - Page 1
Forum section: electronics / general

author: kripton2035
author_rank: Super Contributor
timestamp: November 08, 2016, 06:53:43 pm
content: 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 wehope to achieve on these devices ?thanks.

author: suicidaleggroll
author_rank: Super Contributor
timestamp: November 08, 2016, 07:10:23 pm
content: 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.

author: kripton2035
author_rank: Super Contributor
timestamp: November 08, 2016, 08:02:59 pm
content: I want to have a 8 bits, or at most 10 bits of resolution.

author: kripton2035
author_rank: Super Contributor
timestamp: November 08, 2016, 08:05:10 pm
content: is it possible to make a adc that stores directly in Pi RAM the scanned results ? is it what is called DMA ?

author: timb
author_rank: Super Contributor
timestamp: November 08, 2016, 08:07:51 pm
content: Quote from: suicidaleggroll on November 08, 2016, 07:10:23 pmUsing 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.

author: kripton2035
author_rank: Super Contributor
timestamp: November 08, 2016, 08:54:55 pm
content: around what value is "very" ?

author: kripton2035
author_rank: Super Contributor
timestamp: November 08, 2016, 08:56:47 pm
content: are there any example around there for an implementation of a DMA on a Pi ?

author: julianhigginson
author_rank: Frequent Contributor
timestamp: November 08, 2016, 11:36:17 pm
content: you get 40Ms/sec into a pi over USB, apparently?http://www.bitscope.com/pi/

author: suicidaleggroll
author_rank: Super Contributor
timestamp: November 08, 2016, 11:47:03 pm
content: Quote from: julianhigginson on November 08, 2016, 11:36:17 pmNot according to this page:http://www.bitscope.com/pi/blog/201309/?p=DI25AQuoteSo it can only burst at 40 MS/s. Probably a limitation of the RPi's USB interface

author: julianhigginson
author_rank: Frequent Contributor
timestamp: November 09, 2016, 10:12:20 am
content: aaah.. that would make sense. :-)

author: kripton2035
author_rank: Super Contributor
timestamp: November 10, 2016, 10:00:36 pm
content: well, for anyone interested, I've got an answer here :https://github.com/hzeller/rpi-gpio-dma-demoThe 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 !

author: danadak
author_rank: Super Contributor
timestamp: November 11, 2016, 11:31:28 am
content: 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 measurementsmade on sample set. This largey controls the update rate of the DSO. acquisition andmeasurment.http://cp.literature.agilent.com/litweb/pdf/5989-7885EN.pdfhttp://www.epdtonthenet.net/article/14549/Why-gamble-with-DSO-update-rates-.aspxThe measurement phase is largely code execution. One starts to think of DSP engine forthe math handling.Regards, Dana.

author: XFDDesign
author_rank: Frequent Contributor
timestamp: November 11, 2016, 04:11:50 pm
content: 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 todois going to be far more useful than getting all the numbers of specs of the highest-end X possible.

author: timb
author_rank: Super Contributor
timestamp: November 13, 2016, 12:43:36 am
content: Quote from: XFDDesign on November 11, 2016, 04:11:50 pmRight, 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.

author: Rasz
author_rank: Super Contributor
timestamp: November 13, 2016, 05:59:35 am
content: 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.

author: XFDDesign
author_rank: Frequent Contributor
timestamp: November 14, 2016, 02:26:00 pm
content: Quote from: timb on November 13, 2016, 12:43:36 amThis 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.

author: westfw
author_rank: Super Contributor
timestamp: November 14, 2016, 09:37:57 pm
content: QuoteThe 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.)QuoteIt shouldn't be too surprising. Direct CPU access will be accessing the cache memory, which is much faster than actual DRAM.