properties of the CAN protocol

[Kittu20]

Hello everyone,

I was recently reviewing the CAN protocol specifications document, where I came across the term "guarantee of latency time." However, I'm having difficulty understanding its precise meaning.

As far as I know, in CAN communication, a node sends a message, and all other nodes receive and decode it. But I'm unsure about what exactly the "guarantee of latency time" entails.

Could someone kindly explain this term to me? My understanding is that it may relate to the time taken to send or receive a message, but I would appreciate any clarification or insights on this topic.

Thank you for your assistance! 

[nctnico]

Sounds more like marketing wank. CAN messages have different priorities. So unless you send a message with the highest priority, a message has an unknown latency as you can't predict which other, more high priority messages are on the bus a message needs to wait for. CAN controllers typically have multiple messaging queues with different priorities and sometimes also the option to queue messages sorted by priority. With priority queuing enabled it is very possible the last message which is put into the queue, is actually send before all the other messages which are waiting in the queue.

[Kittu20]

I'm seeking clarification on the role of the RTR (Remote Transmission Request) bit in the CAN protocol.  is that it determines whether a message contains data to be transmitted or if it signifies something else. However, I'm unclear on its precise function and significance in communication between CAN nodes.

Can someone provide a detailed explanation of the RTR bit's purpose and how it influences message transmission

[Siwastaja]

It it just the marketing department's way of saying that if you send a message with highest priority ID (lowest number) in the whole bus (i.e. you prove absence of others talking at same or even higher priority), and we assume good signal integrity therefore no corruption and resending of data, then you have guaranteed latency. Which is quite obvious for such simple and low-level protocol; just like a lightswitch has guaranteed latency to the lightbulb. There is no other mechanism to latency guarantee than simplicity.

[ejeffrey]

Well there are two specific features that enable low deterministic latency.  First is that the message length is short and the clock fixed.  This means that when a node wants to transmit it is guaranteed to have an opportunity to try within a fixed and short period of time.  Second, the priority mechanism doesn't corrupt the data and allows the highest priority message to continue without interruption.

Compare to shared medium Ethernet.  Here a collision corrupts the data and both transmitters have to abort and retry.  It only guarantees progress statistically.

I2C multi master mode has similar prioriy arbitration to CAN but allows arbitrarily long messages and variable clock rate so you can't guarantee the bus will be free in a specific amount of time.

You can get deterministic latency in i2c and even Ethernet if you put enough constraints on it, such as limited message length, max utilization, and adding priority.  However with CAN those constraints are part of the standard so any off the shelf compliant CAN peripherals will comply.