CAN Messages

The Remote Frame

Summary: “Hello everyone, can somebody please produce the data labeled X?”
The Remote Frame is just like the Data Frame, with two important differences:

• it is explicitly marked as a Remote Frame (the RTR bit in the Arbitration Field is recessive), and
• there is no Data Field.

The intended purpose of the Remote Frame is to the transmission of the corresponding Data Frame. If, say, node A transmits a Remote Frame with the Arbitration Field set to 234, then node B, if properly initialized, might respond with a Data Frame with the Arbitration Field also set to 234.

Remote Frames can be used to implement a type of request-response type of bus traffic management.

The Error Frame

Summary: (everyone, aloud) “OH DEAR, LET’S TRY AGAIN”
Simply put, the Error Frame is a special message that violates the framing rules of a CAN message.
The Error Frame consists of an Error Flag, which is 6 bits of the same value (thus violating the bit-stuffing rule) and an Error Delimiter, which is 8 recessive bits.

The Overload Frame

Summary: “I’m a very busy little 82526, could you please wait for a moment?”
The Overload Frame is mentioned here just for completeness. It is very similar to the Error Frame with regard to the format and it is transmitted by a node that becomes too busy. The Overload Frame is not used very often, as today’s CAN controllers are clever enough not to use it.

Standard vs. Extended CAN

Originally, the CAN standard defined the length of the Identifier in the Arbitration Field to eleven (11) bits. Later on, customer demand forced an extension of the standard. The new format is often called Extended CAN and allows no less than twenty-nine (29) bits in the Identifier.

Sometimes people advocate that standard CAN is “better” than Extended CAN because there is more overhead in the Extended CAN messages. This is not necessarily true. If you use the Arbitration Field for transmitting data, then Extended CAN may actually have a lower overhead than Standard CAN has.

The standards are formally called

• 2.0A, with 11-bit Identifiers only,
• 2.0B, extended version with the full 29-bit Identifiers (or the 11-bit, you can mix them.) A 2.0B node can be
  • “2.0B active”, i.e. it can transmit and receive extended frames, or
  • “2.0B passive”, i.e. it will silently discard received extended frames.