I've had a hard time getting any definitive responses to questions on the subject of memory access & latency. It is true that the PRU cores have faster access to DRAM that is part of the PRU-ICSS (through the 32-bit interconnect SCR) - though not single-cycle - than to system DDR. However, the ARM core accesses DDR through L3 fabric, but the PRU-ICSS through L4FAST, so I'm thinking that it can access DDR faster than PRU-ICSS memory.
I've also asked about differences in latency/throughput/contention comparing PRU-ICSS 12KB shared RAM v the 8KB data RAM. No response. Since both 8K data RAM is accessible to both PRU cores, I'm not sure what the benefit of the 12KB shared RAM is (thought I imagine there is, I just can't figure it out). Lastly - and even more importantly - is total agreement that you have to be careful about accessing any memory correctly. I have posted several times asking about the am335x_pru_package examples (using UIO). In at least one (https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt/PRU_PRUtoPRU_Interrupt.c), there is hardcoded use of the first 8 bytes of physical memory at 0x8000_0000. I don't see how that can be OK. It may be that I don't know some secrets of Linux internals, but from a theoretical perspective, I just don't know how one can make the assumption that any part of main memory is not in use by another process unless it is guaranteed by the kernel. On Wednesday, March 8, 2017 at 4:14:56 PM UTC-8, William Hermans wrote: > > > > On Wed, Mar 8, 2017 at 4:34 PM, ags <alfred.g...@gmail.com <javascript:>> > wrote: > >> Correct - to preserve deterministic execution, the PRU cannot be >> asynchronously interrupted. Polling (of some form) is required. >> >> Back to the OP, there is a way to register a (non-async) interrupt with >> the PRU. One can force a system interrupt (any one of the 64 that the PRUSS >> recognizes) by setting a bit in the Interrupt Status Register. From >> userspace it looks just like writing to the PRU DRAM since it's just >> writing a value to mmap()'d physical address. The advantage over what's >> been discussed here is that depending on how it's set up, it could be >> faster than polling from DRAM. I will have to implement to provide actual >> measurements. >> > > So I remember asking Charles, some time ago, if it would be more efficient > writting to DRAM, or to one of the shared memory area for the PRU. From the > ARM side of things. I think perhaps in this case, writing to one of the > PRU's memory area's might be more efficient. In this one case. My reasoning > here is that through userspace, one would have to write out to memory > through /dev/mem/ anyhow. So why not make that to a memory location where > the PRU has single cycle read speeds ? One *would* have to take extra care > to make sure this memory location is correct, but no more so than writing > into DRAM. . . . > > Something to think about anyhow. > -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/17e13ff7-4418-4058-9433-f30726d3d922%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
