<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>