> > The ADC block is rated for 200Ksps max. The easiest thing to do is a quick > char device driver that configure the ADC with the right settling times and > have the DMA engine gather the data. Once you have that all you need to do > is > cat /dev/foobar > file. >
No point. IIO is already included, and used with the latest debian images. On Mon, Jun 20, 2016 at 3:07 PM, William Hermans <[email protected]> wrote: > http://lmgtfy.com/?q=AM335c+ADC+module -> > http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide#Introduction > > An analog-to-digital converter (abbreviated ADC) is a device that uses >> sampling to convert a continuous quantity to a discrete time representation >> in digital form. >> >> The TSC_ADC_SS (Touchscreen_ADC_subsystem) is an 8 channel general >> purpose ADC, with optional support for interleaving Touch Screen >> conversions. The TSC_ADC_SS can be used and configured in one of the >> following application options: >> >> - 8 general purpose ADC channels >> - 4 wire TS, with 4 general purpose ADC channels >> - 5 wire TS, with 3 general purpose ADC channels >> - 8 wire TS >> >> *ADC used is 12 bit SAR ADC with a sample rate of 200 KSPS (Kilo Samples >> Per Second).* The ADC samples the analog signal when "start of >> conversion" signal is high and continues sampling 1 clock cycle after the >> falling edge. It captures the signal at the end of sampling period and >> starts conversion. It uses 12 clock cycles to digitize the sampled input; >> then an "end of conversion" signal is enabled high indicating that the >> digital data ADCOUT<11:0> is ready for SW to consume. A new conversion >> cycle can be initiated after the previous data is read. Please note that >> the ADC output is positive binary weighted data. >> > > > > > On Mon, Jun 20, 2016 at 2:33 PM, <[email protected]> wrote: > >> > the best woud be the PRU because you can store the data in the share >> memory. >> >> Do you mean the 12KB data memory? As I understand it, it's only shared >> between PRUs, not directly with the CPU. Moving data from there to the CPU >> would require DMA, as 'programmed' access would not keep up with 1.6 MSPS. >> Is that right? But if I understand correctly, the ADC can be configured to >> send its results (through an intermediate FIFO) to DMA, so the PRU would >> just be a needless layer of complexity. >> >> Of course, If I could find free or inexpensive software that needed >> little or no modification to do the job, I wouldn't mind if it happened to >> use the PRU :) >> >> Thanks. >> >> On Monday, June 20, 2016 at 12:53:28 PM UTC-7, Micka wrote: >>> >>> the best woud be the PRU because you can store the data in the share >>> memory. That is the fastest way. >>> >>> you can stop the acquisition whenever you want or let it go back at the >>> beginning of your memory and go on. >>> >>> >>> Le lun. 20 juin 2016 à 21:29, <[email protected]> a écrit : >>> >>>> 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/c5cae6bf-c8e0-45c4-ab5b-6bc236766d09%40googlegroups.com >>>> <https://groups.google.com/d/msgid/beagleboard/c5cae6bf-c8e0-45c4-ab5b-6bc236766d09%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/bd593480-ae6b-453b-addd-0b9cb07036d6%40googlegroups.com >> <https://groups.google.com/d/msgid/beagleboard/bd593480-ae6b-453b-addd-0b9cb07036d6%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/CALHSORopvnRt772piWz404p4o%3DsbnRpzVfXdtrfX%2BD38X4_yUw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
