On Wed, Mar 8, 2017 at 4:34 PM, ags <[email protected]> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqEQkrRG5GigfuRnGALdjUzjyey2U%3DQA4FzBQa7H7Xxdw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
