Re: RFC: Extension to External Interrupt API

Andy Ross

Vinayak Kariappa Chettimada wrote:
I am implementing a "work" (tasklet in Linux terms), a "work", being
a function/routine, is invoked as a direct call i.e. if the caller
is in the same priority as the ISR and the software interrupt (my
"work" group) that would have been offloaded to (if were at another
priority) is enabled. Hence, the need for irq_is_enabled().

In theory, each h/w interrupt can have separate/own bottom-half
"work" group (ISR). Why, to have priority levels for the
Yeah, this got some water-cooler attention last week. So it seems
what you're really asking for is an interrupt bottom half framework
for zephyr. So you can have your fiber scheduled alongside the
hardware interrupts when needed.

And (Ben needs to jump in here, I'm no expert) it seems like we have
most of what is needed already in the fiber scheduler. All that I can
see we'd need is:

1. Map the available hardware interrupt priorities to the top N fiber

2. Mask off equal and lower interrupt priorities during the execution
of a fiber at those levels. This may be tricky to specify on all
architectures, and may involve some of them running "bottom half"
fibers with interrupts disabled. It might plausibly break some
assumptions in existing code that has an "in an ISR" notion (the
definition of "ISR" gets fuzzy).

3. Arrange to have the exit code for every ISR call _Swap() to
reschedule instead of returning directly to the interrupted task.
This would have some code size cost (maybe a tiny stub to wrap the
user-defined ISRs), though not huge.

But at that point, you don't need to muck with architecture-specific
interrupts to get what you want. You just wake up your work fiber(s)
from your existing ISRs with whatever IPC mechanism you want (give a
semaphore, write a command to a fifo, whatever) and they get scheduled
at the IRQ-scale priority you want.

What did I miss?


Join to automatically receive all group messages.