Hi, Thanks for everyone who has got in touch. I have a few ideas now. I'll give /dev/mem and mmap() a go since I know the absolute addresses of the memories I want to read write from, thanks William.
Greg, yes I am worried about how fast I can get RpMsg to work to spit out the ADC data, or to pass samples in to transmit. It looks a lot of overhead. For more info on what I am doing, or trying to do atleast. If I timestamp the incoming data using the IEP timer at 1MHz, yes so I will have 200 instruction cycles (theoretically) to play with between samples. I want a free running counter (to use as my data timestamp) stored in shared memory for access for the ARM and the other PRU. I have another precision signal a 1 pulse per minute to track drift in the internal clock. This will come in as a GPIO rising pulse. I will timestamp it when it is seen and this will allow me to measure samples inbetween my 1 sec precision clock. Every 10 polls will give me the sample clock (really the SPI rate from the chip). I will feed this out via GPO to an ADC chip and use it as an SPI clock to clock the data in over SPI. Then use the C28 pointer in the PRU to write the data into DDR together with the timestamp of the received data , or shared memory (not sure where is best yet for me). Trigger a Host interrupt on R31 to warn the ARM there is new data to process. The RpMsg will be used for configuration, turning the read off/on and halting the PRU. Chris , yes looking at what I want to do uio_pruss (Prussdrv) seems to give me that flexibility, however it looks like it is being dropped in favour of RpMsg. Also I am looking at building, then modifying the PRU Cape Demo example. I have some linker errors at the moment I am trying to fix, I have probably missed some detail in the build instructions below. http://processors.wiki.ti.com/index.php/PRU_Cape_Getting_Started_Guide http://processors.wiki.ti.com/index.php/PRU_Cape:_Building_Demos They don't seem to use prussDrv ( I dont have anything against PrussDrv, it seems that TI are moving away from it to RemoteProc/RPMsg). The PRU Cape example seems to be mostly deferenced pointers to PRU registers and memory so I was also going to give that a try. I need to work on something else for a few days. However i'll keep the topic going and record my progress (or otherwise) incase anyone else will find it useful 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/c6626bfc-d17e-44b2-8254-2130af3873a1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
