<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I've pushed my latest changes to optimize CAN throughput &
latency, which had problems before and have become worse with
aggressive SPIRAM usage.<br>
<br>
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>
<br>
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>
<blockquote><tt>class SevconClient : public InternalRamAllocated</tt><br>
</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>
<br>
See the Twizy CanResponder() in module rt_can for an example:<br>
<blockquote><tt>void OvmsVehicleRenaultTwizy::CanResponder(const
CAN_frame_t* p_frame)</tt><tt>;</tt><br>
<tt>MyCan.RegisterCallback(TAG,
std::bind(&OvmsVehicleRenaultTwizy::CanResponder, this,
_1));</tt><br>
</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>
<br>
The new build is in my "edge" directory.<br>
<br>
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>
<br>
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>
<br>
Regards,<br>
Michael<br>
<br>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>