CAN Bus Timing Question

Unless those crystal tolerances are small enough that you don't exceed the 0.5% in total, I'd say you are.

Well, make it more challenging, then! Use 50 meters of non-optimal cable (say, 50 meters of salvaged 110 Volts power cable with some silly connectors, piled up in loops close to a flourescent tube, CRT or other nice generator of EMI), and see what happens.

The first thing you'll lose consistently is maximum cable length for full-length messages (8 bytes of payload optimized to require a large number of stuff bits), from the node with the faster clock to the one with the slower, because the ACK bit sent by the recipient won't arrive in time for the sender to receive it properly.

What's stopping you from using 29.something MHz on the master, too?

Since AIUI CAN guarantees a bit transition after no more than 4 bits, it seems that you're looking at a 1.24% additional cumulative timing error before the nodes can resynch themselves. If I'm analysing that correctly it doesn't sound very bad to me.

What might be very interesting to try would be to lower the clock frequency (perhaps using some type of programmable clock chip) until you start to get failures in your worst-case setup. That would give you some clue as to your timing sensitivity.

Mike

On 17 Oct 2003 10:55:46 GMT, Hans-Bernhard Broeker wrote in comp.arch.embedded:

Typical crystals are rated at 0.02%, so adding two of those to the nominal mis-match yields 0.35%. Of course I'm aware that this doesn't include temperature variations.

The master is using a stand-along controller, separate from the processor, that only goes up to 25 MHz tops.

It would work that way if CAN nodes were all resynching themselves on transitions. IIRC, by default they don't. Esp. not at the higher baud rates.

And that's before you start to worry about those parts of a CAN frame that don't undergo bit stuffing.

I thought that was the whole point of bit stuffing, to provide transitions and guaranteed intervals to resynch on. I'm no expert in CAN details, though, so I could very well be wrong. In that case, what *is* the point of bit stuffing?

Are there any fields longer than 4 bits that don't bit-stuff?

To distinguish between 8 bit data and start/end flags.

Meindert

"Mike Silva" schrieb im Newsbeitrag >

Of course there are! The arbitration field for instance. If bit stuffing would take place the whole identifier method would be useless.

And by the way? Why 4 bit? The longest period without Re-Synchronisation are 10 bit (5 dominant, 5 recessive), in case of Re-Synchronisation after error frames it is even 13 consecutive bit of one polarization.

Regards, Taso

"Jack Klein" schrieb

First, I would suggest to use the same oscillator frequency for both devices. 30 MHz and 29.something won't work! With 29.something it is not possible to match 2 µs = x*tq with x beeing an integer.

Yes, you migh risk something but there are ways you can avoid these problems. It is important that the minimal RJW in your system is

If you work at 30 MHz with a BRP of 4 you'll get according to this formula

tbit*fosc/BRP = BTL-cycles

For 500 kBaud

At 15 BTL-cycles one tq is 133,3 ns long, so programm your RJW in both controllers to RJW = 1. That equals 133,3 ns. The number of nodes this method works is -theoretically- infinite. It's all matter of oscillator tolerances and RJW, but I recommend not to experiment with heteregone frequencies like 29.something and 30 MHz! The frequencies variate at

Try, this is a deterministic approach of configuring a CAN-network.

Regards, Taso

Just to clear up any residual confusion I may have caused: that bit about CAN nodes not necessarily all doing resynchronization was bogus

--- they most definitely do.

The scheme is more complicated, really. The actual sampling frequency of a CAN line is considerably higher than the bus baud rate --- between 8 and 25 times as large, per the CAN 2.0 spec.

The spec restricts signal edges to fall within the first sample interval (called a "time quantum" or 'tq') of a CAN bit time or at most a certain number of quanta (the SJW, for 'synchronization jump width) after that. If it ever falls outside that time frame, you get synchronization error, and eventually the CAN node will go off-line.

In the end, you get two formulae for the oscillator tolerance (taken here from a CAN textbook edited by Prof. Wolfhard Lawrenz):

df

Well, here's what my spec says (BOSCH 1991):

-------- BIT STREAM CODING The frame segments START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD and CRC SEQUENCE are coded by the method of bit stuffing. Whenever a transmitter detects five consecutive bits of identical value in the bit stream to be transmitted it automatically inserts a complementary bit in the actual transmitted bit stream. The remaining bit fields of the DATA FRAME or REMOTE FRAME (CRC DELIMITER, ACK FIELD, and END OF FRAME) are of fixed form and not stuffed. The ERROR FRAME and the OVERLOAD FRAME are of fixed form as well and not coded by the method of bit stuffing.

--------

So the arbitration field is bit-stuffed according to this spec, and I guess that implies that the controllers are smart enough to figure out a stuff bit in the arbitration field and ignore it during on-the-fly arbitration. Rather surprising, actually!

The '4' was because I remembered incorrectly -- it's 5 consecutive bits. And you're right about the 10 bit period (5 dominant, 5 recessive) as I now see in the spec that only R->D edges are required to be used for resynch (makes sense). As usual, a little CAN experience did not an expert me make! ;-)

Mike

"Mike Silva" schrieb im Newsbeitrag

Yep, you're right. I know that part, but I still don't understand how it can work. I'll give an example:

Transmitter 1: ID = 0x9

SOF|0|0|0|0|0|Stuff|0|0|1|0|0|1

Transmitter 2: ID = 0x24

SOF|0|0|0|0|0| 1 |0|0|1|0|0

After five consecutive bit the second transmitter sends a recessive bit due to its defined ID. How is it possible that Transmitter2 assumes a sent stuff bit of Transmitter 1? As one can see, the bit pattern is odd, i.e. the one ID-field would be one bit longer, than the second one.

I don't know the stuff bit rule exactly, but imho it must define that every bit after 5 bit of consecutive polarity is a stuff bit. Otherwise arbitration cannot work out.

I would really like to know how. Maybe someone can help?

Ack.

You're forgetting that SOF is a zero, too, so this should actually read:

SOF|0|0|0|0|Stuff(1)|0|0|0|1|0|0|1

That's not what Transmitter 2 actually sends -- even setting aside the SOF==0 issue. TX2 has sent 5 consequtive zeroes, too, so _regardless_ of what it's next bit to be sent is, it _also_ sends a stuff bit. I.e. it'll send:

SOF|0|0|0|0|Stuff(1)|0|1|0|0|1|0|0

In other words: since the need for bit stuffing is determined only by the 4 bits sent _before_ the prospective stuff bit, not by the next bit they're planning to send afterwords, all participants on the bus have the same information about whether the next bit they'll send/see is a stuff bit or not.

If there were no differences in the past 5 ID bits, i.e. they were the same on all sending nodes, then the stuff bit, if any, will be the same for all sending nodes, too, and as such not introduce any change.

You're right, of course -- so simple! Thanks for clearing that up.

Mike

"Hans-Bernhard Broeker" schrieb im

Yes, I forgot! Thanx.

Acknowledged! Let's summarize this. The definition is:

Every bit after five consecutive bit of same polarity has to be interpretated as stuff bit. Right?

Regards, Taso

Right --- under the presumption that those five consequtive bits of same polarity are all in a part of the CAN frame that does use bit stuffing.