<div dir="auto"><div dir="ltr"><div dir="ltr"><div>Hi Greg,</div>Somehow missed this comment earlier.<div><br></div><div>Yes, this is totally on the Vehicle Task - so I've used a 200ms timer to inject a frame with a null task into the vehicle loop which cause the extra poll.</div><div dir="auto"><br></div><div dir="auto"> The only thing I've done with the ECU task is to add an event for when it gets turned on and off. This is then listened for in the vehicle code calling a virtual function allowing the individual Vehicle implementations to respond. </div><div dir="auto"><br></div><div dir="auto">Michael Geddes </div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 13 Feb 2023 at 12:06, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" target="_blank" rel="noreferrer">mark@webb-johnson.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>Greg,<div><br></div><div>On reflection, I think Michael is actually talking about the vehicle task (ODBII poller), rather than ECU task (OBDII ECU receiver).</div><div><br></div><div>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.</div><div><br></div><div>Regards, Mark<br><div><br><blockquote type="cite"><div>On 13 Feb 2023, at 11:58 AM, Greg D. <<a href="mailto:gregd2350@gmail.com" target="_blank" rel="noreferrer">gregd2350@gmail.com</a>> wrote:</div><br><div>
<div bgcolor="#FFFFFF">
Hi Michael,<br>
<br>
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.<br>
<br>
What are you trying to do?<br>
<br>
Greg<br>
<br>
<br>
<div>Michael Geddes wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div>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).</div>
<div dir="auto"><br>
</div>
<div dir="auto">Michael <br>
<br>
<div class="gmail_quote" dir="auto">
<div dir="ltr" class="gmail_attr">On Mon, 13 Feb 2023, 9:08
am Mark Webb-Johnson, <<a href="mailto:mark@webb-johnson.net" target="_blank" rel="noreferrer">mark@webb-johnson.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>This approach (<a href="http://ticker.ms/" rel="noreferrer noreferrer" target="_blank">ticker.ms</a>.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?
<div><br>
</div>
<div>The events are processed in the context of the
housekeeping task.</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>Regards, Mark.<br>
<div><br>
<blockquote type="cite">
<div>On 11 Feb 2023, at 12:08 PM, Michael Geddes
<<a href="mailto:frog@bunyip.wheelycreek.net" rel="noreferrer noreferrer" target="_blank">frog@bunyip.wheelycreek.net</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">Hi all,<br>
<div><br>
</div>
<div>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.</div>
<div>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.</div>
<div>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.</div>
<div><br>
</div>
<div>So I have implemented the following:<br>
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). </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div> The idea of this is that it keeps the
queue moving in case there were protocol
errors or other hiccoughs that stopped it
continuing! </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>e) For (currently) the Ioniq 5, I
register a listener for these events and
then call a function ECUStatusChange(bool). </div>
<div> 1) For 'enabled' this calls
PollSetThrottling(8) and
PollSetSubtick(true)</div>
<div> 2) For 'disabled' this calls
PollSetThrottling(4) and
PollSetSubtick(false)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Any feedback on any of this would be
greatly appreciated. I'm worried about</div>
<div>* Thread safety (would these events be
executed in the same thread?)</div>
<div>* Overloading the system somehow /
causing battery drain when system off.</div>
<div>* Do I need to turn off the
ticker.ms.100 event at some point for
power-saving? When?</div>
<div>* Stuff I haven't thought of.</div>
<div><br>
</div>
<div>//.ichael Geddes</div>
<div><br>
</div>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" rel="noreferrer noreferrer" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" rel="noreferrer noreferrer" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><br><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br></div></blockquote></div><br></div></div></div>_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote></div></div></div>