Wow, I think that /dev/mem + mmap() is the easy solution! Many thanks. But can you please confirm that by "200ksps for 7 channel simultaneously" you mean that each of the 7 channels is being sampled 200k times per second. If so, that's 1.4M captures per second, enough for my project.
> But CPU usage is so high, that you're not going to be able to do a whole lot more in addition to reading the ADC in this fashion. This is essentially a lab experiment. The program only needs to run correctly once (though it will take many executions to get all the external factors right). On each run, the BBB has no other tasks to perform. It won't start writing the results to a file until after the capture is complete. If CPU usage during the capture is 95%, that's fine. If it's 105%, I'll slow the sample rate a bit to avoid losing samples. But if it's 250%, then I'm in trouble. If not missing samples requires running in single-user mode with no networking and only a serial console, that's IMO a minor nuisance compared to learning about PRU, etc. and debugging a much more complex program. On Monday, June 20, 2016 at 2:53:47 PM UTC-7, William Hermans wrote: > > The ADC module is a 200ksps SAR module . . .You're only going to be able > to sample 200k samples per second . . . > > Additionally you can use: > > > 1. PRUs ( Programmable Real-time Units ) > 2. IIO ( industrial IO ) > 3. /dev/mem/ + mmap() > > > To read 200ksps. Personally, I've proven that /dev/mem + mmap() can work > for reading 200ksps for 7 channel simultaneously. But CPU usage is so high, > that you're not going ot be able to do a whole lot more in addition to > reading the ADC in this fashion. Hence, the PRU are best used, as this > offers hardware offload( very little CPU load needed - and only when > reading values out ). > > On Mon, Jun 20, 2016 at 12:00 PM, Stewart <[email protected] > <javascript:>> 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 >> --- >> 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/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. >> > > -- 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/2ff2e93c-ca65-46ec-a755-5c7f830da2b1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
