> > *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.
