Forums

Using different numbers of TQ but same frequency on CAN bus?

Started by Mike Noone February 24, 2007
Hi - I have a system that consists of one Atmel SAM7X256 connected via
CAN to 6 Microchip MCP2515 chips. The MCP2515s have 20MHz clocks, and
the SAM7X256 has a 55MHz clock. I have the CAN bus running at 1MHz
right now, but the chips aren't perfectly matched. Specifically, the
SAM7X256 uses 11TQ, while the MCP2515 uses 10TQ. I had to do this as
otherwise I'd have to have fractional baudrate divisors, which
obviously is not possible. Communication is perfect without any CAN
errors whatsoever - but I'm just wondering - is this allowed within
spec? Or am I just getting lucky? I have the propagation segment on
the SAM7X256 1TQ longer than on the MCP2515. Is this the best part to
lengthen? These are my settings:

MCP2515:
syncseg = 1TQ
PS1 = 3TQ
PS2 = 3TQ
propseg = 3TQ

AT91SAM7X256:
syncseg = 1TQ
PS1 = 3TQ
PS2 = 3TQ
propseg = 4TQ

Thanks!

-Mike

On 24 Feb 2007 12:41:31 -0800, "Mike Noone" <nleahcim@gmail.com> wrote
in comp.arch.embedded:

> Hi - I have a system that consists of one Atmel SAM7X256 connected via > CAN to 6 Microchip MCP2515 chips. The MCP2515s have 20MHz clocks, and > the SAM7X256 has a 55MHz clock. I have the CAN bus running at 1MHz > right now, but the chips aren't perfectly matched. Specifically, the > SAM7X256 uses 11TQ, while the MCP2515 uses 10TQ. I had to do this as > otherwise I'd have to have fractional baudrate divisors, which > obviously is not possible. Communication is perfect without any CAN > errors whatsoever - but I'm just wondering - is this allowed within > spec? Or am I just getting lucky? I have the propagation segment on > the SAM7X256 1TQ longer than on the MCP2515. Is this the best part to > lengthen? These are my settings: > > MCP2515: > syncseg = 1TQ > PS1 = 3TQ > PS2 = 3TQ > propseg = 3TQ > > AT91SAM7X256: > syncseg = 1TQ > PS1 = 3TQ > PS2 = 3TQ > propseg = 4TQ > > Thanks! > > -Mike
We've been doing this for quite some time, without any problems, using a master with external CAN controllers with 8 MHz clock (8 TQ at 500 KHz), and the on-chip CAN controllers on slave DSPs that wind up using 20 TQ. Never had a problem. If you're not having any problems, I wouldn't change anything. -- Jack Klein Home: http://JK-Technology.Com FAQs for comp.lang.c http://c-faq.com/ comp.lang.c++ http://www.parashift.com/c++-faq-lite/ alt.comp.lang.learn.c-c++ http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
On Feb 24, 12:41 pm, "Mike Noone" <nleah...@gmail.com> wrote:
> Hi - I have a system that consists of one Atmel SAM7X256 connected via > CAN to 6 MicrochipMCP2515chips. The MCP2515s have 20MHz clocks, and > the SAM7X256 has a 55MHz clock. I have the CAN bus running at 1MHz > right now, but the chips aren't perfectly matched. Specifically, the > SAM7X256 uses 11TQ, while theMCP2515uses 10TQ. I had to do this as > otherwise I'd have to have fractional baudrate divisors, which > obviously is not possible. Communication is perfect without any CAN > errors whatsoever - but I'm just wondering - is this allowed within > spec? Or am I just getting lucky? I have the propagation segment on > the SAM7X256 1TQ longer than on theMCP2515. Is this the best part to > lengthen? These are my settings: > > MCP2515: > syncseg = 1TQ > PS1 = 3TQ > PS2 = 3TQ > propseg = 3TQ > > AT91SAM7X256: > syncseg = 1TQ > PS1 = 3TQ > PS2 = 3TQ > propseg = 4TQ > > Thanks! > > -Mike
If the bit times are exactly the same, I think you should have no problems caused by clock mis-match. I've often used nodes with different clocks and different CANbus "time quanta" but I've almost always been able to match bit times precisely. (Bus length and speed are still as constrained as always.) My belief is that the only testing that counts for much is testing that forces a lot of bus contention (arbitration). The fact that nodes can hear each other when the packets don't collide never convinces me I have a functional bus. I create a test case with a heavily loaded bus, and make sure there are many messages whose IDs are the same for the first many bits. If THAT runs without retries, I trust my cabling, transceivers, PropSeg, SynchSeg, sample point, bit times etc. Rick Corey (Am I paranoid _enough_?)