CAN Messages, Part II

2. The Remote Frame

Summary: “Hello everyone, can somebody please produce the data labeled X?”

요약: "모두 안녕, 누구 X라는 라벨을 가지는 데이터를 만들어줄 수 없니?"

The Remote Frame is just like the Data Frame, with two important differences:
Remote Frame은 Data Frame과 같다, 두 가지 중요한 다른점만 빼면

• it is explicitly marked as a Remote Frame (the RTR bit in the Arbitration Field is recessive), and
• Remote Frame이라고 명시적으로 표시되어 있다.(Arbitration field 의 RTR bit 가 recessive(1) 이다.)
• there is no Data Field.
• Data Field 가 없다.

The intended purpose of the Remote Frame is to solicit 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 Frame의 의도 된 목적은 해당 데이터 프레임의 전송을 요구하는 것입니다. 예를 들어, 노드 A가 중재 필드를 234로 설정 한 원격 프레임을 전송하면 올바르게 초기화 된 노드 B는 중재 필드도 234로 설정된 데이터 프레임으로 응답 할 수 있습니다.

Remote Frames can be used to implement a type of request-response type of bus traffic management. In practice, however, the Remote Frame is little used. It is also worth noting that the CAN standard does not prescribe the behaviour outlined here. Most CAN controllers can be programmed either to automatically respond to a Remote Frame, or to notify the local CPU instead.

원격 프레임은 버스 트래픽 관리의 요청 - 응답 유형의 유형을 구현하는 데 사용할 수 있습니다. 그러나 실제로는 원격 프레임은 거의 사용되지 않습니다. CAN 표준이 여기에 설명 된 동작을 규정하지 않는다는 점도 주목할 가치가 있습니다. 대부분의 CAN 컨트롤러는 원격 프레임에 자동 응답하거나 대신 로컬 CPU에 통보하도록 프로그래밍 할 수 있습니다.

There’s one catch with the Remote Frame: the Data Length Code must be set to the length of the expected response message. Otherwise the arbitration will not work.

원격 프레임에는 하나의 캐치가 있습니다. 데이터 길이 코드는 예상 응답 메시지의 길이로 설정되어야합니다. 그렇지 않으면 중재가 작동하지 않습니다.

Sometimes it is claimed that the node responding to the Remote Frame is starting its transmission as soon as the identifier is recognized, thereby “filling up” the empty Remote Frame. This is not the case.

때로는 원격 프레임에 응답하는 노드가 식별자가 인식되는 즉시 전송을 시작하여 빈 원격 프레임을 "채우는"것으로 주장됩니다. 그렇지 않다.

A Remote Frame (2.0A type):

3. 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. It is transmitted when a node detects a fault and will cause all other nodes to detect a fault – so they will send Error Frames, too. The transmitter will then automatically try to retransmit the message. There is an elaborate scheme of error counters that ensures that a node can’t destroy the bus traffic by repeatedly transmitting Error Frames.

간단히 말해, 오류 프레임은 CAN 메시지의 프레이밍 규칙을 위반하는 특수 메시지입니다. 노드가 오류를 감지하면 다른 모든 노드가 오류를 감지하여 전송되므로 오류 프레임도 전송됩니다. 그러면 송신기는 자동으로 메시지를 재전송합니다. 노드가 오류 프레임을 반복적으로 전송하여 버스 트래픽을 파괴 할 수 없도록 보장하는 정교한 오류 카운터 체계가 있습니다.

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 Error Delimiter provides some space in which the other nodes on the bus can send their Error Flags when they detect the first Error Flag.

오류 프레임은 6 비트의 동일한 값 (따라서 비트 스터핑 규칙 위반) 인 오류 플래그와 8 개의 리세 시브 비트 인 오류 구분 기호로 구성됩니다. 오류 구분 기호는 버스의 다른 노드가 첫 번째 오류 플래그를 감지 할 때 오류 플래그를 보낼 수있는 공간을 제공합니다.

Here’s the Error Frame:

4. The Overload Frame

Summary: “I’m a very busy little 82526, could you please wait for a moment?”
요약: "난 정말 바쁜 82526(지금은 폐기된 controller), 잠깐 기다려 줄 수 있겠니?"

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. In fact, the only controller that will generate Overload Frames is the now obsolete 82526.

오버로드 프레임은 여기에 완전성을 위해 언급되었습니다. 형식과 관련하여 오류 프레임과 매우 유사하며 너무 바쁜 노드에서 전송합니다. 오버로드 프레임은 오늘날 사용되는 CAN 컨트롤러가 사용하기에 충분히 영리하기 때문에 자주 사용되지 않습니다. 실제로 오버로드 프레임을 생성하는 컨트롤러는 현재 폐기 된 82526입니다.

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. To differentiate between the two frame types, a reserved bit in the Control Field was used.

본래, CAN 표준은 중재 필드의 식별자 길이를 11 비트로 정의했습니다. 나중에 고객 요구가 표준의 확장을 요구했습니다. 새로운 형식은 확장 CAN (Extended CAN)이라고도하며 식별자에 29 비트 이상 허용합니다. 두 프레임 유형을 구별하기 위해 제어 필드의 예약 된 비트가 사용되었습니다.

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 (but see below.)
• 1.x refers to the original specification and its revisions.

New CAN controllers today are usually of the 2.0B type. A 1.x or 2.0A type controller will get very upset if it receives messages with 29 arbitration bits. A 2.0B passive type controller will tolerate them, acknowledge them if they are correct and then – discard them; a 2.0B active type controller can both transmit and receive them.

오늘날 새로운 CAN 컨트롤러는 일반적으로 2.0B 유형입니다. 1.x 또는 2.0A 유형 제어기는 29 개의 조정 비트가있는 메시지를 수신하면 매우 혼란 스럽습니다. 2.0B 패시브 타입 컨트롤러는이를 허용하고, 올바른지 확인한 후 폐기합니다. 2.0B 능동형 컨트롤러는 이들을 송수신 할 수 있습니다.

Controllers implementing 2.0B and 2.0A (and 1.x) are compatible – and may be used on the same bus – as long as the controllers implementing 2.0B refrain from sending extended frames!

2.0B 및 2.0A (및 1.x)를 구현하는 컨트롤러는 2.0B를 구현하는 컨트롤러가 확장 된 프레임을 보내지 않는 한 호환 가능하며 동일한 버스에서 사용할 수 있습니다!

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.

종종 사람들은 확장 CAN 메시지에 더 많은 오버 헤드가 있기 때문에 표준 CAN이 확장 CAN보다 "더 우수"하다고 주장합니다. 이것은 반드시 사실 일 필요는 없습니다. 중재 필드를 사용하여 데이터를 전송하는 경우 확장 CAN은 실제로 표준 CAN보다 낮은 오버 헤드를 가질 수 있습니다.