<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I currently don’t send anything on can2. I could try to send something, but the car is away this weekend :-(<div class=""><br class=""></div><div class="">Geir<br class=""><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">13. jan. 2018 kl. 17:24 skrev Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">dexter@expeedo.de</a>>:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
  
  <div text="#000000" bgcolor="#FFFFFF" class="">
    Part one (TX queue) done & pushed.<br class="">
    <br class="">
    <tt class="">OVMS > can can1 status </tt><tt class=""><br class="">
    </tt><tt class="">CAN:       can1</tt><tt class=""><br class="">
    </tt><tt class="">Mode:      Active</tt><tt class=""><br class="">
    </tt><tt class="">Speed:     500000</tt><tt class=""><br class="">
    </tt><tt class="">Rx pkt:                  236657</tt><tt class=""><br class="">
    </tt><tt class="">Rx err:                       1</tt><tt class=""><br class="">
    </tt><tt class="">Rx ovrflw:                    0</tt><tt class=""><br class="">
    </tt><tt class="">Tx pkt:                  106378</tt><tt class=""><br class="">
    </tt><tt class="">Tx delays:                    4</tt><tt class=""><br class="">
    </tt><tt class="">Tx err:                       0</tt><tt class=""><br class="">
    </tt><tt class="">Tx ovrflw:                    0</tt><tt class=""><br class="">
    </tt><tt class="">Err flags: 0x800caa</tt><tt class=""><br class="">
    </tt><br class="">
    TX performance is rock steady on can1 -- the delays occurred when
    sending the stop charge request (as expected). I can't test can2/3,
    Greg & Geir, could you…?<br class="">
    <br class="">
    The TxCallback can't be used on the mcp2515. The ISR can't query the
    IRQ register, so the TX IRQs are now also handled by the
    RxCallback(). As the TX IRQs need to be cleared before loading the
    next frame, this needs another SPI call. I hope that doesn't
    introduce new problems.<br class="">
    <br class="">
    <br class="">
    No changes are necessary to the application code (well, except you
    can remove any hard coded delays now). The TX queue has a length of
    20 frames and will automatically be used by the drivers when no TX
    buffers are free.<br class="">
    <br class="">
    If an application wants to know whether a frame was sent immediately
    or gets delayed it can check the return code of the Write() method.
    Write() now also can take a second parameter for the maximum wait
    time for space in the TX queue to become available if it's full
    (default 0 = fail immediately if queue is full).<br class="">
    <br class="">
    <br class="">
    I also added logging of CAN errors. It's currently activated by "can
    … trace on", I don't think this needs to be active by default, just
    for CAN issue debugging.<br class="">
    <br class="">
    <tt class="">E (45718) can: Error can1 rxpkt=3 txpkt=0 errflags=0x800caa
      rxerr=1 txerr=0 rxovr=0 txovr=0 txdelay=0</tt><tt class=""><br class="">
    </tt><tt class="">E (83528) can: Error can1 rxpkt=7483 txpkt=226
      errflags=0x800caa rxerr=1 txerr=0 rxovr=0 txovr=0 txdelay=0</tt><br class="">
    <br class="">
    …that's also a first part of the logging extension (part two).<br class="">
    <br class="">
    Regards,<br class="">
    Michael<br class="">
    <br class="">
    <br class="">
    <div class="moz-cite-prefix">Am 12.01.2018 um 19:01 schrieb Michael
      Balzer:<br class="">
    </div>
    <blockquote type="cite" cite="mid:357384bc-b854-bf66-3cc5-55344c2b7c38@expeedo.de" class="">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
      Yes, I had something like that in mind. On TX IRQ, the drivers
      send CAN_txcallbacks to the CAN_rxtask. The CAN_rxtask then
      fetches frames from the TX queue and calls the TxCallback until
      all TX buffers of the driver are full. From the already existing
      TxCallback() stubs I suppose you had planned a scheme like that
      already? ;)<br class="">
      <br class="">
      Greg, can you create a pull request for your MCP2515 change? I'd
      like to merge that before beginning on the drivers.<br class="">
      <br class="">
      Thanks,<br class="">
      Michael<br class="">
      <br class="">
      <br class="">
      <div class="moz-cite-prefix">Am 12.01.2018 um 01:19 schrieb Mark
        Webb-Johnson:<br class="">
      </div>
      <blockquote type="cite" cite="mid:EB2639C4-0BF3-40C7-ACED-4364F2BDD606@webb-johnson.net" class="">
        <meta http-equiv="Content-Type" content="text/html;
          charset=utf-8" class="">
        Option B sounds like a good approach.
        <div class=""><br class="">
        </div>
        <div class="">Presumably we are just polling the tx queue in the
          existing CAN_rxtask based on TxCallback?</div>
        <div class=""><br class="">
        </div>
        <div class="">Regards, Mark.<br class="">
          <div class=""><br class="">
            <blockquote type="cite" class="">
              <div class="">On 11 Jan 2018, at 8:42 PM, Michael Balzer
                <<a href="mailto:dexter@expeedo.de" class="" moz-do-not-send="true">dexter@expeedo.de</a>>
                wrote:</div>
              <br class="Apple-interchange-newline">
              <div class="">
                <meta http-equiv="Content-Type" content="text/html;
                  charset=utf-8" class="">
                <div text="#000000" bgcolor="#FFFFFF" class="">
                  <div class="moz-cite-prefix">Greg, Mark,<br class="">
                    <br class="">
                    I can check your new code after work.<br class="">
                    <br class="">
                    For the TX performance/overflow issue, there are
                    basically two options:<br class="">
                    <ul class="">
                      <li class="">A: make all application TX be aware
                        of overflows, i.e. check the return value of the
                        CAN Write() call as necessary and/or introduce
                        sufficient delays (very ugly)<br class="">
                      </li>
                      <li class="">B: add a TX queue to the CAN
                        framework, so the application can just push some
                        frames as fast as it likes, with an option to
                        wait/block/fail if the queue is full</li>
                      <ul class="">
                        <li class="">→ the framework checks for TX
                          buffers becoming available <b class="">(i.e. driver
                            issuing a TxCallback request)</b> and
                          delivers queued frames only as fast as the
                          driver can handle them<br class="">
                        </li>
                      </ul>
                    </ul>
                    Option B has been on my todo list since removing the
                    delay from the MCP driver and introducing the TX
                    buffer check in the esp32can driver, as I don't
                    think applications should need to handle TX
                    overflows.<br class="">
                    <br class="">
                    I can try to implement that this weekend if it's
                    urgent now.<br class="">
                    <br class="">
                    Regards,<br class="">
                    Michael<br class="">
                    <br class="">
                    <br class="">
                    Am 11.01.2018 um 05:55 schrieb Greg D.:<br class="">
                  </div>
                  <blockquote type="cite" cite="mid:b229b09f-ef72-c564-7839-fa8a815157cd@gmail.com" class="">
                    <meta http-equiv="Content-Type" content="text/html;
                      charset=utf-8" class="">
                    Hi Mark, Micheal,<br class="">
                    <br class="">
                    Ok, good news and bad news.<br class="">
                    <br class="">
                    Good news:  Rx problem I believe is fixed.  Return
                    is true only if we received something, else false. 
                    And the other interrupt conditions are handled at
                    the same time, so no hangs are seen when restarting
                    wifi.  Rx overflow counter does increment properly. 
                    Yea!  Code has been pushed to my clone on Github.<br class="">
                    <br class="">
                    Bad news:  I am still able to hang the bus, but I
                    think it's on the transmit side.  The obd2ecu
                    process can send up to 3 frames back to back to
                    report the ECU Name, followed soon after by several
                    more with to grab the VIN.  Without any flow control
                    on the transmit side, and with a half-duplex CAN
                    bus, that's just too much.  Turning off the VIN
                    reporting (config set obd2ecu private yes) seems to
                    let everything run because I don't respond to the
                    VIN request (which lets everything drain as OBDWiz
                    times out).  Also verified by putting temporary
                    delays in the obd2ecu code to let things drain a bit
                    between frames.  So, the transmit side is still a
                    bit fragile, depending on timing.  Not sure quite
                    what to do here, as there is no easy place to queue
                    things...  Do we need to go back to the old way with
                    a delay in the obd2ecu code (perhaps better than in
                    the driver, no?).  Architecturally it's ugly, but
                    this only occurs at startup, and I don't mind the
                    kludge.  Do any other uses of the MCP busses do a
                    burst of transmitting?  If not, I'll put the delays
                    in the obd2ecu code and call it close enough.  Lemme
                    know.<br class="">
                    <br class="">
                    For receive, I'd go with what I have for now, if
                    Michael would be so kind as to review what I have
                    done first.  <a class="moz-txt-link-freetext" href="https://github.com/bitsofgreg/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/mcp2515/mcp2515.cpp" moz-do-not-send="true">https://github.com/bitsofgreg/Open-Vehicle-Monitoring-System-3/blob/master/vehicle/OVMS.V3/components/mcp2515/mcp2515.cpp</a> 
                    Hopefully he'll be back on line before I get up in
                    the morning.  Wonderful how the Earth's spin helps
                    with the teamwork.<br class="">
                    <br class="">
                    I'll keep poking at things tonight, and take it out
                    for a spin in the car tomorrow, just to see
                    everything working together.  But as it is now, it's
                    much better than it was before.  Really, this time. 
                    :)<br class="">
                    <br class="">
                    Greg<br class="">
                    <br class="">
                    <br class="">
                    <div class="moz-cite-prefix">Greg D. wrote:<br class="">
                    </div>
                    <blockquote type="cite" cite="mid:e1ebf1b2-15e2-fa7b-92e1-6ed2a4972b63@gmail.com" class="">
                      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
                      Hi Mark,<br class="">
                      <br class="">
                      I believe you are right about the multiple flags,
                      and the code only processing Rx and "error"
                      separately.  Fundamentally, a roll-over from
                      buffer 0 to buffer 1 isn't really an error, just a
                      statement of fact on what happened.  So, we should
                      have buffer 1 and the rollover flag at the same
                      time, which in fact is what I saw.  I need to
                      handle the Rx overflow at the same time as the
                      buffer 1 receive, I think...<br class="">
                      <br class="">
                      I need to grab some dinner, but have a fix in the
                      works.  Will report back in a few hours, hopefully
                      with good news...<br class="">
                      <br class="">
                      Greg<br class="">
                      <br class="">
                      <br class="">
                      <div class="moz-cite-prefix">Mark Webb-Johnson
                        wrote:<br class="">
                      </div>
                      <blockquote type="cite" cite="mid:E10D22FC-01E4-4976-8A90-EA916B9CE7F1@webb-johnson.net" class="">
                        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
                        <div class=""><br class="">
                        </div>
                        The design of the system is as follows:
                        <div class=""><br class="">
                        </div>
                        <div class="">
                          <ul class="MailOutline">
                            <li class="">The can object CAN_rxtask
                              listens on the rx queue to receive
                              instructional messages from canbus
                              drivers. These can be:</li>
                            <ul class="">
                              <li class="">CAN_frame: simply passes an
                                entire incoming can frame to the
                                IncomingFrame handler.</li>
                              <li class="">CAN_rxcallback: an
                                instruction for the CAN_rxtask to call
                                the RxCallback task repeatedly.</li>
                              <li class="">CAN_txcallback: an
                                instruction for the CAN_rxtask to call
                                the TxCallback once.</li>
                            </ul>
                            <li class="">In the case of CAN_rxcallback,
                              the canbus object RxCallback function is
                              expected to return FALSE to indicate
                              nothing should be done and RxCallback
                              should not be called again, or TRUE to
                              indicate an incoming frame has been
                              received and should be passed
                              to IncomingFrame.</li>
                            <li class="">The system is arranged so that
                              individual bus driver interrupt
                              implementations can be fast and efficient.</li>
                            <ul class="">
                              <li class="">The driver can choose to
                                receive the frame in the interrupt
                                handler itself, and pass it with
                                CAN_frame to CAN_rxtask. The esp32 can
                                driver uses this option.</li>
                              <li class="">Or the driver can choose to
                                delay the reception of the frame to the
                                RxCallback stage, and merely pass an
                                indication with CAN_rxcallback. The
                                mcp2515 driver uses this option.</li>
                            </ul>
                            <li class="">The true/false response from
                              RxCallback is designed to allow the
                              callback to signal it received a frame or
                              not. If it received a frame, then it is
                              called again.</li>
                            <li class="">This approach is used in order
                              to be able to centralise the reception of
                              CAN frames to one single task (avoiding
                              having to run individual tasks for each
                              canbus, hence saving stack RAM).</li>
                          </ul>
                          <div class=""><br class="">
                          </div>
                          <div class="">The RxCallback should definitely
                            ONLY return true if an actual can message
                            has been received, and is being passed back
                            in the frame pointer parameter.</div>
                          <div class=""><br class="">
                          </div>
                          <div class="">I suspect the issue is that the
                            mcp2515 RxCallback is being faced with
                            multiple error flags. Changing that to a
                            return true (as Greg has done) has the
                            undesired side-effect of issuing a spurious
                            IncomingFrame (with garbage/blank frame),
                            but also causes the RxCallback to be called
                            again (clearing the error flag). Perhaps the
                            solution is to put a loop in RxCallback so
                            that if an error condition is found, it
                            should be cleared, but then loop again and
                            keep clearing errors until no more are
                            found, then return false? I think that in
                            the mcp2515 case, this error clearing loop
                            can be simply handled in the RxCallback
                            itself.</div>
                          <div class=""><br class="">
                          </div>
                          <div class="">The alternative is to change the
                            RxCallback logic so that the return bool
                            value means simply ‘loop’ (call me again,
                            please), and have the RxCallback itself
                            call IncomingFrame(), rather than passing a
                            frame as a parameter. If Michael/Greg think
                            this is a better approach, I am happy to
                            make that change - it is pretty trivial.</div>
                          <div class=""><br class="">
                          </div>
                          <div class="">Regards, Mark.</div>
                          <br class="">
                        </div>
                      </blockquote>
                    </blockquote>
                  </blockquote>
                  <br class="">
                  <pre class="moz-signature" cols="144">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
                </div>
                _______________________________________________<br class="">
                OvmsDev mailing list<br class="">
                <a href="mailto:OvmsDev@lists.teslaclub.hk" class="" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a><br class="">
                <a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a><br class="">
              </div>
            </blockquote>
          </div>
          <br class="">
        </div>
        <br class="">
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br class="">
        <pre wrap="" class="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk" moz-do-not-send="true">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
      </blockquote>
      <br class="">
      <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
      <br class="">
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br class="">
      <pre wrap="" class="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br class="">
    <pre class="moz-signature" cols="160">-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
  </div>

_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></div></body></html>