The ADC uses a sequencer and you can only read the sample when the samples are complete. The sequencer provides an interrupt or triggers a DMA transfer when the EOC (End of Conversion) is achieved. Since you cannot service interrupts in userspace, you will have to poll repeatedly to wait for the conversion to complete. Given the non deterministic nature of Linux, you will miss some of the conversions when you processor utilization is high. Polling itself will cause high CPU utilization. Hence the /dev/mem + mmap() won’t work.
Regards, John > On Jun 20, 2016, at 4:40 PM, [email protected] wrote: > > I'm well aware of the analog mux and fully understand that if N channels are > being sampled, the maximum sample rate for each channel is reduced by a > factor of N. > > However, Mr. Hermans, who clearly knows what he is talking about, stated > "I've proven that /dev/mem + mmap() can work for reading 200ksps for 7 > channel simultaneously." > It's reasonable to assume that he would not have included the "7 channel > simultaneously" part unless it was somehow relevant to the performance he > observed. > > And, if the ADC is actually capable of doing conversions at a 1.6 MHz rate, > then it could sample all 8 channels at 200KSPS each, and maybe that's what > Mr. Hermans was observing. > > > On Monday, June 20, 2016 at 3:39:09 PM UTC-7, Wulf Man wrote: > um no the 7 channels go into a analog mux and you can only have one selected > input at a time. > > On 6/20/2016 3:35 PM, [email protected] <javascript:> wrote: >> 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: >> >> PRUs ( Programmable Real-time Units ) >> IIO ( industrial IO ) >> /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] <>> 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 >> <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 [email protected] <>. >> To view this discussion on the web visit >> <https://groups.google.com/d/msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com?utm_medium=email&utm_source=footer>https://groups.google.com/d/ >> >> <https://groups.google.com/d/>msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> -- >> 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 [email protected] <javascript:>. >> To view this discussion on the web visit >> <https://groups.google.com/d/msgid/beagleboard/2ff2e93c-ca65-46ec-a755-5c7f830da2b1%40googlegroups.com?utm_medium=email&utm_source=footer>https://groups.google.com/d/msgid/beagleboard/2ff2e93c-ca65-46ec-a755-5c7f830da2b1%40googlegroups.com >> >> <https://groups.google.com/d/msgid/beagleboard/2ff2e93c-ca65-46ec-a755-5c7f830da2b1%40googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/c2736249-fdeb-4673-80c6-4182ba741ca3%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/c2736249-fdeb-4673-80c6-4182ba741ca3%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/EA0B5B05-82AD-4AAF-9F53-33E096CD5DBF%40gmail.com. For more options, visit https://groups.google.com/d/optout.
