Currently the ADC driver is configured for 16x oversample, Open Delay = 152 cycles and Sample Delay = 1 cycles.
time in us for processing a single channel, calculated as follows: num cycles = open delay + (sample delay + conv time) * averaging num cycles: 152 + (1 + 13) * 16 = 376 clock frequency: 24MHz / 8 = 3MHz clock period: 1 / 3MHz = 333ns processing time: 376 * 333ns = 125us Regards, John > On Jun 20, 2016, at 5:06 PM, [email protected] wrote: > > > You're not understanding correctly . . . the ADC module is rated for > > 200ksps only. Not 1M, not 2M, 200ksps. > > So your "7 channel simultaneously" comment had nothing to do with the total > sample rate, but merely indicates that this 200 KSPS rate was achieved even > though some additional overhead (e.g. distributing the captured data into 7 > different buffers) was present. Is that correct? > > But in that case, I'm confused by john3909's link, wherein a TI spokesman > stated that the 200 kSPS value is for 3 MHz ADC clock, though the maximum ADC > clk frequency is 24 MHz. A further clarification was that the 24 MHz ADC clk > could only be achieved when the master oscillator is 24 MHz, but I confirmed > at > https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SCH.pdf?raw=true > that Y2 is indeed 24 MHz on production boards. > > On Monday, June 20, 2016 at 4:45:04 PM UTC-7, William Hermans 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/aa4a8a4e-56d1-4c14-ab99-42fa2ae3a07b%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/aa4a8a4e-56d1-4c14-ab99-42fa2ae3a07b%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/C2343BC6-2607-458E-B077-429247B7C0ED%40gmail.com. For more options, visit https://groups.google.com/d/optout.
