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