> > *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 <[email protected]> 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 <[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]> 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]> 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]> 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]> 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]> >>> 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]> 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]> 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 [email protected]. >>>>> 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]. >>>>> 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]. >>> 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]. >>> 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]. >> 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]. >> 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]. > 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]. > 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]. For more options, visit https://groups.google.com/d/optout.
