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

Geir Øyvind Vælidalo geir at validalo.net
Sun Dec 31 03:25:35 HKT 2017


I don’t have anything connected to CAN3. I could try to use CAN3 instead of CAN2. It’s a long shot, but worth a try… I’ll look into it tomorrow.

Geir

> 30. des. 2017 kl. 19:29 skrev Greg D. <gregd2350 at gmail.com>:
> 
> Ha, I thought 100k was a typo for 1000, sorry...  Yeah, high speed overflow shouldn't be an issue.  On the other hand, low speed means that the time to receive a frame increases 10x, so that opens up a larger window if the chip doesn't like being talked to when actively receiving a frame.  Perhaps there is some interaction between the two sides of the chip?  For example, are there any registers that pertain to both busses?  I only use CAN3, with nothing connected to CAN2.
> 
> Greg
> 
> 
> Geir Øyvind Vælidalo wrote:
>> Thanks Greg. This can-bus is only 100kbit and uses less than 10% of the available capacity. It is a low speed, low traffic bus. And currently I don’t do any transmitting on it. 
>> 
>> I don’t see why it shouldn’t work for me, then.
>> 
>> Geir
>> 
>>> 30. des. 2017 kl. 19:07 skrev Greg D. <gregd2350 at gmail.com <mailto:gregd2350 at gmail.com>>:
>>> 
>>> For what it's worth, I've been using CAN3 for a long time with no lockups, running the OBDII ECU code.  What is different, perhaps, is that all the interactions are at 500k speed (vs 1000), and generally alternate one frame receive, followed by one frame transmit.  So, overflow should never occur unless the OBD2ECU code stops, at which point I probably didn't care.  Standard vs extended has not been a factor, in case that's a question.
>>> 
>>> The only issue we had was that if you try to transmit several frames back-to-back, the third and subsequent frame sent were all duplicates of the second frame.  That was fixed by adding a delay in the code, hoping that it would be sufficient for the prior frame to actually get sent.  Seems to work, though those frames are typically only sent at startup (request of VIN or ECU Name), not hammered on.
>>> 
>>> Greg
> 
> _______________________________________________
> 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/20171230/8af3c9dd/attachment.htm>


More information about the OvmsDev mailing list