5. 데이터 송신 (1) 데이터 프레임 (2) 리모트 프레임

 더 이상 CAN 프레임에 대해 설명하는 것을 미룰 수 없을 것 같습니다. CAN 통신에는 다음과 같은 4개의 프레임이 사용됩니다.

데이터 프레임	데이터를 송신하기 위해 사용되는 프레임.
리모트 프레임	자신 이외의 버스 상의 어떤 노드에게 데이터 프레임의 송신을 요구할 때 사용되는 프레임.
에러 프레임	버스의 에러를 검출한 노드에 의해 송신되는 프레임.
오버로드 프레임	프레임 사이의 여분의 지연을 공급하기 위해 사용되는 프레임.

 여기서 에러 프레임과 오버로드 프레임은 CAN 컨트롤러가 자신의 내부 상태를 버스 상태와 비교하여 자동으로 내보내는 것이기 때문에, 사용자는 데이터 프레임이냐 리모트 프레임이냐만 결정할 수 있습니다. 따라서 데이터 프레임과 리모트 프레임에 대해서만 자세히 알아보도록 하겠습니다. 나머지 사항들에 대한 자세한 내용은 ‘자동차 네트워크 시스템’에서 알 수 있습니다.

(1) 데이터 프레임

  데이터를 송신하기 위해 사용되는 프레임입니다. 이 프레임은 표준 식별자만 사용하는 데이터 프레임과 확장 식별자를 사용하는 데이터 프레임 2가지로 나뉘게 되고 다음과 같이 구성됩니다.

 

 리모트 프레임과 비교를 하기 위해 리모트 프레임의 구성도 추가하였습니다. 그리고 레퍼런스 매뉴얼에서 가져온 그림인데 잘못된 부분을 약간 수정했습니다. RM009 838페이지와 비교해서 보시면 될 것 같습니다.

조정	ID는 식별자를 의미하고 RTR은 Remote Transmission Request의 약자로 이 프레임이 데이터 프레임인지 리모트 프레임인지를 나타냅니다. 이 비트가 도미넌트(0)이면 데이터 프레임이고, 리세시브(1)이면 리모트 프레임입니다. IDE에서 E는 Extension의 줄임말로 이 프레임이 표준 식별자를 사용하는지(0) 확장 식별자를 사용하는지(1) 나타냅니다. CAN 버스의 신호 상태는 리세시브와 도미넌트가 있다고 했습니다. 도미넌트 비트는 리세시브 비트보다 항상 우선하고 버스 프리 상태에서 버스는 리세시브 상태입니다. 이 원리로 두개 이상의 노드가 동시에 전송을 시작 했을 경우 조정 필드에서 우선순위를 결정하게 됩니다. 자신의 출력값과 입력값이 다른 노드는 즉시 출력을 중단하고, 일치하는 노드만 출력을 계속 진행하는 방식입니다. 이 때문에 식별자는 낮을수록 우선순위가 높고, 데이터 프레임이 리모트 프레임보다 우선순위가 높습니다. 그런데 확장 식별자에는 SSR 비트가 나옵니다. SSR은 Substitute Remote Request의 약자로 확장 식별자를 사용하는 프레임에서만 사용되며 항상 리세시브(1)입니다. 이것은 우선순위 결정권을 IDE에게 먼저 넘겨주기 위해 사용됩니다. 따라서 리모트 프레임이라도 확장 식별자를 사용하는 데이터 프레임보다 우선하게 됩니다. 즉, 우선순위는 표준 데이터 프레임 > 표준 리모트 프레임 > 확장 데이터 프레임 > 확장 리모트 프레임이 됩니다. 또 한가지 IDE는 표준 식별자를 사용하는 프레임에서는 컨트롤 필드에 속하고 확장 식별자를 사용하는 프레임에서는 조정 필드에 속합니다. 하지만 표준 식별자를 사용하는 프레임끼리 비교할 대는 RTR에서 결정이 나며, 확장 식별자를 사용하는 프레임과 표준 식별자를 사용하는 프레임이 비교될 때는 표준 식별자를 사용하는 프레임의 조정이 먼저 끝나도 확장 식별자를 사용하는 프레임은 그 후에도 조정이 계속 이루어 지면서 우선권을 상실하기 때문에 표준 식별자를 사용하는 프레임의 조정 필드에 IDE가 없는 것이 문제가 되지 않습니다. 주의할 것은 식별자는 노드의 주소나 정보를 의미하지 않는다는 것입니다. 식별자는 데이터의 내용을 의미합니다. 또한 식별자는 MSB부터 전송됩니다.
컨트롤	표준 식별자를 사용하는 프레임에서는 IDE가 있지만, 핵심적인 정보는 DLC (Data Length Code)입니다. 바이트 단위로 데이터의 길이를 나타냅니다. 0부터 8까지의 값을 가질 수 있으며, DLC의 값만큼만 데이터가 전송됩니다. 즉, 데이터 필드에 4바이트를 입력했다고 해도, DLC가 3이면 3바이트만 전송됩니다.
데이터	0바이트부터 8바이트까지 데이터를 포함시킬 수 있습니다. CAN 프레임 중 유일하게 가변적입니다. 그리고 데이터는 MSB부터 전송됩니다. 밑에서 오실로스코프로 관찰한 그림에서 확인할 수 있습니다.
CRC	송신 노드가 보낸 정보와 수신 노드가 보낸 정보가 일치하는지 검사하기 위해 사용됩니다. 송신 노드가 보내는 정보의 일정 범위에 대해 CRC계산을 수행하여 프레임에 싣어 보내면, 수신 노드 또한 프레임을 수신하면서 약속된 범위에 대해 CRC 계산을 수행하고 송신 노드의 CRC와 비교하게 되는데 유튜브를 보면 쉽게 알 수 있습니다.
ACK	독특한 비트입니다. 위의 프레임 그림을 보면 이렇게 되어 있습니다. 항상 도미넌트(0) 비트이어야 한다는 의미입니다. 하지만 송신 노드는 이 비트를 리세시브(1)로 보냅니다. 아까 언급했듯이 도미넌트 비트는 리세시브 비트보다 우선합니다. 이 방법으로 ACK 비트에 대해 자신은 리세시브를 보냈는데 다른 노드가 이 프레임을 인식했다는 의미로 이 비트 타이밍에 도미넌트를 출력하여 도미넌트가 수신될 경우, 정상적으로 수신되었다고 판단하게 됩니다. 참고로 이것은 상대방 노드가 이 프레임을 수신했을 때 필터 통과 여부와는 관련이 없습니다. 즉, 상대방 노드는 일단 프레임이 제대로 수신되기만 하면 ACK 비트를 도미넌트로 만들어줍니다. 따라서 이 비트만 다른 비트들과 달리 자신이 송신한 상태와 동일한 상태가 감지될 경우에 오류로 인식합니다.

 참고로 r0, r1은 reserve의 약자로 다음 버전을 위해 예약된 프레임입니다. 제가 지금 설명하고 있는 내용은 모두 CAN 2.0B입니다. CAN 2.0A에서는 확장 식별자가 없었기 때문에 IDE 비트도 reserve였습니다. 하지만 다음 버전인 CAN 2.0B에서 사용되기 시작했습니다. 이처럼 언젠가 사용될 수 있지만 아직은 사용되지 않는 비트들을 의미합니다.

(2) 리모트 프레임

자신 이외의 버스 상의 어떤 노드에게 데이터 프레임의 송신을 요구할 때 사용되는 프레임입니다. 데이터 프레임과의 유일한 차이는 데이터 필드의 유무와 RTR 값 뿐입니다. 이때 리모트 프레임의 식별자와 나중에 송신될 데이터 프레임의 식별자는 같습니다. CAN_TDLxR 레지스터와 CAN_TDHxR 레지스터에 값을 입력해도 CAN_TIxR 레지스터의 RTR 비트를 1로 셋하여 전송하면 데이터는 전송되지 않습니다. 수신측에서도 리모트 프레임을 읽고 CAN_RLxR 레지스터와 CAN_RHxR 레지스터를 읽어와도 쓰레기값만 검출됩니다. 근데 이 쓰레기값은 규칙적으로 바뀌는데 왜 이런건지는 모르겠습니다. 또한 CAN 컨트롤러가 RTR 비트를 리세시브(1)로 수신한다고 해도, 자동으로 이 프레임을 리모트 프레임으로 인식하고 이 프레임의 식별자를 자신이가 다룬다면 그에 관련된 데이터를 데이터 프레임에 싣어 보내지 않습니다. 이것은 사용자 어플리케이션에서 수신된 프레임의 RTR 값을 확인해서 그에 맞는 처리를 직접 코드로 구성해야 합니다. HAL 드라이버에는 이에 관한 처리가 따로 없습니다. 레퍼런스 매뉴얼에는 확장 식별자을 사용하는 리모트 프레임에 대한 그림이 없는데요. 그리고 저도 오실로스코프를 사용할 때 데이터 프레임만 관찰했습니다. 하지만 확장 식별자를 사용하여 리모트 프레임을 보내본 결과 수신측에서 확장 식별자를 정확하게 인식했으므로 확장 식별자를 사용하는 리모트 프레임은 생략된 것이지 없는게 아닙니다.