Thanks for the link. Given the recent update to the data sheet, it seems pretty likely that the 200 kSPS total sample rate limit is correct, even though that conflicts with both the (older) TRM and the comments in 2014 by Biser Gatchev-XID <http://e2e.ti.com/members/1607373>. So, it appears to be a waste of time to attempt 800 kSPS+.
Sorry to have bothered you all, Stewart On Monday, June 20, 2016 at 4:55:03 PM UTC-7, William Hermans wrote: > > 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] > <javascript:>> 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] <javascript:>> >> 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] <javascript:>. >>> 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/0e065a8d-18aa-4365-9764-5ca22c60b7c1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
