I seemed to have lost a post here that I made. *Somehow* . . . Anyway, I never shared my /dev/mem + mmap() code with anyone, and I will never post it on this group. So no one here would know what I've done in code concerning that. My reason is simple. In order to use code of that nature, you need to earn the right to do so, and hopefully have an understanding of could happen if you're not careful.
Most of that code is peripheral setup, and the rest is simply reading from the ADC buffer, and then printf() to screen. However, in order to get the best performance you never let that data get put on screen by piping the output of the executable to a file. *That* increases performance drastically, and is a happy medium for not having to write a bunch of read() / write() / open() calls for a simple test. Perfect ? Who cares, I never did. I proved a point to myself, and that is all that matters to me. I proved to myself that /dev/mem/ + mmap() works fine, and if you have an application that does not need to spend a lot of CPU time doing things. Then it would work fine. As it is. Reading from the ADC multiple channels as fast as you can. Should probably be done using the PRUs. Simply so you can use that CPU time saved to do other things. Perhaps even display that data to the outside world from a web server. Interrupts. They happen, and frequently. So it does not matter if your app generated interrupts or not. Your app will constantly be interrupted by them. So if you're using an rt kernel, "return latency" will be less. Meaning, your app should be able to get things done faster. Which brings me to another point. I hope I was misunderstanding someone earlier this week talking about remoteproc and bringing interrupts to userspace. *That* would be a terrible idea, and would generate all kinds of context switching between userland, kernel space, processes, interrupts, copying data to / from kernel space. . . yeah it would be a bloody mess. But you know what. That will just give me another reason to avoid what I'm already avoiding now. So, for me, no big deal. I guess. On Mon, 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/CALHSORpQeiad1uLBq-U_4LiW7XUfaciE30dT7-92c2_1Z-i_Lw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
