In short, is it okay to use *FromISR() version of freertos functions in non ISR context?
For exemple, to not make a distinction between the way of writing a function as an ISR or a timer callback?
If it’s allowed to use FromISR function in user space without breaking the system, what would be the downside of doing so?
I’m working on cortex R5. If I’m not mistaken, interrupt nesting is not enabled by default when starting from a template project created by xilinx SDK. I say this because interrupts are never re-enabled from within main ISR exception handler, nor withing any of my irq_hanlers.
From what I can see, FromISR versions do enter critical sections too, but they seem to do it in a “wrap it all in” way, whereas normal versions allow for several enter-exit in the function (to allow for low interrupt latency where applicable?).
“normally” it is ok to use FromISR functions from tasks in ports that support interrupt nesting, but not in ports that do not. I think the Cortex-R port does support interrupt nesting.
Thats what I thought. CortexR5 does support indeed interrupt nesting. ARM documentation states that uppon entering an ISR, the interrupt enable bit in status register is automatically cleared. That would mean that until explicitely set back (interrupt enable bit), interrupt nesting cannot happen right? (In the sens that interrupt nesting is supported, but not enabled). I mean, that’s what ‘defines’ interrupt nesting? The fact of re-enabling interrupts while inside an interrupt?
If I recall correctly all interrupts are routed to a single interrupt entry point, which is written in C. It is then up to whoever implements the service routines
that are called from that single entry point as to whether they want to enable interrupts again before calling the actual handler.
For this it isn’t so much the hard supporting nesting, but the port. A port that doesn’t support nesting won’t need to implement a version of FromISR critical sections, so can make the macros empty, which says that using a FromISR function outside and ISR won’t get the needed protection. If the ports FromISR critical section works outside of an ISR then generally the FromISR functions would work when called outside an ISR (but not sure if there is any promise that they will always work).
I thought I remember at one point a statement that they could be used outside an ISR if done inside a critical section.
I understand. If the port enables interrupt nesting, then enter and exit critical from isr actually disables interrupt so from isr versions of api works. Only thing is that context switch should be explicitely done after calls if un userland (not the portYIELD_FROM_ISR, which just sets a variable to 1)
Yes, since some ports can’t schedule a scheduler requests in the middle of an ISR (it needs to be the last thing the ISR does), the FromISR routines will need an explicit call to taskYield (not sure if portYIELD_FROM_ISR is usable here in all cases, that may be one of the exceptions to using FromISR functions, but maybe it would work for all the cases that use nesting (I don’t know all the ports well enough).