You make a very good point and we have no idea what the ADC front end bandwidth is. You would think that TI would add some provisions in the ADC setup that can be whatever you want as long as you do not exceed 200ksps. The 200ksps I believe comes from a setting where clock divider = 8, open delay =1, sample delay = 0 and oversample = 1x. The fact that they allow a 24MHz clock, and no warning is interesting. This was also discussed on E2E and no one from TI shut the idea down.
Anyway, if I can get the DMA to work, then we can test the concept ;-) If nothing else, at least we get a proper 200ksps ADC working on the ARM directly. No need for PRU. Regards, John > On 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/464B65A0-BD04-4154-AB4A-81AC3D8760CF%40gmail.com. For more options, visit https://groups.google.com/d/optout.
