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? On Monday, June 20, 2016 at 1:01:46 PM UTC-7, Wulf Man wrote: > > 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 > > > On 6/20/2016 12:53 PM, Micka wrote: > > 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. > > > Le lun. 20 juin 2016 à 21:29, < <javascript:>[email protected] > <javascript:>> a écrit : > >> 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. >> >> -- >> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> <https://groups.google.com/d/msgid/beagleboard/c5cae6bf-c8e0-45c4-ab5b-6bc236766d09%40googlegroups.com?utm_medium=email&utm_source=footer> >> https://groups.google.com/d/msgid/beagleboard/c5cae6bf-c8e0-45c4-ab5b-6bc236766d09%40googlegroups.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > 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 [email protected] <javascript:>. > To view this discussion on the web visit > <https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtnELw1UDxA79pnBs-sZp-cG%3Dq8GRWoGJpuzFCCdjwodKQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtnELw1UDxA79pnBs-sZp-cG%3Dq8GRWoGJpuzFCCdjwodKQ%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f381261d-fcb9-4c27-b58c-4298337f0c8e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
