[Feature Request] Can we get rid of xxxFromISR() functions or catch wrong function call (nonFromISR function call in ISR)?

[Hadatko]

Is your feature request related to a problem? Please describe. We found out after months that some function which is called in ISR was missing fromISR postfix. But application start rebooting recently.

Describe the solution you'd like For example RPMSG contains platform and environment function to figure out if the call is inside or outside of ISR and based on that they are calling rtos API. It would be nice if rtos itself could handle that. Maybe have some function to implement from users. I saw also xPortIsInsideInterrupt. So after that change freertos would have single api for in ISR and outside of ISR calls.

Describe alternatives you've considered Other possible solution could be inform somehow user that he is calling wrong function in/outside ISR.

Additional context

[RichardBarry]

Thanks for your feedback. There is an FAQ item here as to why the code is as it is - historical decisions. The 'FromISR' versions are often used as simpler/faster versions for use within tasks too - although some care needs to be done when doing that. Perhaps a quick thing to do would be to add asserts into the taskENTER_CRITICAL() and taskEXIT_CRITICAL() macros that triggers if the macros are called from an ISR as those macros are probably called by all non ISR versions of the API.

[Hadatko]

I understand that it can be harder to implement both feature with one API name. Your suggestion sounds good to me. And can be som check added also for oposite situation?

[john-mullan-agilent]

I ran into similar issues with FreeRTOS API functions and had luck writing my own API wrappers with a check for the condition (portNVIC_INT_CTRL_REG & portVECTACTIVE_MASK) to call the appropriate FreeRTOS API's as needed. This requires copying the portVECTACTIVE_MASK definition from port.c into user code, and maybe a FreeRTOS API could be provided to check this condition.

[chinglee-iot]

Hardware platform support is required to know the current context is in ISR or a normal task. There are existing port functions for this purpose. However, not every hardware platform implements this function. xPortIsInsideInterrupt() can be used if you are using cortex-M CPU platform. It is provided as a port function. If you are using other platform, you might need to implement this function yourself.

Another port macro portASSERT_IF_IN_ISR can be used to assert when current context is in ISR. It is still implemented in some port only.

taskENTER_CRITICAL and taskEXIT_CRITICAL is mapping to portENTER_CRITICAL and portEXIT_CRITICAL. The assertion trigger in ISR can be implemented in these port macros.

I will close this issue first. Feel free to open this issue for more discussion.