mmap isn't faster than a kernel driver (kernel code has priority over user space code) and you still cannot handle interrupts from user space. Anyway, you won’t find any drivers in the kernel implemented your way (/dev/mem, mmap). However, mmap is used in drivers to eliminate mem to mem copy when transferring data between user space and kernel space.
Regards, John > On Mar 2, 2016, at 11:04 PM, William Hermans <[email protected]> wrote: > > From what I remember, the solution you proposed was using 90% of the CPU. > > 93% CPU load when using one shot mode, and continuously opening / closing a > file descriptor to the ADC module. There is no such load when using mmap(), > as mmap() is light years faster. > > > On Wed, Mar 2, 2016 at 11:52 PM, John Syne <[email protected] > <mailto:[email protected]>> wrote: > When the ADC is in continuous mode, you shouldn't read the data until it has > been updated. Simply reading the data over and over again to get the same > value that hasn’t been updated is just dumb. The interrupt tells you when the > conversion has been updated and then you read it. The point I was making > originally was that there was no need to use PRU to sample the ADC at full > speed. You can do the same from the IIO driver. Running at full speed > consumes less than 10% of the CPU. If the IIO driver was updated to use DMA, > then there would be no CPU utilization. From what I remember, the solution > you proposed was using 90% of the CPU. > > Regards, > John > > > > >> On Mar 2, 2016, at 10:12 PM, William Hermans <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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 >> >> FIrst of all, it *will* work. I've done it, and it works. Second of all, in >> continuous mode, values are put out as 32bit values. Only the first 12bits >> is the actual ADC value. The next 4 bits is the channel ID( 0 - 7 ), and the >> last 16bits reserved / unused. Thirdly, using interrupts in fast moving code >> is about as bad of an idea as using try / catch blocks in fast moving code. >> It adds code latency, and also introduces non deterministic behavior. This >> is why iio does not work fast for short data sets. >> >> >> dd if=/dev/iio:device0 of=~/test >> >> Maybe, but it's a terrible idea if the target is flash media. The ADC's can, >> and will use up a lot of storage space, very quickly. Just using 7 channel >> in one shot mode, one channel after the next. In a loop of 300k iterations. >> I was using up ~3MB/s disk space. Maxed out, and all channel used. The ADC's >> should use up ~9MB/s or more. >> >> >> On Wed, Mar 2, 2016 at 4:06 PM, John Syne <[email protected] >> <mailto:[email protected]>> wrote: >> 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] >>> <mailto:[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 >> <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 > <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.
