Details when to use xxxFromISR()?

iamtherealeimer wrote on Friday, November 06, 2015:

Hi guys,

I have a general question how to determine when to use the xxFromISR()-functions?

First, I know that in the case I misuse the “regular” function, I will most likely get an assert which points me to use the FromISR()-function. But I would like to understand the logic when to use one or the other.

For example:
I am communicating with FreeRTOS via UART. I configured the TX and RX to be using the DMA. As soon as an internal buffer is full or I the termination-character is received, the data (in my case a string) is put onto to queues TX/RXQueue. Every package of data is signalled with the accroding callback,. As far as im concerned, the TX/RXCmpltCallbacks are not interrupts, or are they?

If I am not using the xQueueSendFromISR(), I am ending in an assert. So my guess is that I have a twist in my logic and I would like to untwist that. Or in other words: “How can I determine when to use FromISR or the regular function?”

Related to that question?
If I use the xQueueReceiveFromISR-function do I need to be in an ISR or does the queued element is from an ISR?

Thank you for your time and help, I realy appreciate every input on the topic.

eimer

rtel wrote on Friday, November 06, 2015:

If your Tx/Rx complete callback functions are called from the context on an interrupt service routine, then you will have to use the ‘FromISR’ version of the API functions. If they are called from the context of a task, then you can use either version (although using the ‘FromISR’ version from a task need care).

Using a DMA for the transmission sounds very efficient, which is good, so presumably you only have one interrupt being generated when the buffer is full (as you state) rather than lots of interrupts. That sounds ideal so far, but how are you then placing the string into a queue? If you place the whole string into a queue then it will definitely not be efficient, but if you are just queueing a pointer to the string then your set up sounds ideal.

When you are using an RTOS you also have the opportunity to defer interrupt processing to a task (so the ISR just unblocks a high priority task, then returns directly to the task, so interrupt processing occurs contigous in time just as if it had all been done in the ISR), and when executing from a task context you can use all the API functions. See the following link for some examples:
http://www.freertos.org/RTOS_Task_Notification_As_Counting_Semaphore.html