Re: RFC: Extension to External Interrupt API


Chettimada, Vinayak Kariappa
 

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?
Yes, for now from the Zephyr source, there is so much duplication, I can do the same thing :-). for example:
drivers/interrupt_controller/exti_stm32.c
drivers/interrupt_controller/arcv2_irq_unit.c
drivers/interrupt_controller/ioapic_intr.c
drivers/interrupt_controller/loapic_intr.c
...

Everything is so wrong or missing for ARM, NVIC should truely be an interrupt_controller driver in Zephyr. May be that is how I should implement for ARM then, may be inconsistent based on NVIC as I see it is so now in the drivers/interrupt_controller for others!. This will make a subsystem like a BLE controller a portability nightmare, unless there is an interrupt controller driver model, is there one? irq.h is the closest i could find.

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? :)
I am trying to generalise. I need a bottom-half, a routine that is scheduled by the top half to be executed later, at a safer time. irq_offload in Zephyr sense, but I really want is Tasklets.

-Vinayak

Join devel@lists.zephyrproject.org to automatically receive all group messages.