On 7/30/2016 2:47 PM, William Hermans wrote: > > DMA in my mind almost seems the way to go. But there are several key points > that > I'd need to understand to make that determination.But at the moment I'm > imagining all kinds of cool possibilities. . . too bad I do not have the time > to > invest into looking into this right now.
DMA is not really necessary, as the PRU can read/write to the ARM system DRAM and the ARM can read/write to the PRU memories. There are some ways DMA could improve performance of a high-performance application using both the ARM and the PRU heavily, but it's not a clear win in all cases. However, any kernel-level physical memory access for talking to the PRU is going to have a lot in common with doing DMA. You need to map physical addresses into logical memory space, issue fence instruction to guarantee memory coherency, etc. Basically, the PRU can be considered a "custom" DMA controller, in that it is something other than the application processor that is accessing and changing main memory contents. The usage semantics for talking to the PRU in kernel space are very similar to using DMA. Just 's/DMA/PRU/g' and you won't go too far wrong! ;-) -- Charles Steinkuehler [email protected] -- 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/15e2ce5a-95e9-002e-914f-6cbb3af22e58%40steinkuehler.net. For more options, visit https://groups.google.com/d/optout.
