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 > On Jun 20, 2016, at 12:00 PM, Stewart <snelson.st...@gmail.com> wrote: > > 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 > <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+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/0543FF25-240A-4275-8BB4-5F93E48F28D9%40gmail.com. For more options, visit https://groups.google.com/d/optout.
