First, that isn’t going to work because the ADC uses a scan loop and unless you 
can respond to interrupts, you cannot determine when the ADC conversion has 
completed. There is a much simpler way to do this. Simply use the IIO driver 
and then read /dev/iio:device0

For example, do:

dd if=/dev/iio:device0 of=~/test

Enable the iio buffer and your file will receive samples at the configured 
speed.

Regards,
John




> On Mar 2, 2016, at 2:27 PM, William Hermans <[email protected]> wrote:
> 
> errr oops, I sent too soon. mmap() is fast, and can actually read from the 
> ADC faster than the ADC can update values. But, it's using the main processor 
> to do so, and if you need to do more than just read the ADC. Additional 
> processes would have to compete for processor time. So, if one does want / 
> need to read at maximum speed, it might be wise to offload the main 
> processor, by using a PRU.
> 
> It would not matter if this were done in userspace, or kernel space. It'll 
> definitely put a load strain on the ARM processor.
> 
> On Wed, Mar 2, 2016 at 3:19 PM, William Hermans <[email protected] 
> <mailto:[email protected]>> wrote:
> You realize that you can read the ADC from Linux at full speed also? No need 
> to use the PRU. 
> Regards,
> John
> I do, because I've proven just that :) mmap() is dahmed fast . . .
> 
> 
> On Wed, Mar 2, 2016 at 2:32 PM, John Syne <[email protected] 
> <mailto:[email protected]>> wrote:
> You realize that you can read the ADC from Linux at full speed also? No need 
> to use the PRU. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Mar 2, 2016, at 12:43 PM, TJF <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> Hello PatM001!
>> 
>> There's libpruio <http://beagleboard.org/project/libpruio/>, which provides 
>> ADC sampling at full speed (200 kHz). You'll get rid of the exeptions (and 
>> the miss readings of the sysfs driver in case of sampling multiple channels).
>> 
>> The downside: no C# binding yet. It's written in FreeBASIC/PASM and gets 
>> shipped with a C header. You may try SWIG <http://www.swig.org/> on the C 
>> header in order to generate a binding for your prefered language.
>> 
>> If you try, please share your results, or at least report.
>> 
>> BR
>> 
>> -- 
>> 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]>.
>> 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]>.
> 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]>.
> 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].
For more options, visit https://groups.google.com/d/optout.

Reply via email to