http://www.ti.com/lit/ds/sprs717j/sprs717j.pdf
Page 3: – 12-Bit Successive Approximation Register (SAR) ADC • 200K Samples per Second • Input can be Selected from any of the Eight Analog *Inputs Multiplexed* *Through an 8:1 Analog Switch* • Can be Configured to Operate as a 4-Wire, 5-Wire, or 8-Wire Resistive Touch Screen Controller (TSC) Interface On Mon, Jun 20, 2016 at 4:44 PM, William Hermans <[email protected]> wrote: > 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. >> > > You're not understanding correctly . . . the ADC module is rated for > 200ksps only. Not 1M, not 2M, 200ksps. > > On Mon, 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] 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: >>>> >>>> >>>> 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]> 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]. >>>>> 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/ >>>>> msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c% >>>>> 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]. >>> 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 >>> . >>> 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/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. >> > > -- 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/CALHSORo5eC0H_5E0vJUEyi%2B4LB9O_4ZFGLPDHt5kvERAC6ZbWQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
