BY the way, when I say read from the ADC buffer. I do not mean that piece of garbage /dev/iio:device0. I mean the ADC hardware buffer. FIFO0DATA described on page 1095 of the TRM.
On Mon, Jun 20, 2016 at 7:27 PM, William Hermans <yyrk...@gmail.com> wrote: > 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 <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> 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> >>> 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 beagleboard+unsubscr...@googlegroups.com. >>> 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqX3Ex8RdyKJvVqK94ZmAdHa-wsg8-5Mzi%2BxdSpBh75uA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
