- 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.hkhttp://lists.teslaclub.hk/mailman/listinfo/ovmsdev