Well, I think that is still to be determined if the ADC can sample higher than 200ksps and that is why I’m adding DMA to this driver. But in any case, why not use a higher speed ADC connected via SPI or McASP? You can purchase boards that sample at a higher rate and connect those to the BBB.
Regards, John > On Jun 20, 2016, at 5:27 PM, [email protected] wrote: > > 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 > <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: >> >> 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 >> <http://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] <>. >> 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] <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 > <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/0e065a8d-18aa-4365-9764-5ca22c60b7c1%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/0e065a8d-18aa-4365-9764-5ca22c60b7c1%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/62B95A31-A261-431E-8319-61C504A49848%40gmail.com. For more options, visit https://groups.google.com/d/optout.
