I never shared my /dev/mem + mmap() code with the group / publicly. For what should be obvious reasons. I fact I do not think I shared it with anyone. My reasoning is that if someone can figure out how to do this on their own, then they probably earned the right, and with that comes knowledge and responsibility.
As far as interrupts and rt. That does not matter. Interrupts happen all the time, and the more you have, for whatever reason, the slower your application will be. Regardless if your app generated that interrupt or not. So if i understood what someone was talking about concerning remoteproc not long ago. Moving interrupts to userspace . . . would be a very very bad idea. You'd get all kind of context switching between processes / interrupts fighting for time. Then jumping into and out of kernel space, potentially copying data . . . yeah, very very bad idea. On Mon, Jun 20, 2016 at 6:43 PM, John Syne <[email protected]> wrote: > 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 <[email protected]> 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, <[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 > <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. > > > -- > 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/71213655-9793-4728-894B-34BB74239A0D%40gmail.com > <https://groups.google.com/d/msgid/beagleboard/71213655-9793-4728-894B-34BB74239A0D%40gmail.com?utm_medium=email&utm_source=footer> > . > > 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/CALHSORqJpA8gwGGUQC-tgED3LQ%3Dyj2%3DpQXgoOLs0XV2N4OPuZw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
