A question to the FreeRTOS gurus:
How much time may we spend in a ticker event handler, or generally a
software timer callback, without risking system stability?
The FreeRTOS manual explicitly warns about using any kind of
blocking calls within the timer service task, as all software timer
callbacks are executed in that context:
https://freertos.org/RTOS-software-timer.html
"Timer callback functions execute in the
context of the timer service task. It is therefore essential that
timer callback functions never attempt to block. For example, a
timer callback function must not call vTaskDelay(),
vTaskDelayUntil(), or specify a non zero block time when
accessing a queue or a semaphore."
The timer service queue currently has 10 slots. That's tunable, but
I'm also worried about other system components possibly relying on
regular timer periods of higher frequency.
My specific issue: I'm producing the notifications from my ticker1
handler. I now found out a simple standard info notification needs
already around 10 ms, and my battery status update (15 data
messages) needs 60-70 ms. I thought these would run faster, not sure
where the time is spent. I'm using the command notifications, nice
to use but with quite some overhead of course.
So if for example the wifi or bluetooth stack needs a 50 ms timer,
that may already be a problem. But do system components use software
timers for time critical tasks?
The solution would be moving the notification generator to a
separate task. A new task would need RAM, but there's also the
housekeeping task, which could generally be made available for such
needs. It's basically idle after the init process and already has a
large stack. I think about adding a callback execution queue to it,
so my ticker handler would simply queue the notification generator
call there.
Thanks,
Michael
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26