Re: RFC: Extension to External Interrupt API

Andy Ross

Vinayak Kariappa Chettimada wrote:
Welcome your valuable comments on the proposed extension to External
Interrupt API.
As has been mentioned in gerrit, there is worry about the portability
of a lot of this, which is a mostly 1:1 transcription of an ARM
feature as I understand it.

In particular irq_pending_set() seems to be pretty non-standard. Not
all architectures have a visible system-wide interrupt latch (x86
does, but only for external hardware interrupts), and AFAIK only ARM
allows it to be written (x86 can synchronously trigger an interrupt,
which isn't quite the same thing).

Do you have ideas on how this would be implemented for the other
architectures in Zephyr? If we can't have it as a general API, I'm
not really sure I see the value for having it in-tree. All of what
you're doing can (and, I gather, is) doable for specific hardware on a
per-app basis anyway, right?

Honestly it seems like what you have with the BLE work is tied very
closely to your hardware environment, and might need to be generalized
a bit. Can you explain what exactly you need from these features that
you can't get with Zephyr in other ways now? I mean, if your goal
with irq_pending_set() is to just have another interrupt handler
called after the current one completes, can't you implement that with
a function call at the bottom of the ISR? :)


Join to automatically receive all group messages.