[Ovmsdev] can1 TX performance solved

[Geir Øyvind Vælidalo]

Great Michael! I’ll test that as soon as I have the time.

The previous version made me come a little bit further, however it will still stop, but for another reason. Maybe the last change will fix that?

I seems my problem now has to do with the queue. The queue is shared between both CAN-busses: Can1 (500kbit) and can2 (100kbit).
The RxCallback sometimes handles multiple can-frames from can2 in one «queue»-entry. Which means it can take quite a long time to finish. At that time the much faster can1 fills the rest of the queue. At the next interrupt, the queue is full and the RxCallback on can2 won’t be called.
The flags on mcp2515 won’t be cleared and no more interrupts will occur.

I wonder if we should have one queue per can and in CAN_rxtask we could check m_rxqueue1, m_rxqueue2 and m_rxqueue in a round robin fashion.   
I think it is quick to test, so if your latest changes won’t fix this, I will try with separate queues.

Geir 



> 31. des. 2017 kl. 21:38 skrev Michael Balzer <dexter at expeedo.de>:
> 
> Turned out this was no hardware issue but a scheduler problem: the CAN rx and vehicle rx tasks were not scheduled often & fast enough to consistently keep up with the 10 ms period.
> 
> After assigning the CAN RX task to core 0 and raising the vehicle task priority to 10, there are no more TX overflows, and my charge control override works perfectly.
> 
> Geir, I don't know if that helps with your can2 issue, but it's worth a try.
> 
> Regards,
> Michael
> 
> 
> Am 31.12.2017 um 19:59 schrieb Michael Balzer:
>> 
>> And TX overflows actually do occur quite often, without a plausible cause:
>> 
>> OVMS > can can1 status 
>> CAN:       can1
>> Mode:      Active
>> Speed:     500000
>> Rx pkt:                  133146
>> Rx err:                       0
>> Rx ovrflw:                    0
>> Tx pkt:                   53238
>> Tx err:                      95
>> Tx ovrflw:                  498
>> Err flags: 0x12c00
>> 
>> In this case, a TX occurs every 10 ms on a 500 kbit bus -- plenty of time for the buffer to get sent. I'm looking into that.
> 
> -- 
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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