So, let me put it this way, and no that's not what John was trying to infer. *Any* time you cross over from user space to kernel space, and back. There is *always* a performance hit. Which technically is not 100% accurate, but is accurate for anything that matters . . .
On Thu, Mar 3, 2016 at 12:32 AM, Micka <mickamus...@gmail.com> wrote: > ?? John said that UIO drivers work in ms not in us range .....Looks like > that both of you agree on that ! > > Le jeu. 3 mars 2016 à 08:28, William Hermans <yyrk...@gmail.com> a écrit : > >> *Wrong again, UIO attempts to handle interrupts as events, but the >>> concept is slow (typically ms, not us)* >>> >> >> You're full of it if you're trying to purport that any interrupt in Linux >> works in the uS range. >> >> On Thu, Mar 3, 2016 at 12:26 AM, John Syne <john3...@gmail.com> wrote: >> >>> 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> 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> 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> 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> >>>>> 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> 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> >>>>>> 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> >>>>>> 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> >>>>>>> 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> 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 >>>>>>>> --- >>>>>>>> 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. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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. >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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. >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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. >>>>> >>>>> >>>>> >>>>> -- >>>>> 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. >>>>> >>>> >>>> >>>> -- >>>> 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. >>>> >>>> >>>> >>>> -- >>>> 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. >>>> >>> >>> >>> -- >>> 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. >>> >>> >>> -- >>> 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. >>> >> >> -- >> 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. >> > -- > 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. > -- 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.
