Capture analog input at near maximum sample rate?

[snelso...@gmail.com]

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.

This guide: http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User%27s_Guide speaks of 200 KSPS.  What is the limitation here?

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.

Thanks.

[Micka]

the best woud be the PRU because you can store the data in the share memory. That is the fastest way.

you can stop the acquisition whenever you want or let it go back at the beginning of your memory and go on.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c5cae6bf-c8e0-45c4-ab5b-6bc236766d09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[evilwulfie]

on the am355x processor the ADC used is 12 bit SAR ADC with a sample rate of 200 KSPS

any faster and you will need an external ADC

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtnELw1UDxA79pnBs-sZp-cG%3Dq8GRWoGJpuzFCCdjwodKQ%40mail.gmail.com.

[Hunyue Yau]

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.

--
Hunyue Yau
http://www.hy-research.com/

[John Syne]

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.

Regards,
John

> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1496053.WtKKS7Pqg7%40acer0.

[snelso...@gmail.com]

Thanks for the reply.

I'm looking at the AM335x Technical Reference Manual, downloaded from
http://phytec.com/wiki/images/7/72/AM335x_techincal_reference_manual.pdf

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.

Do you know what the obstacle is?  

[snelso...@gmail.com]

> 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 :)

Thanks.

[William Hermans]

http://lmgtfy.com/?q=AM335c+ADC+module -> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#Introduction

An analog-to-digital converter (abbreviated ADC) is a device that uses sampling to convert a continuous quantity to a discrete time representation in digital form.

The TSC_ADC_SS (Touchscreen_ADC_subsystem) is an 8 channel general purpose ADC, with optional support for interleaving Touch Screen conversions. The TSC_ADC_SS can be used and configured in one of the following application options:

• 8 general purpose ADC channels
• 4 wire TS, with 4 general purpose ADC channels
• 5 wire TS, with 3 general purpose ADC channels
• 8 wire TS

ADC used is 12 bit SAR ADC with a sample rate of 200 KSPS (Kilo Samples Per Second). The ADC samples the analog signal when "start of conversion" signal is high and continues sampling 1 clock cycle after the falling edge. It captures the signal at the end of sampling period and starts conversion. It uses 12 clock cycles to digitize the sampled input; then an "end of conversion" signal is enabled high indicating that the digital data ADCOUT<11:0> is ready for SW to consume. A new conversion cycle can be initiated after the previous data is read. Please note that the ADC output is positive binary weighted data.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/bd593480-ae6b-453b-addd-0b9cb07036d6%40googlegroups.com.

[William Hermans]

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.