<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="">Looks good. I don’t see too much impact on available RAM for my configurations.<div class=""><br class=""></div><div class="">It will go to EDGE tonight, so we’ll get some more varied testing then.</div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 23 Jul 2018, at 4:30 AM, Michael Balzer <<a href="mailto:dexter@expeedo.de" class="">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="">
    I've pushed my latest changes to optimize CAN throughput &
    latency, which had problems before and have become worse with
    aggressive SPIRAM usage.<br class="">
    <br class="">
    There especially were too many RX overflows and TX delays now. The
    Twizy module needs to respond to some frames as fast as possible,
    and the delays added up to over 120 ms in some circumstances.<br class="">
    <br class="">
    I first moved the esp32can ISR and instance into internal RAM, then
    applied that change to all peripheral objects. To allocate objects
    of some class in internal RAM, simply add the super class
    InternalRamAllocated to it (counterpart to ExternalRamAllocated),
    i.e.<br class="">
    <blockquote class=""><tt class="">class SevconClient : public InternalRamAllocated</tt><br class="">
    </blockquote>
    This eliminated RX overflows (except some on init when starting the
    module/bus with running transmissions on the bus -- don't know yet
    if we can avoid them), and helped a bit with TX delays. Moving the
    vehicle instance into internal RAM also helped a bit with TX
    latency, but together only reduced it by about 10%. So I also added
    a synchronous callback mechanism to the CAN system to be able to run
    a CAN responder directly within the CAN rxtask context.<br class="">
    <br class="">
    See the Twizy CanResponder() in module rt_can for an example:<br class="">
    <blockquote class=""><tt class="">void OvmsVehicleRenaultTwizy::CanResponder(const
        CAN_frame_t* p_frame)</tt><tt class="">;</tt><br class="">
      <tt class="">MyCan.RegisterCallback(TAG,
        std::bind(&OvmsVehicleRenaultTwizy::CanResponder, this,
        _1));</tt><br class="">
    </blockquote>
    This reduced TX delays to zero most of the time. From time to time
    some delays still occurred, not continously but in chunks and only
    every few minutes. I think they were caused by the Wifi stack,
    because they seem to have disappeared after rearranging the CAN
    rxtask to be running at priority 23 and reducing the Wifi task
    priority to 22, but I need to collect some more data on this.<br class="">
    <br class="">
    The new build is in my "edge" directory.<br class="">
    <br class="">
    Placing the peripherals in internal RAM potentially solves other
    issues as well -- it's certainly not good if a peripheral component
    has to wait for an SPIRAM page-in operation. But I've had no
    reproducable issues before I could test now. We need to test this in
    the field.<br class="">
    <br class="">
    Regarding the issues with can2 & can3: I don't think they are
    related to this, but it's worth a try. The mcp2515 instances are in
    internal RAM now as well.<br class="">
    <br class="">
    Regards,<br class="">
    Michael<br class="">
    <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.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>