<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Just added an additional fix for this.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 13.01.2018 um 19:03 schrieb Michael
Balzer:<br>
</div>
<blockquote type="cite"
cite="mid:0aec6e8b-1f85-b4dd-af45-fe8217ad350d@expeedo.de">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Please check again.<br>
<br>
Thanks,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 13.01.2018 um 18:42 schrieb Greg
D.:<br>
</div>
<blockquote type="cite"
cite="mid:24d452bf-1ce8-5263-7b43-5c5d6c3cc245@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
Gave it a quick try, and got a crash... I'll see if I can
isolate it a bit, but here's something to start with.
Tombstone, attached. <br>
<br>
Greg<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">Geir Øyvind Vælidalo wrote:<br>
</div>
<blockquote type="cite"
cite="mid:40A285C5-B816-4B4D-9B4F-6A8277A051C9@validalo.net">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
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="" moz-do-not-send="true">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 class="" wrap="">_______________________________________________
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 class="" wrap="">_______________________________________________
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>
</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>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
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>
<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>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
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>
<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>