Greg, On reflection, I think Michael is actually talking about the vehicle task (ODBII poller), rather than ECU task (OBDII ECU receiver). That said, my comment applies equally to the vehicle task. Anytime our code has a task and receive queue, the timer handling can be implemented by simply injecting messages into that queue. Many tasks in freertos follow that model. Regards, Mark
On 13 Feb 2023, at 11:58 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Michael,
I've tried to track what you're proposing to do with the OBD2ECU task, but to be honest I'm confused. By design it is to be driven by the HUD; HUD sends a request for some metric, and the OBD2ECU task responds with whatever the current value of that metric is. If something isn't getting updated on the metric side, it can't conger up the data. Same if the HUD doesn't ask for something; there's no way to push an update to it.
What are you trying to do?
Greg
Michael Geddes wrote:
Ah thanks, this is exactly why I described it rather than just putting up even a draft. I'll do exactly as you recommend... It makes sense. I hadn't thought to feed the subtick through the ECU object. I can't imagine any other place where that kind of responsivness is required... So.. Yes, agreed. (And I'll make it a 200ms timer).
Michael
On Mon, 13 Feb 2023, 9:08 am Mark Webb-Johnson, <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
This approach (ticker.ms <http://ticker.ms/>.100 event) is a little concerning. Our event queue is of limited size, and often when we see a stuck/busy task the first sign is inability to send the 1 second ticker message. Adding another every 100ms would presumably make this 10 times worse?
The events are processed in the context of the housekeeping task.
Given that the OBD2ECU code has it’s own task, with receive queue, perhaps it would be safer to just register a simple 100ms freertos timer (running whenever the ECU task is running) and use that to feed a timer notification into the receive queue? That would keep the processing within the ECU task, and also avoid any locking/contention issues. Would either need to add a new custom message type, or just use something like frame.origin=NULL to signal it was a timer event (rather than an incoming can frame).
Regards, Mark.
On 11 Feb 2023, at 12:08 PM, Michael Geddes <frog@bunyip.wheelycreek.net <mailto:frog@bunyip.wheelycreek.net>> wrote:
Hi all,
Now that I have a functional HUD connection, I've been tweaking some things to make sure it is responsive. The HUD itself is polling multiple times (4?) per second, so it's making sure the speed (particularly) metric is kept up-to-date. Initially, it was really slow because I had left the message throttle as its default of 1. Which means that at most 1 ISOTP message was being executed a second and speed was being updated every 3-4 seconds, which was unusable. I upped that to 8, and that was an improvement, and now I have this sub-ticker mechanism (below) implemented, and it appears to increase responsiveness and decrease latency between the dashboard speedo and the HUD speedo. It's really hard to observe as it requires that you be driving! It's also hard to be objective. Without the sub-ticker it's workable. With the sub-ticker, I think it just tightens it up that much more.
So I have implemented the following: a) I added a new ticker timer in 'housekeeping' which sends an event every 1 ms "ticker.ms.100". (Though I'm thinking that every 2ms might be sufficient). The message is blocked from being sent to the web (now).
b) In vehicle.h I have a (protected) function PollSetSubtick(bool) that can turn off and on the use of this 'sub-second' ticker (first time it's turned on is when it actually registers for the event). This then sets up a count that is reset whenever the polling ticker is incremented (m_poll_ticker) and the sub-ticker is enabled.
c) When enabled, from sub-ticker count 4 onwards every 2 sub-ticks (0.1s), it calls PollerSend(false) as long as 1) It hasn't reach the end of the list, and 2) we aren't waiting for more parts of the current ISOTP message. The idea of this is that it keeps the queue moving in case there were protocol errors or other hiccoughs that stopped it continuing!
d) I have implemented events for when the ecu is turned on and off: vehicle.ecu.start and vehicle.ecu.stop respectively called from the constructor/destructor of the ECU class.
e) For (currently) the Ioniq 5, I register a listener for these events and then call a function ECUStatusChange(bool). 1) For 'enabled' this calls PollSetThrottling(8) and PollSetSubtick(true) 2) For 'disabled' this calls PollSetThrottling(4) and PollSetSubtick(false)
f) The other thing I did for Ioniq 5 was to put an extra 'Speed' check at the end of the poll list - (for car 'on' only). Which means it checks speed twice per poll tick.
Any feedback on any of this would be greatly appreciated. I'm worried about * Thread safety (would these events be executed in the same thread?) * Overloading the system somehow / causing battery drain when system off. * Do I need to turn off the ticker.ms.100 event at some point for power-saving? When? * Stuff I haven't thought of.
//.ichael Geddes
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev