Ah, I thought you were talking about this solutions: http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/ <http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/>
Otherwise, you would have to replicate much of the ADC driver in userspace and then loop, waiting for FIFO0COUNT>0, read samples from FIFO1DATA until FIFOCOUNT-0 and doing this in a way that doesn’t hog the CPU but still be fast enough to overflow the FIFO. At 1.5msps, you would have to do this in less than 21uS assuming a average FIFO Count of 32. I just don’t see ti, but maybe you have a trick that I don’t know about ;-) Did you enable StepID? This way you can see if you missed any samples. Regards, John > On Jun 20, 2016, at 7:49 PM, William Hermans <[email protected]> wrote: > > 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[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] > <mailto:[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] > > > <mailto:[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/ <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 [email protected] > <mailto:beagleboard%[email protected]>. > 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 [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/CALHSORqX3Ex8RdyKJvVqK94ZmAdHa-wsg8-5Mzi%2BxdSpBh75uA%40mail.gmail.com > > <https://groups.google.com/d/msgid/beagleboard/CALHSORqX3Ex8RdyKJvVqK94ZmAdHa-wsg8-5Mzi%2BxdSpBh75uA%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/A5B3C151-A278-47EC-875A-46D72E89AA41%40gmail.com. For more options, visit https://groups.google.com/d/optout.
