Also, the on die ADC is capable of 200Ksps. So the am335x on die ADC should be able to handle your samples needed easily. As for your 1 us latency expectation . . . a single PRU instruction cycle is 5ns. So we're talking what ? 200 total cycles to play with ? It could be tight getting a sample form the ADC into memory, depending.
On Tue, Sep 13, 2016 at 10:45 PM, William Hermans <[email protected]> wrote: > Perhaps this will also help ? > > http://processors.wiki.ti.com/index.php/AM335x_PRU_Read_Latencies > > On Tue, Sep 13, 2016 at 10:35 PM, William Hermans <[email protected]> > wrote: > >> From userland, and using /dev/mem + mmap() it is possible to get >> ~3MB/second worth of samples from the on die am335x processors ADC. >> Granted, many of these samples are redundant, but I wrote a C application >> to do this, *just* to see how much such an application could handle. >> >> Theoretically, the PRU's should be capable of much more, since the code >> to read from an ADC would not be loading the am335x processor. I do not >> recall how much this application I experimented with was loading down the >> am335x processor under Linux, but I am wanting to say it was pretty much >> maxed out. >> >> On Tue, Sep 13, 2016 at 3:27 PM, Greg <[email protected]> wrote: >> >>> Hi Paul- >>>> >>> >>> I'm using the RPMsg character device to transfer 16 bit data PRU to ARM >>> at a rate of 8ksps. This is a low rate compared to your requirement, >>> however, I am not seeing significant ARM processor loading at this rate. I >>> don't know the practical upper limit of RPMsg as deployed in the PRU >>> examples, but perhaps 100ksps is not out of the question. >>> >>> My impression is that the kernel programmers have a very good tool box >>> for efficient handling of data, and I assume the RPMsg took advantage of >>> these tools. >>> >>> My present scheme is to use one character device as a data stream, and >>> another for PRU control functions. I'm not deep into it yet, so I can't >>> comment on the practicality of this scheme with the remoteproc/RPMsg >>> framework. >>> >>> Regards, >>> Greg >>> >>> -- >>> 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/ms >>> gid/beagleboard/298bd9f1-bd28-4d6c-97b3-05b80925662f%40googlegroups.com >>> <https://groups.google.com/d/msgid/beagleboard/298bd9f1-bd28-4d6c-97b3-05b80925662f%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> 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/CALHSORrUhtmxWk2d5WjBo45%2Bc2TXwRcT%2Bdk%3Ds5qc856jaE0tRA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
