Re: RFC: Extension to External Interrupt API

Andy Ross

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
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. No?


* 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.