Am I at interrupt level?

Kernel
1

I’m not suggesting this is good design, but:

Assume I’ve received a callback. It could have been from an ISR or from an xTimer expiration.

If I’m inside an ISR, I need to call xTaskNotifyFromISR(). But if it’s an xTimer notification, I believe I need to call xTaskNotify().

So: is there a way to determine dynamically if I need to call xTaskNotifyFromISR() vs xTaskNotify()? Alternatively, do bad things happen if I call xTaskNotifyFromISR() from within an xTimer callback?

(To repeat myself: I’m not defending this as good design. But it could simplify the code design in this specific case…)

2

Knowing if you are in an interrupt or not is a port specific thing. Some ports provide macros that make it easier - such as https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/master/portable/GCC/ARM_CM4F/portmacro.h#L171 - gut calling the ‘FromISR’ versions from tasks is fine too.

3

For Cortex-M MCUs there is a Processor Status Register IPSR telling the current IRQ number which could be checked in the associated callback.
I think I’d go this way because it’s HW managed and inherently race free (if I’d have to stick to this unfavorable design).

4

Do you mean that it’s permissable to call the FromISR version when I’m not in an ISR?

5

Answer actually depends on the port you are using. Generally, if the port you use supports interrupt nesting (such as Cortex-M, RX, PIC32, etc.) then you can call the FromISR versions from tasks. The opposite is not true - you cannot call the standard versions from interrupts. Maybe this information needs to be added to https://www.freertos.org/FAQ_API.html#IQRAPI

1 Like
6

That’s great news! :+1:

In my case, it’s Cortex-M and it’s all user-level interactions, so speed is not an issue.

And yes, adding a paragraph to the FAQ could be handy! :slight_smile:

Many thanks.