[Ovmsdev] Time spent in ticker event handlers / new use for housekeeping task

[Mark Webb-Johnson]

Done, and committed. Seems ok.

Regards, Mark.

> On 29 Mar 2018, at 8:39 AM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
> 
> Michael,
> 
> 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.
> 
> I’ll handle this. Shouldn’t take me long, and I can commit in the next hour or so.
> 
> Regards, Mark.
> 
>> On 29 Mar 2018, at 2:50 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>> 
>> 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 <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
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180329/f101c5c1/attachment.htm>