<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    A question to the FreeRTOS gurus:<br>
    <br>
    How much time may we spend in a ticker event handler, or generally a
    software timer callback, without risking system stability?<br>
    <br>
    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:<br>
    <br>
    <a class="moz-txt-link-freetext" href="https://freertos.org/RTOS-software-timer.html">https://freertos.org/RTOS-software-timer.html</a><br>
    <blockquote><i>"</i><i>Timer callback functions execute in the
        context of the timer service task. It is therefore</i><i> </i><b><i>essential</i></b><i> </i><i>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.</i><i>"</i><br>
    </blockquote>
    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.<br>
    <br>
    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.<br>
    <br>
    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?<br>
    <br>
    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.<br>
    <br>
    Thanks,<br>
    Michael<br>
    <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </body>
</html>