I’m looking to write a simple app for BBB. When started from the command line, it would set up the ADC in continuous mode and read ~1 M samples from e.g. AN0 into memory. After the capture is complete, it would write the data to a file and exit.
Ideally, it would run at the hardware limit of 1.6 MSPS (15 cycles of 24 MHz adc_clk per sample). If that’s not practical, 800 KSPS or better would be acceptable.
What is an easy way to do this? Most Beaglebone ADC examples sample at kilohertz rates or slower.
I’ve seen various suggestions to use the PRU, but don’t understand why. I would think that since DMA would be required anyway, there should be no requirement to otherwise access the hardware with tight timing. If PRU is indeed necessary, is there a suitable example or tutorial? (None of the libpruio built-in examples deal with rapid sampling or large amounts of data.)
Any other ideas for a simple way to capture data fast will be gratefully appreciated.
The ADC block is rated for 200Ksps max. The easiest thing to do is a quick
char device driver that configure the ADC with the right settling times and
have the DMA engine gather the data. Once you have that all you need to do is
cat /dev/foobar > file.
The block doesn't run from 24MHz. It is divided down. IIRC, it needs to be
around 6MHz.
The PRU is indeed unnecessary and a waste of resources. All that does is turn
the flexible PRU into a DMA engine but there is a hard DMA engine on the SoC
already.
I have been working on adding DMA to the ADC driver, but it currently it throws overflow errors before DMA starts. The DMA should trigger when the ADC fifo reaches a predefined threshold, but for some reason there is a delay before DMA triggers. The ADC driver uses the IIO framework and I’m using their experimental DMA buffer framework which has its share of issues. I’m trying to diagnose the error by replicating the setup in Starterware. Unfortunately the CCS debugger isn’t all that helpful so now I’m trying to get my Lauterbach working Starterware, but I have to translate the CCS GEL scripts to Lauterbach Practice scripts.
Regarding the sampling rate, the datasheet does specify 200ksps, but if you setup the sample delay, open delay, etc, it should be possible to achieve something like 1.5msps, but I haven’t been able to verify this yet.
Section 12.2.2 reads (in part):
Clock Signal Max Freq
adc_clk 24 MHz
ADC clock (typ)
Section12.3.7 reads (in part):
Sampling rate can be as fast as every 15 ADC clock cycles
This works out to 1.6 MSPS, a number that I’ve also seen in numerous credible posts. It seems logical, requiring 12 clock cycles for the SAR process; the remaining 3 being overhead to sample, initialize and store.
However, I’ve not heard of anyone actually get it to work at anything near that speed, though I also haven’t found any info stating why it can’t. There is an ADC_CLKDIV Register described in section 12.5.1.13 . Although the ‘Reset’ value is 0 (corresponding to division by 1), I’ve read in various places that the ‘default’ value (presumably initialized by some driver) is 7 (corresponding to division by 8), which would indeed make the ‘15 ADC clock cycles’ sample rate 200 KSPS.
the best woud be the PRU because you can store the data in the share memory.
Do you mean the 12KB data memory? As I understand it, it’s only shared between PRUs, not directly with the CPU. Moving data from there to the CPU would require DMA, as ‘programmed’ access would not keep up with 1.6 MSPS. Is that right? But if I understand correctly, the ADC can be configured to send its results (through an intermediate FIFO) to DMA, so the PRU would just be a needless layer of complexity.
Of course, If I could find free or inexpensive software that needed little or no modification to do the job, I wouldn’t mind if it happened to use the PRU
The ADC block is rated for 200Ksps max. The easiest thing to do is a quick
char device driver that configure the ADC with the right settling times and
have the DMA engine gather the data. Once you have that all you need to do is
cat /dev/foobar > file.
No point. IIO is already included, and used with the latest debian images.
