[Ovmsdev] Higher resolution events

Mark Webb-Johnson mark at webb-johnson.net
Wed Jan 10 13:58:39 HKT 2018

We’re talking about FreeRTOS timers here, not chip-level timers.

From what I can see, FreeRTOS has a task that it uses to run these timers and execute the callbacks. I think creating the timer once, and then resetting it each time you need it is probably the best approach (as it reduces heap allocation/deallocations).

Regards, Mark.

> On 10 Jan 2018, at 10:26 AM, HONDA S-2000 <s2000 at audiobanshee.com> wrote:
> On Dec 2, 2017, at 1:46 AM, Tom Parker <tom at carrott.org> wrote:
>> On 27/11/17 00:42, Mark Webb-Johnson wrote:
>>> You definitely don’t want to be spinning - that won’t give you any precision on the delay (other tasks may pre-empt), and is also wasteful.
>>> How about a timer (xTimerCreate). Have it fire once every 50ms/100ms. You can xTimerStart start it, and stop when done.
>> This worked! I create the timer once, start it whenever I receive the command, and stop it from within the timer call when I'm done.
>> I've got a bit more testing to do before I push, and I'd like to get the other leaf pull request out of the way first the remote command changes build on that change.
> Naive question here: Does creating a timer use up a finite resource? What if other modules or commands need timers? Is there a risk that xTimerCreate will fail for some other part of the code while you’re holding on to your timer?
> I ask because perhaps it would be better to create the timer when you receive a command, and release or free the timer when you’re done. Of course, if your command is always being sent periodically, then it may not matter whether the timer resource is made available for those brief windows in between repetitions.
> It seems that modern ARM chips have lots of timer resources, but they’re still finite.
> Yes, I realize that this is a basic memory-versus-speed tradeoff in efficiency. There’s not necessarily anything wrong with creating a resource once and then reusing it forever - I’m just wondering about the ramifications.
> Brian
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

More information about the OvmsDev mailing list