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] > <javascript:>> 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 > --- > 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/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/aeaf9852-fb4c-4fd1-9594-8aad0ad5fd3c%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] > <mailto:[email protected]>. > To view this discussion on the web visit > 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?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/9026f5a1-bc0b-ac21-ba00-412211753ca5%40gmail.com. For more options, visit https://groups.google.com/d/optout.
