Geir & Greg,
first of all, I did an over-optimization mistake in the RxCallback:
the return after fetching the frame must always be true -- fix is
pushed.
That has caused frames to get lost so you should apply this fix
first.
Am 31.12.2017 um 01:00 schrieb Geir
Øyvind Vælidalo:
I did a test where I created three counters.
One went into MCP2515_isr and counts every interrupt.
One was added as the
first code line in mcp2515::RxCallback.
And the
third one was added to RxCallBack, but right before we read
the CAN frame via SPI that will end up in IncomingFrame. I.e.
should be a count of every CAN frame.
This
is what I got:
OVMS > can can2 status
CAN: can2
Mode: Active
Speed: 100000
Rx pkt:
82
MCP2515_isr:
239
RxCallback1:
320
RxCallback2:
295
Rx err:
0
Tx pkt:
0
Tx err:
0
Err flags: 0x2040
These numbers puzzles me. Shouldn’t RxCallback1 and RxCallback2 be less or equal to MCP2515_isr? Where does these extra
81 calls come from? I’m missing something here...
No, that's expected behaviour. The MCP2515 has two RX buffers plus
error conditions. The framework is designed to loop RxCallback over
an IRQ event until all buffers and error conditions have been
processed, so RxCallback counters should always be >= ISR count.
Also, RxCallback2 is much bigger than Rx pkt, which means not all frames are sent
to IncomingFrame.
That's in part due to my bug, but it also can happen under normal
conditions, as an error IRQ will also trigger the RxCallback but not
return a frame to be processed.
What does the 0x2040 means? And where do that
number comes from?
That's constructed in line 293 from the error interrupt flags and
the error register. The lower 8 bits are in the image I sent, the
upper 8 bits are
// MERRF 0x80 = message tx/rx error
// ERRIF 0x20 = overflow / error state change
Regards,
Michael
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26