<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class="">If you exceed 1 second, the monotonictime will start to jump and lose sync with real time.</div></blockquote><br class=""></div><div class="">There is actually a way around that (increment monotonictime in the timer handler, not in housekeeping task). The ticker.* calls still won’t go, but monotonictime will at least still increase at a reasonably accurate rate.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><br class=""><div><blockquote type="cite" class=""><div class="">On 29 Mar 2018, at 11:46 PM, 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="">
Mark,<br class="">
<br class="">
thanks, that's even better. We can also reduce the timer task stack
now. 6K is the current size, I think we should now be able to set
this to 1K, maybe 1.5. I'll try running it at 1K and report.<br class="">
<br class="">
For other ticker users: you may now use blocking calls (i.e.
semaphore or queue waits) and do longer processing in ticker event
handlers. Up to 1 second total time should be possible now (but not
recommended). If you exceed 1 second, the monotonictime will start
to jump and lose sync with real time.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
<div class="moz-cite-prefix">Am 29.03.2018 um 03:09 schrieb Mark
Webb-Johnson:<br class="">
</div>
<blockquote type="cite" cite="mid:C0E8F7A2-D9FB-4FA4-9B05-8DFCA1D57408@webb-johnson.net" class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
Done, and committed. Seems ok.
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On 29 Mar 2018, at 8:39 AM, Mark Webb-Johnson
<<a href="mailto:mark@webb-johnson.net" class="" moz-do-not-send="true">mark@webb-johnson.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8" class="">
<div 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 class=""><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="" moz-do-not-send="true">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" moz-do-not-send="true">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="" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a><br class="">
<a href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" class="" moz-do-not-send="true">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
_______________________________________________<br class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.teslaclub.hk" class="" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a><br class="">
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<br class="">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre wrap="" class="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<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=""></body></html>