The latency in the RT kernel is only relevant for interrupts (preemption). The scheduler will still swap out user space apps to service background tasks and that is the same as the regular kernel. In any case, the ADC uses a sequencer to do the samples and those samples get stored in the fifo, so you have to wait until the fifo count is greater than a certain number and then read until the fifo is empty and poll again for samples. From what I recall, you were just reading the samples from the IIO driver. I don’t believe you had code to setup the sequencer, or maybe I’m wrong?
Regards, John > On Jun 20, 2016, at 6:32 PM, William Hermans <yyrk...@gmail.com> wrote: > > 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, <ybeag...@rehut.com > <mailto:ybeag...@rehut.com>> 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 <yyrk...@gmail.com > > > <mailto:yyrk...@gmail.com>> 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/ <http://www.hy-research.com/> > > -- > 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%2bunsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/33331620.iAXeZpr9Qk%40acer0 > <https://groups.google.com/d/msgid/beagleboard/33331620.iAXeZpr9Qk%40acer0>. > 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>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CALHSORqLfF2SF8F5ydYtQj24x8%2BNcOvMHopRDPyDStqarYv8Dg%40mail.gmail.com > > <https://groups.google.com/d/msgid/beagleboard/CALHSORqLfF2SF8F5ydYtQj24x8%2BNcOvMHopRDPyDStqarYv8Dg%40mail.gmail.com?utm_medium=email&utm_source=footer>. > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/71213655-9793-4728-894B-34BB74239A0D%40gmail.com. For more options, visit https://groups.google.com/d/optout.
