How to Handle Time-Critical Sensor Data Interrupts Efficiently in FreeRTOS on STM32F4?
I'm using FreeRTOS on an STM32F4 microcontroller to handle temperature sensor data. The sensor triggers an interrupt, and I need to process the data as quickly as possible within 10 microseconds. I thought creating a new task within the ISR using
xTaskCreate would be efficient for memory management cus during testing, I encountered an error during runtime that halted my system.
While the exact error message didn't clearly state "attempted to create a task from ISR," it indicated a function call failure. What's the recommended approach for handling time-critical sensor data interrupts in FreeRTOS while maintaining efficient memory management?
@Middleware & OS @HelperSolution:Jump to solution
Hmmm, I wouldn't be able to help you with your specific issue, as that would amount to doing it.
Here is the thing, you don't want to do anything lengthy, or expensive in an ISR. Basically you want to do stuff, like RX data, Indicate RX, Ack RX. This is for ISRs in general RTOS or not.
Ok thats the first part. The next thing is since you have this awareness, whenever you have some task arriving by ISR or Event you should be ready to handle it. So in your case you know some sensor data is going to come in by ISR, and you should be ready to handle it. Outside of the ISR remember.
...
7 Replies
You can’t dynamically create a task directly in an ISR, but you can pend a function that starts them from the RTOS daemon task.
Hi @ZacckOsiemo I wasn't aware of using the RTOS daemon task for this purpose, could you tell me a bit on how you will effectively use this approach for my time-critical sensor data processing? Are there any specific considerations or potential pitfalls I should be aware of when using this method?
Solution
Hmmm, I wouldn't be able to help you with your specific issue, as that would amount to doing it.
Here is the thing, you don't want to do anything lengthy, or expensive in an ISR. Basically you want to do stuff, like RX data, Indicate RX, Ack RX. This is for ISRs in general RTOS or not.
Ok thats the first part. The next thing is since you have this awareness, whenever you have some task arriving by ISR or Event you should be ready to handle it. So in your case you know some sensor data is going to come in by ISR, and you should be ready to handle it. Outside of the ISR remember.
In freeRTOS this would amount to roughly the following steps
1. Define a function that creates your processing task
2. Schedule the above Function from the ISR this is called pending in freeRTOS
3. Define your task that will be created by the function above
4. Any configuration you need so that your RTOS daemon can get the scheduled function and at some point invoke it.
take time and care to make sure your logic, or thinking is RTOS aware. Most of the time it's not a code issue. Its a logic issue. I hope this helps somewhat.
So lengthy operations within an ISR are detrimental to system performance , thanks @ZacckOsiemo for clarifying
Its ok if I interrupt you to pass me a pen on your desk. But if I interrupt you to run to shop for me while you are doing some code at your desk is not ok.
Lol yh true man , this illustration is straight forward
Glad to be of service.