Hi, To implement the Leaf's remote climate control, I need to send a frame, wait 50ms and then repeat another frame every 100ms for 25 repetitions. On the v2 hardware I implemented this with a 50ms delay and the ticker10th function. I wasn't able to find any delay functions in v3 so either I didn't look hard enough, nothing needs one, or busy-waiting isn't the right thing to do. Ticker10th isn't implemented. I could refactor the existing ticker task to fire 10 times a second instead of once per second, or I could register a new task for the climate control and cancel it after the the 25 repetitions. Or maybe something else altogether is appropriate? Thoughts?
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. One trick to use is that the freertos objects contain a void* user data you can use to point to ‘this’ (your C++ object). Regards, Mark.
On 26 Nov 2017, at 1:38 PM, Tom Parker <tom@carrott.org> wrote:
Hi,
To implement the Leaf's remote climate control, I need to send a frame, wait 50ms and then repeat another frame every 100ms for 25 repetitions.
On the v2 hardware I implemented this with a 50ms delay and the ticker10th function. I wasn't able to find any delay functions in v3 so either I didn't look hard enough, nothing needs one, or busy-waiting isn't the right thing to do. Ticker10th isn't implemented. I could refactor the existing ticker task to fire 10 times a second instead of once per second, or I could register a new task for the climate control and cancel it after the the 25 repetitions. Or maybe something else altogether is appropriate?
Thoughts?
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
I use vTaskDelay(50 / portTICK_PERIOD_MS) to delay 50ms. Not sure if that is the correct way, though. Geir
26. nov. 2017 kl. 12:42 skrev Mark Webb-Johnson <mark@webb-johnson.net>:
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.
One trick to use is that the freertos objects contain a void* user data you can use to point to ‘this’ (your C++ object).
Regards, Mark.
On 26 Nov 2017, at 1:38 PM, Tom Parker <tom@carrott.org> wrote:
Hi,
To implement the Leaf's remote climate control, I need to send a frame, wait 50ms and then repeat another frame every 100ms for 25 repetitions.
On the v2 hardware I implemented this with a 50ms delay and the ticker10th function. I wasn't able to find any delay functions in v3 so either I didn't look hard enough, nothing needs one, or busy-waiting isn't the right thing to do. Ticker10th isn't implemented. I could refactor the existing ticker task to fire 10 times a second instead of once per second, or I could register a new task for the climate control and cancel it after the the 25 repetitions. Or maybe something else altogether is appropriate?
Thoughts?
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
So long as you are calling this in IncomingFrameCan* or IncomingPollReply, that is possibly acceptable, but bear in mind that any other incoming CAN frames will be queued up and possible lost (if the queue overflows) while you are in vTaskDelay. Using timers means that the transmission will be in the context of the freertos timer task, but is generally acceptable for short quick jobs (like transmitting a single CAN frame). Regards, Mark.
On 27 Nov 2017, at 3:00 AM, Geir Øyvind Vælidalo <geir@validalo.net> wrote:
I use vTaskDelay(50 / portTICK_PERIOD_MS) to delay 50ms. Not sure if that is the correct way, though.
Geir
26. nov. 2017 kl. 12:42 skrev Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>>:
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.
One trick to use is that the freertos objects contain a void* user data you can use to point to ‘this’ (your C++ object).
Regards, Mark.
On 26 Nov 2017, at 1:38 PM, Tom Parker <tom@carrott.org <mailto:tom@carrott.org>> wrote:
Hi,
To implement the Leaf's remote climate control, I need to send a frame, wait 50ms and then repeat another frame every 100ms for 25 repetitions.
On the v2 hardware I implemented this with a 50ms delay and the ticker10th function. I wasn't able to find any delay functions in v3 so either I didn't look hard enough, nothing needs one, or busy-waiting isn't the right thing to do. Ticker10th isn't implemented. I could refactor the existing ticker task to fire 10 times a second instead of once per second, or I could register a new task for the climate control and cancel it after the the 25 repetitions. Or maybe something else altogether is appropriate?
Thoughts?
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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.
Pulled the outstanding request. All looks good now. Regards, Mark.
On 2 Dec 2017, at 5:46 PM, Tom Parker <tom@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. _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
On Dec 2, 2017, at 1:46 AM, Tom Parker <tom@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
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@audiobanshee.com> wrote:
On Dec 2, 2017, at 1:46 AM, Tom Parker <tom@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (4)
-
Geir Øyvind Vælidalo -
HONDA S-2000 -
Mark Webb-Johnson -
Tom Parker