<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Michael,<div class=""><br class=""></div><div class="">Yes, this is nasty and really not the correct way of doing things. The housekeeping task is wasted, and moving the ticker signals into that would make much more sense.</div><div class=""><br class=""></div><div class="">I’ll handle this. Shouldn’t take me long, and I can commit in the next hour or so.</div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 29 Mar 2018, at 2:50 AM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="content-type" content="text/html; charset=utf-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
A question to the FreeRTOS gurus:<br class="">
<br class="">
How much time may we spend in a ticker event handler, or generally a
software timer callback, without risking system stability?<br class="">
<br class="">
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 class="">
<br class="">
<a class="moz-txt-link-freetext" href="https://freertos.org/RTOS-software-timer.html">https://freertos.org/RTOS-software-timer.html</a><br class="">
<blockquote class=""><i class="">"</i><i class="">Timer callback functions execute in the
context of the timer service task. It is therefore</i><i class=""> </i><b class=""><i class="">essential</i></b><i class=""> </i><i class="">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 class="">"</i><br class="">
</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 class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
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 class="">
<br class="">
Thanks,<br class="">
Michael<br class="">
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</div>
_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>