2025-12-23 5:21 AM
Good days at all. I need to start a project and I'm unsure which path to take: I'd like to create an application that requires some tasks to run in parallel and some to run at different times. I've used timers as interrupts in the past, so as soon as a timer reaches its end, I can execute tasks. Now I know I can also use tasks using FreeRTOS, and as I've seen in general, it seems that each declared task has settable delays. My question is this: when working with multiple tasks, is it better to use FreeRTOS or the interrupts of the various timers available? Another question: are the delays that can be set in the cycles within the tasks precise? From what I understand, I believe that both the timer and the FreeRTOS task are non-blocking activities for the processor, which can then perform other tasks without being "blocking." Thanks in advance.
Solved! Go to Solution.
2025-12-23 6:19 AM
> My question is this: when working with multiple tasks, is it better to use FreeRTOS or the interrupts of the various timers available?
Both are viable solutions. Neither is always better. If you need something to run at a precise time, a timer interrupt will generally be better because it is more precise and isn't subject to OS delays due to task switching.
> Another question: are the delays that can be set in the cycles within the tasks precise?
They are not infinitely precise. vTaskDelay will have a resolution of one OS tick which is 1 ms by default.
https://www.freertos.org/Documentation/02-Kernel/04-API-references/02-Task-control/01-vTaskDelay
2025-12-23 6:11 AM
For simple periodic actions use FreeRTOS timers. For timely execution of complex tasks use osDelayUntil. For time-critical, simple processing use MCU hardware timers.
2025-12-23 6:19 AM
> My question is this: when working with multiple tasks, is it better to use FreeRTOS or the interrupts of the various timers available?
Both are viable solutions. Neither is always better. If you need something to run at a precise time, a timer interrupt will generally be better because it is more precise and isn't subject to OS delays due to task switching.
> Another question: are the delays that can be set in the cycles within the tasks precise?
They are not infinitely precise. vTaskDelay will have a resolution of one OS tick which is 1 ms by default.
https://www.freertos.org/Documentation/02-Kernel/04-API-references/02-Task-control/01-vTaskDelay