Hi, Thanks to everyone who replied. William, yes I would use the PRU IEP timer on one of the PRUs to generate 100kHz timer for time stamping data. It gives me 2000 cycles theoretically to play with. If the main loop takes longer I could always poll multiple times for the interrupt. Every interrupt I will generate a sample SPI transfer clock via gpo to go to an ADC. Every 100kHz interrupt I will increment a counter in shared memory. When I clock the data in I will read the 100KHz timer value, and store both the data, the counter and the 100 KHz current timer value in DDR memory. I also have a one second precision timer input, I will store the counter value, and the current 100 KHz timer value in shared memory using the C28 pointer on the PRU. The one second precision timer will be used to track drift in the clock over time. The timer/sample can run for months. I will look at the /dev/mem mmap option.
I am also looking at the PRU Cape example. Struggling to build because of a linker issue but I'll plod on. It doesn't use prussDrv it seems. It has memory mapped registers it use to control the PRU config. It uses the starterware libraries, which are also old. Chris, yes uio_pruss/prussdrv examples seem to give me better control than Remote Proc/RpMsg, I am thinking of trying to rebuild the kernel with the pruss_io kernel objects instead, then use examples like yours. It seems there are lots. I just can't see many examples using RemoteProc/RpMsg. Greg, yes I am concerned about RpMsg being fast enough to transfer the data. I think getting the C28 pointer on the PRU to spit the data into DDR memory would be faster. Then getting a user space program to mmap() /dev/mem to read the data. I want to generate an R31 host interrupt to tell the Arm data is in DDR memory but I can't see how I can see this interrupt in user space. If I used the older uiopruss/prussdrv there are plenty of examples, I can't see where any Remote Proc/rp_msg examples are. I would probably prefer going to uio_pruss but I am concerned that it will not be supported as the newer images on Beaglebone Black use rp_msg. Confused.... I need to work on something else for a few days but I will track my progress, or lack of it here incase it is useful for other people in the future. Best Regards, Paul On Wednesday, September 14, 2016 at 6:56:52 AM UTC+1, William Hermans wrote: > > 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] > <javascript:>> 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] >> <javascript:>> 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] >>> <javascript:>> 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] <javascript:>. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/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/1878e3b7-86bb-4631-879b-148cb77c84d9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
