[Ovmsdev] Problems with IncomingFrameCan when registering two can buses.

[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...

Also, RxCallback2 is much bigger than Rx pkt, which means not all frames are sent to IncomingFrame. I Believe the reason is this code in can.cpp CAN_rxtask:

        case CAN_rxcallback:
          while (msg.body.bus->RxCallback(&msg.body.frame))
            {
            me->IncomingFrame(&msg.body.frame);
            }
          break;

Is this correct? Wouldn’t it skip calling IncomingFrame it there are only one interrupt?
I would think this is would be more appropriate:
  
         case CAN_rxcallback:
      	  {
          bool keepOn=true;
          do
            {
            keepOn = msg.body.bus->RxCallback(&msg.body.frame);
            me->IncomingFrame(&msg.body.frame);
            }while(keepOn);
          }
          break;

Do you agree?

But, the interrupts still stops :-( What does the 0x2040 means? And where do that number comes from? 

Best regards,
Geir




> 30. des. 2017 kl. 21:24 skrev Michael Balzer <dexter at expeedo.de>:
> 
> MCP2515 Arduino

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171231/e109ad74/attachment.htm>