Wrong again, UIO attempts to handle interrupts as events, but the concept is slow (typically ms, not us)
Regards, John > On Mar 2, 2016, at 11:22 PM, William Hermans <yyrk...@gmail.com> wrote: > > 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 > Now. not only are you wrong, but you're making stuff up. You can handle > interrupts from userspace, as much as iio can. But it's not my job to tell > you how. I will mention that perhaps you should look into "userspace > drivers". As far as whats faster ? who f***ing cares. mmap() is a lot faster > than the ADCs . . . and still not the point. > > The point is, if you need fast ADC you should be using the PRU, and then you > may want to seriously consider using an external module. That is, for > anything serious. It does not matter how much CPU mmap() or iio uses. As any > % can preempt other code that needs to run *now* thus creating potential non > determinism. > > > On Thu, Mar 3, 2016 at 12:12 AM, John Syne <john3...@gmail.com > <mailto:john3...@gmail.com>> wrote: > 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 <yyrk...@gmail.com >> <mailto:yyrk...@gmail.com>> 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 <john3...@gmail.com >> <mailto:john3...@gmail.com>> 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 <yyrk...@gmail.com >>> <mailto:yyrk...@gmail.com>> 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 <john3...@gmail.com >>> <mailto:john3...@gmail.com>> 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 <yyrk...@gmail.com >>>> <mailto:yyrk...@gmail.com>> 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 <yyrk...@gmail.com >>>> <mailto:yyrk...@gmail.com>> 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 <john3...@gmail.com >>>> <mailto:john3...@gmail.com>> 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 <jeli.freih...@gmail.com >>>>> <mailto:jeli.freih...@gmail.com>> 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 beagleboard+unsubscr...@googlegroups.com >>>>> <mailto:beagleboard+unsubscr...@googlegroups.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 beagleboard+unsubscr...@googlegroups.com >>>> <mailto:beagleboard+unsubscr...@googlegroups.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 beagleboard+unsubscr...@googlegroups.com >>>> <mailto:beagleboard+unsubscr...@googlegroups.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 beagleboard+unsubscr...@googlegroups.com >>> <mailto:beagleboard+unsubscr...@googlegroups.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 beagleboard+unsubscr...@googlegroups.com >>> <mailto:beagleboard+unsubscr...@googlegroups.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 beagleboard+unsubscr...@googlegroups.com >> <mailto:beagleboard+unsubscr...@googlegroups.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 beagleboard+unsubscr...@googlegroups.com >> <mailto:beagleboard+unsubscr...@googlegroups.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 beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.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 beagleboard+unsubscr...@googlegroups.com > <mailto:beagleboard+unsubscr...@googlegroups.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 --- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
