Well, again it depends on what you mean by realtime. To most developers, it means deterministic and since the AM335x ADC uses a sequencer to do the sampling, it is deterministic, and hence there is no difference between the PRU and ARM with DMA. This shouldn’t be a pissing match as to how fast you can sample, but rather focus on what the OP application was. In this case, since the PRU doesn’t have the required math functions, the PRU is only doing what the DMA is doing, moving samples from the FIFO to DDR memory. Hence, why waste the PRU on such a trivial function. Rather save it for something more useful.
One more thing, the IIO framework is capable of GSPS performance. Regards, John > On Jan 30, 2017, at 9:17 AM, TJF <[email protected]> wrote: > > > > Am Sonntag, 29. Januar 2017 21:50:31 UTC+1 schrieb john3909: > Hi TJF, > > The IIO ADC can sample at 800K samples per second [1]. > > This is not real-time sampling! When you transfer chunks of samples by DMA, > you add further and unsteady latency. The only way to sample real-time is > pulling samples one by one from the FiFo, and this is limited to 200 kSps (= > TI specification, on some boards I got up to 250 kSps). > > You cannot achieve that sampling rate with with PRU and have it do something > useful with those samples. > > Why do you know what I can achieve? I did experimental sampling at 1600 kSps > with the PRU, up to 295 samples (until the FiFo overflows). I assume that I > can get twice that number by using both FiFos (with more than one channel). > But this is not real-time, and it's not ready for daily use. > > BTW: At 200 kSps the PRU performes 1000 instructions between two samples. > Fairly enough to do something useful (as long as you don't use remoteproc > framework). > > Please do not confuse the users! You should mention that your solution is > experimental and you're looking for beta testers. > > I don’t see the purpose of having PRU read from /dev/iio:deviceX. > > Not today, but in future you may notice that the PRUSS are very good in data > processing and you'll need to feed them with data for that purpose. > > > @Fabián > > The external ADC is an option when you may need the TSC_ADC_SS for a touch > screen on the board. Otherwise it's an overkill, just protect the analog > input lines against under-/overvoltage. > > Regards > > -- > 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/5148db1c-9819-47fc-a3e3-2a0dc8e1d9f0%40googlegroups.com > > <https://groups.google.com/d/msgid/beagleboard/5148db1c-9819-47fc-a3e3-2a0dc8e1d9f0%40googlegroups.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/29D31B81-D659-4821-8C05-D878B9563120%40gmail.com. For more options, visit https://groups.google.com/d/optout.
