
<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>