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] > <javascript:>> 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/ef5c9a37-311a-4c5b-8d7e-c3849535650b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
