When you're writing directly to memory addresses ( registers ), you can't tell me what is, and what isn't. *This* is exactly what the PRU does when accessing peripherals modules. But, you'd be surprised what you can accomplish from userland when you pay close attention to what you should *not* do in order to remain performant.
Anyway, reading from a memory location, and putting that value into another location does not really take a lot of computational power, and then if you're using an rt kernel. The scheduler is going to run in a tighter loop, offering lower latency. But again, you have to be smart how you go about things. Printing every, or even *any* samples to stdout will slow thigns down considerably. Also, if you use a lot of API calls that have to go back and forth to / from the kernel . . . that's going ot slow things down considerably also. etc . . . On Mon, Jun 20, 2016 at 6:14 PM, <[email protected]> wrote: > The ADC is a SAR ADC. Overclocking it is likely to have side effects on the > analog end of things which will reduce accuracy. > > Ignoring that it is a very bad idea to keep doing things in userland: > > On Monday, June 20, 2016 18:06:09 John Syne wrote: > > That is a totally different issue. You were reading the same sample over > and > > over again as opposed to increasing the sample rate by changing the clock > > divider, open delay, sample delay, etc. In any case, at 200ksps, each > > sample occurs every 5uS. How is a user space app going to process samples > > at 5uS? Even when you poll for the EOC with 8 channels configured, you > > still have to service the samples every 40uS and that is still not > possible > > from a userspace app. > > You could use the FIFOs to reduce the read timing accuracy but you still > risk > getting scheduled away for (comparatively) long period of time. This > probally > means you will also need to check the status for FIFO overflows and.... > > > > > My guess is the app you had was reading the same sample at a higher rate > > than 1.5msps and then the scheduler switched out your app to service > > background tasks and then return a while later and then your app would > read > > the same sample again. The average sample rate would then result in > > 1.5msps. Not a good idea. You should enable the channel ID to see when > you > > miss samples. > > It is not just missing sames but what is the overall accuracy of the data > when > the ADC module is overclocked? Does it appear anywhere near the 12bits of > accuracy? > > > > Regards, > > John > > > > > On Jun 20, 2016, at 5:49 PM, William Hermans <[email protected]> > wrote: > > > > > > So going back to what I said earlier. When using /dev/mem + mmap() > yes, I > > > was (actually ) reading more than> > > > 200ksps from 7 channels simultaneously. For a total of somewhere > around > > > 1.5Msps> > > > ***********BUT*********** > > > > > > Only 1 sample in ~8-9 per second was valid. So what I proved is > possible > > > is completely different from what is accurate / possible for the > AM335x's > > > on die ADC module. > > -- > Hunyue Yau > http://www.hy-research.com/ > > -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/33331620.iAXeZpr9Qk%40acer0. > 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqLfF2SF8F5ydYtQj24x8%2BNcOvMHopRDPyDStqarYv8Dg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
