[Ovmsdev] Problems with IncomingFrameCan when registering two can buses.
dexter at expeedo.de
Sun Dec 31 03:30:13 HKT 2017
can you please try this: locate the speed setup in mcp2515.cpp, it's around line 115. Replace the setup for 100 KBPS by this:
//cnf1=0x03; cnf2=0xfa; cnf3=0x87;
cnf1=0x44; cnf2=0xe5; cnf3=0x83;
Then try again.
Am 30.12.2017 um 20:25 schrieb Geir Øyvind Vælidalo:
> 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.
>> 30. des. 2017 kl. 19:29 skrev Greg D. <gregd2350 at gmail.com <mailto: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.
>> 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.
>>>> 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.
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev