Re: RFC: Extension to External Interrupt API

Benjamin Walsh <benjamin.walsh@...>

On Fri, Sep 16, 2016 at 12:20:56PM -0400, Benjamin Walsh wrote:
On Fri, Sep 16, 2016 at 09:06:13AM -0700, Andy Ross wrote:
Benjamin Walsh wrote:
IIUC, he wants to queue work in another interrupt of the same priority,
serve the other interrupts of same priority that are already pending,
and then only execute the work he's queued. Kinda some sort of
cooperative yielding, but at interrupt level. This is exactly how fibers
(cooperative threads) are scheduled in Zephyr BTW. What he's not getting
if was to queue work to fibers instead, is that when his delayed work
would run would be depending on what work is already being done in a
fiber when he handles his interrupt and what other interrupts of lower
priority might be pending.
Does that work? Are pended ARM interrupts really "queued" like that?
If you have multiple pending interrupts of the same priority I'd have
to believe the order of delivery would be arbitrary and
hardware-dependent (i.e. whatever fixed precedence the hardware
designers picked in a mux somewhere).

If that works, then I agree this sounds cool. But my suspicion is
IIRC, you can have sub-priorities on Cortex-M.


However, IIRC as well, Zephyr programs the interrupt priorities with 0
subgroups, so that would not work. We could have a config option that
asks for the number of subgroups though, not hard to add.

Isn't x86 able to do that as well, in the IDT in each 16-vector block,
based on the vector position within the block ?
Nevermind, INTx is a synchronous trap, doesn't work.

Join to automatically receive all group messages.