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