Re: RFC: Extension to External Interrupt API

Maureen Helm

-----Original Message-----
From: Benjamin Walsh [mailto:benjamin.walsh(a)]
Sent: Friday, September 16, 2016 11:21 AM
To: Andy Ross <andrew.j.ross(a)>
Cc: Vinayak Kariappa Chettimada
devel(a); Benjamin Walsh
Subject: [devel] Re: Re: RFC: Extension to External Interrupt API

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.
Agreed. I think subgroups could make that work, but I don't think you have many options when there are only a few priority bits implemented. On the nrf52 you've only got 3 bits implemented, 2 priorities are reserved for the kernel, so I think you can only use one bit for subpriority.

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 ?

that the only promise you get with this irq_pend_set() implementation
is that the IRQ will run at its fixed priority sometime after your
call completes and before ISRs of lower priority or user code get to
run. And if *that's* true then you should be able to just test for
the pending state of those other known IRQs* at the end of your
function and call the one of your choice to get the same behavior.


* Not ones higher than the current handler, which by definition aren't
pending. And not ones lower than the target which wouldn't run
anyway. That's going to be a small, tractable list. And
importantly one accessible to application code in Zephyr without
exposing ARM's writable interrupt pending bits.

Join to automatically receive all group messages.