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. On Wednesday, March 8, 2017 at 2:14:15 PM UTC-8, Justin Pearson wrote: > > According to this 2015 video from the Embedded Linux Conference, the PRU > does not support asynchronous interrupts: > > https://youtu.be/plCYsbmMbmY?t=22m6s > > I think there is some sort of PRU interrupt queue, but it does not > interrupt the PRU's execution. Your PRU code must explicitly monitor the > PRU interrupt queue to check for an interrupt. > > Alternatively, I've used a method for ARM/PRU coordination that is similar > to what William Hermans described: when the ARM CPU wants to trigger > something on the PRU, it writes a 1 to the bottom byte of the PRU data RAM. > The PRU continuously monitors this bottom byte to watch for a change. > > -Justin > > > On Wednesday, March 8, 2017 at 8:18:48 AM UTC-8, William Hermans wrote: >> >> >> >> On Wed, Mar 8, 2017 at 9:04 AM, William Hermans <[email protected]> wrote: >> >>> For the purpose of this discussion with ags, I do not think the actual >>> definition of what an interrupt is, is quite so important, as much as how >>> to achieve an end goal. On a single threaded "system", I also do not think >>> asynchronous is really ever a factor. But I usually do tend to view >>> interrupts as prioritized, and preemptive. >>> >> >> Additionally, what I proposed, should not interfere with system >> interrupts much, if at all. But should complete the task as fast as the >> system would allow, and is blocking in nature. >> >> One thing I did not mention however, is that even though my idea is >> blocking in nature, you can give processor back to the system by using >> sleep(), or usleep(). Instead of continuously polling to the point that >> you're keeping the processor so busy, it has little time to do anything >> else. >> >> In my use case, I think I used usleep() with a value of 10,000, which >> seemed responsive enough for my purpose, and only used 1-3% processor >> time. >> >> -- 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/ed8bd90f-9265-4002-b9a7-fcde916b2e50%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
