My experience matches the first part of that but not the second! I use a CAN bus with the MCP2515 chips, and I'm running someone's library on an Arduino. I got it wired per directions, installed some code from the library examples folder, and away it went.

This came after a long period when I was using an RS485 network. It was perfectly reliable, but I spent a lot of programming hours ensuring that it would work properly, with the main issue being the question of when a particular node was authorized to transmit. It's impossible to have a true peer-to-peer system with RS485, where there doesn't have to be any kind of master unit directing events. Whereas with CAN, each processor can act as if it has the right to transmit any time it wants. That's why I say there's magic which you don't need to understand--in fact priority is being sorted out, but you can just let it happen.

Another drawback with RS485 in a party-line application is that every processor has to read every byte, in order to decide whether it's being addressed. That leads to a lot of interrupts! On a CAN network, processors are only interrupted if there's a complete message, and even beyond that, the external hardware can filter incoming messages and only alert the processor if it's something that an individual node needs. The amount of hassle involved in using CAN is comparatively very small.

I wrote my own code from the processor manual (Renesas RA4m1), and in the process discovered a bug in the CAN hardware. No - it can’t deal with mixed 11 bit and 29 bit headers.

 

I wrote my own code from the processor manual (Renesas RA4m1), and in the process discovered a bug in the CAN hardware. No - it can’t deal with mixed 11 bit and 29 bit headers.

I have to admit we never even tried that, but at the same time I'm not sure I would consider it a bug. I don't remember if there was anything in the Bosch specification that suggested such a thing was possible.

 

I have to admit we never even tried that, but at the same time I'm not sure I would consider it a bug. I don't remember if there was anything in the Bosch specification that suggested such a thing was possible.

I wouldn’t have done it either, as it sounds like a daft thing to do. If you need 29-bit headers, then you need 29-bit headers all round.
BUt Renesas says its processor can deal with mixed, and it can’t.

 

I wouldn’t have done it either, as it sounds like a daft thing to do. If you need 29-bit headers, then you need 29-bit headers all round.
BUt Renesas says its processor can deal with mixed, and it can’t.

Did you consult the Bosh CAN specification on the matter? I used to have a paper copy, but it went walkabout pre-retirement.

 

The ERROR frame itself creates a bit stuffing error for every node with an active receiver, because it is six consecutive dominant bits. Every node that receives an ERROR frame will also generate an error frame.

One thing I'm still confused about is the Active Error Flag.

An Active Error Flag consists of six consecutive dominant bits, which would normally violate the bit stuffing rule.

Does the bit stuffing rule apply only to normal CAN frames, It is not applied to the Active Error. Or is there another mechanism that allows every node to recognize those six dominant bits as an Active Error

 

One thing I'm still confused about is the Active Error Flag.

An Active Error Flag consists of six consecutive dominant bits, which would normally violate the bit stuffing rule.

Does the bit stuffing rule apply only to normal CAN frames, It is not applied to the Active Error. Or is there another mechanism that allows every node to recognize those six dominant bits as an Active Error

The first Active Error Frame violates the bit stuffing rule and causes a cascade of ERROR Frames, both active and Passive until each node on the network has had a say. The ERROR frame cascade subsides and the transmitter that threw the first ERROR frame will retry the busted transmission.

 

I would like to thank all who contributed to the above discussion. It has been most enlightening for me.

 

If you want a lucid explanation of CAN bus, watch this video:

He covers it very thoroughly, but be warned that he talks fast!

 

I think this is the part where I'm getting confused.

Let's say there are three nodes: A, B, and C.

Node A is transmitting a frame. While transmitting, it detects a bit error, so it immediately sends an Active Error Flag.

Now B and C receive those six dominant bits.

My confusion is, under normal communication, six consecutive dominant bits would be a bit stuffing error. So what do B and C actually see? Do they first detect a bit stuffing error and then send their own Error Flags, or do they somehow recognize that these six dominant bits are already an Active Error Flag?

The reason I'm asking is that if B and C simply treat it as another bit stuffing error, it feels like every Error Flag would trigger another Error Flag, and I can't see how that sequence ever ends. That's the part I'm not able to picture.

 

I think this is the part where I'm getting confused.

Let's say there are three nodes: A, B, and C.

Node A is transmitting a frame. While transmitting, it detects a bit error, so it immediately sends an Active Error Flag.

Now B and C receive those six dominant bits.

My confusion is, under normal communication, six consecutive dominant bits would be a bit stuffing error. So what do B and C actually see? Do they first detect a bit stuffing error and then send their own Error Flags, or do they somehow recognize that these six dominant bits are already an Active Error Flag?

The reason I'm asking is that if B and C simply treat it as another bit stuffing error, it feels like every Error Flag would trigger another Error Flag, and I can't see how that sequence ever ends. That's the part I'm not able to picture.

It doesn't really matter whether nodes B & C detect the first error or the ERROR active frame from node A. Each of them will transmit one and only one ERROR flag, active or passive and then go idle waiting for new frames from whatever source.

 

It doesn't really matter whether nodes B & C detect the first error or the ERROR active frame from node A. Each of them will transmit one and only one ERROR flag, active or passive and then go idle waiting for new frames from whatever source.

So, transmitting node can detect errors such as bit errors and ACK errors and receiving nodes can detect errors such as CRC errors and bit stuffing errors.

One thing I'm still not completely clear about is the ACK field. I'm trying to relate the protocol to what I would actually observe on the physical bus.

I think that the transmitter always sends a recessive bit in the ACK slot. If at least one receiver has received the frame correctly, it send dominant bit, overriding the transmitter's recessive bit.

What I'm confused about is what we would actually see on a CAN bus waveform or logic analyzer?

During the ACK slot, would we first see the transmitter's recessive bit and then the receiver changing it to dominant, or would the bus simply appear dominant for the entire ACK slot?

 

So, transmitting node can detect errors such as bit errors and ACK errors and receiving nodes can detect errors such as CRC errors and bit stuffing errors.

One thing I'm still not completely clear about is the ACK field. I'm trying to relate the protocol to what I would actually observe on the physical bus.

I think that the transmitter always sends a recessive bit in the ACK slot. If at least one receiver has received the frame correctly, it send dominant bit, overriding the transmitter's recessive bit.

What I'm confused about is what we would actually see on a CAN bus waveform or logic analyzer?

During the ACK slot, would we first see the transmitter's recessive bit and then the receiver changing it to dominant, or would the bus simply appear dominant for the entire ACK slot?

It would appear mostly dominant, there would be a delay on he leading edge dependent on the distance the signal has to travel.
Also the dominant voltage will probably be different, as it has probably come from a different driver which maybe had a different supply voltage and different output transistors.

 

So, transmitting node can detect errors such as bit errors and ACK errors and receiving nodes can detect errors such as CRC errors and bit stuffing errors.

One thing I'm still not completely clear about is the ACK field. I'm trying to relate the protocol to what I would actually observe on the physical bus.

I think that the transmitter always sends a recessive bit in the ACK slot. If at least one receiver has received the frame correctly, it send dominant bit, overriding the transmitter's recessive bit.

What I'm confused about is what we would actually see on a CAN bus waveform or logic analyzer?

During the ACK slot, would we first see the transmitter's recessive bit and then the receiver changing it to dominant, or would the bus simply appear dominant for the entire ACK slot?

If there is any difference at all it would be a small fraction of a bit time like approximately one period of the high-speed clock. If you can do the experiment and determine the answer, I'd be interested in the result.