- The can object CAN_rxtask listens on the rx
queue to receive instructional messages from canbus
drivers. These can be:
- CAN_frame: simply passes an entire incoming
can frame to the IncomingFrame handler.
- CAN_rxcallback: an instruction for the
CAN_rxtask to call the RxCallback task repeatedly.
- CAN_txcallback: an instruction for the
CAN_rxtask to call the TxCallback once.
- 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.
- The system is arranged so that individual bus
driver interrupt implementations can be fast and
efficient.
- 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.
- 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.
- 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.
- 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).
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.
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.
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.
Regards, Mark.
Greg,
please check the receive flow chart, that's not the
way the MCP2515 is supposed to work with
RXB0CTRL.BUKT=1 and no filters -- if the documentation
is correct.
Your change still will produce wrong IncomingFrame()
calls caused by the return true from the error
handler. You need to change the RxCallback() return
type (or
use the frame buffer for an auxiliary result tag) and
call loop to add the "don't send but keep calling"
case.
Regards,
Michael
Am 10.01.2018 um 23:27 schrieb Greg D.:
The functioning of
buffer overflow, I believe, is working as it should.
I see that most of the time, frames come in on
buffer 0. When I cause
the overflow by starting wifi, I see a single frame
received in buffer
1, along with the status of a buffer overflow from
buffer 0, but the
interrupt status only shows buffer 1 as being full:
status from register
2C is 0x22, not 0x23. The error status was 0x40,
indicating the single
overflow, as expected. My guess is that the timing
is such that buffer
0 was being read at the time the next frame arrived,
so it went into
buffer 1, and that buffer 0 had emptied by the time
buffer 1's interrupt
was seen. I have not seen a buffer 1 overflow
(which would indicate
that a frame was actually lost), so the buffer 0
overflow is totally not
an issue. At most, it's a warning that the system
is under load. No
surprise there; it was.
--
Michael Balzer * Helkenberger Weg 9 * D-58256
Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev