Ignacio García Pérez wrote:
I noticed that when an interrupt object is created using
rt_intr_create(), it is created disabled, and a call to rt_intr_enable()
is necessary for the ISR to be called.
Question is: is this the expected behaviour?.
Yes. You don't necessarily want to take interrupts immediately after the
object is created, for which you might have some additional housekeeping
chores to perform before that.
If so, I think this should
be mentioned somewhere in the rt_intr_create documentation. In fact,
from reading the docs one could infer the opposite.
Ok, will add a note to rt_int_create().
On a related issue, I noticed that the rt_intr_enable() documentation says:
"Enables the hardware interrupt line associated with an interrupt
object. Over Adeos-based systems which mask and acknowledge IRQs upon
receipt, this operation is necessary to revalidate the interrupt channel
so that more interrupts from the same source can be notified."
Is this correct?. I ask because the rt_intr_create() documentation tells
you to just return RT_INTR_ENABLE from the ISR if you want this. It's
Well, the text seems pretty clear to me here: rt_intr_enable() specifies
that the re-enabling _operation_ should be carried on after IRQ receipt,
but not necessarily using rt_intr_enable(). Returning RT_INTR_ENABLE
from the ISR is just the other way to do this.
Xenomai-core mailing list