시리얼 프로토콜 구분 / 동기화 기술

오늘날에도 비동기식 직렬 통신이 전자 장치에 널리 보급됨에 따라 많은 사람들이 때때로 이러한 질문에 직면했다고 생각합니다. 직렬 회선 (RS-232 또는 이와 유사한)으로 연결된 전자 장치 D와 컴퓨터를 고려하여 PC정보를 지속적으로 교환해야합니다 . 즉 , PC각 명령 프레임을 보내고 상태 보고서 / 원격 측정 프레임으로 각각 응답합니다 (보고서는 요청에 대한 응답으로 보내거나 독립적으로 중요하지 않습니다). 통신 프레임 은 임의의 이진 데이터를 포함 할 수 있습니다 . 통신 프레임이 고정 길이 패킷이라고 가정합니다.X msDY ms

문제 :

프로토콜이 연속적이므로 수신 측은 진행중인 전송 된 프레임의 중간에서 동기화를 풀거나 "결합"할 수 있으므로 프레임 시작 (SOF) 위치를 알 수 없습니다. 데이터는 SOF에 상대적인 위치에 따라 다른 의미를 가지며, 수신 된 데이터는 잠재적으로 영원히 손상됩니다.

필요한 솔루션

복구 시간이 짧은 SOF를 감지하는 안정적인 구분 / 동기화 체계 (즉, 재 동기화하는 데 1 프레임 이상 걸리지 않아야 함)

내가 알고있는 (그리고 일부를 사용하는) 기존 기술 :

1) 헤더 / 체크섬 -SOF는 미리 정의 된 바이트 값입니다. 프레임 끝의 체크섬.

• 장점 : 단순합니다.
• 단점 : 신뢰할 수 없습니다. 알 수없는 복구 시간

2) 바이트 스터핑 :

• 장점 : 모든 하드웨어에서 안정적이고 빠른 복구가 가능합니다
• 단점 : 고정 크기 프레임 기반 통신에 적합하지 않음

3) 9 비트 마킹 -각 바이트 앞에 추가 비트를 붙이고 SOF로 표시 1하고 데이터 바이트는 다음으로 표시합니다 0:

• 장점 : 안정적이고 빠른 복구
• 단점 : 하드웨어 지원이 필요합니다. 대부분의 PC하드웨어 및 소프트웨어에서 직접 지원되지 않습니다 .

4) 8 비트 마킹 -위의 에뮬레이션의 종류, 9 번째 대신 8 비트를 사용하는 경우 각 데이터 워드에 대해 7 비트 만 남습니다.

• 장점 : 모든 하드웨어에서 안정적이고 빠른 복구가 가능합니다.
• 단점 : 기존의 8 비트 표현과 7 비트 표현 사이의 인코딩 / 디코딩 체계가 필요하다. 다소 낭비입니다.

5) 타임 아웃 기반 -정의 된 유휴 시간 이후에 오는 첫 바이트로 SOF를 가정합니다.

• 장점 : 데이터 오버 헤드가없고 간단합니다.
• 단점 : 그렇게 신뢰할 수는 없습니다. Windows PC와 같은 열악한 타이밍 시스템에서는 제대로 작동하지 않습니다. 잠재적 인 처리량 오버 헤드.

질문 : 문제를 해결하기 위해 가능한 다른 기술 / 솔루션은 무엇입니까? 위의 목록에서 쉽게 해결할 수있는 단점 을 지적 하여 제거 할 수 있습니까? 시스템 프로토콜을 어떻게 설계합니까?

시스템 프로토콜을 어떻게 설계합니까?

내 경험상 모든 사람이 예상보다 통신 시스템을 디버깅하는 데 훨씬 더 많은 시간을 보냅니다. 따라서 통신 프로토콜을 선택해야 할 때마다 가능한 경우 시스템을보다 쉽게 ​​디버그 할 수있는 옵션을 선택하는 것이 좋습니다.

재미 있고 교육적인 몇 가지 맞춤형 프로토콜을 디자인하는 것이 좋습니다. 그러나 기존 프로토콜을 살펴 보시기 바랍니다. 한 곳에서 다른 곳으로 데이터를 전달해야하는 경우 다른 사람이 이미 디버깅에 많은 시간을 보냈던 기존 프로토콜을 사용하려고 매우 노력합니다.

처음부터 자신의 통신 프로토콜을 작성하면 새로운 프로토콜을 작성할 때 모든 사람이 겪는 것과 동일한 많은 일반적인 문제에 대비할 수 있습니다.

임베디드 - 컴퓨터 통신을위한 Good RS232 기반 프로토콜 에는 12 가지 임베디드 시스템 프로토콜 이 있습니다. 요구 사항에 가장 가까운 프로토콜은 무엇입니까?

어떤 상황에서 기존의 프로토콜을 정확하게 사용하는 것이 불가능하더라도 요구 사항에 거의 맞는 프로토콜로 시작한 다음 조정하면 더 빠르게 작동 할 가능성이 높습니다.

나쁜 소식

마찬가지로 나는 전에 말했다 :

불행히도, 모든 통신 프로토콜이 이러한 모든 기능을 갖추고있는 것은 불가능합니다 :

• 투명성 : 데이터 통신은 투명하고 "8 비트 클린"-(a) 가능한 모든 데이터 파일이 전송 될 수 있음, (b) 파일의 바이트 시퀀스는 항상 데이터로 처리되며 다른 것으로 잘못 해석되지 않음 ) 대상은 추가 또는 삭제없이 오류없이 전체 데이터 파일을 수신합니다.
• 단순 복사 : 변경없이 소스에서 패킷의 데이터 필드로 데이터를 맹목적으로 복사하는 경우 패킷을 만드는 것이 가장 쉽습니다.
• 고유 한 시작 : 패킷 시작 기호는 헤더, 헤더 CRC, 데이터 페이로드 또는 데이터 CRC의 다른 곳에서는 절대 발생하지 않는 알려진 상수 바이트이므로 인식하기 쉽습니다.
• 8 비트 : 8 비트 바이트 만 사용합니다.

통신 프로토콜이 이러한 모든 기능을 가질 수있는 방법이 있다면 놀랐습니다.

좋은 소식

문제를 해결하기 위해 가능한 다른 기술 / 솔루션은 무엇입니까?

텍스트 터미널의 사람이 통신 장치를 대체 할 수 있으면 디버깅이 훨씬 쉬워집니다. 이를 위해서는 프로토콜이 상대적으로 시간에 독립적으로 설계되어야합니다 (사람이 입력 한 키 스트로크 사이에서 비교적 긴 일시 정지 중에는 시간 종료되지 않음). 또한 이러한 프로토콜은 사람이 입력하고 화면에서 읽을 수있는 바이트 종류로 제한됩니다.

일부 프로토콜에서는 메시지를 "텍스트"또는 "이진"모드로 보낼 수 있습니다 (가능한 모든 바이너리 메시지에 동일한 것을 의미하는 "동등한"텍스트 메시지가 있어야 함). 이렇게하면 디버깅이 훨씬 쉬워집니다.

어떤 사람들은 인쇄 가능한 문자 만 사용하도록 프로토콜을 제한하는 것이 "폐기"한다고 생각하는 것 같지만, 디버깅 시간을 절약하면 종종 가치가 있습니다.

이미 언급했듯이 데이터 필드에 헤더 시작 및 헤더 끝 바이트를 포함하여 임의의 바이트가 포함되도록 허용하면 수신기를 처음 켤 때 수신기가 잘못 동기화 될 수 있습니다. 하나의 패킷 중간에있는 데이터 필드에서 헤더 시작 (SOH) 바이트처럼 보이는 것. 일반적으로 수신자는 의사 패킷 끝 (일반적으로 두 번째 실제 패킷의 절반에 해당) 끝에 체크섬이 일치하지 않습니다. 다음 SOH를 찾기 전에 전체 의사 메시지 (두 번째 패킷의 전반을 포함)를 단순히 버리는 것이 매우 유혹적입니다. 결과적으로 수신자는 많은 메시지와 동기화되지 않을 수 있습니다.

alex.forencich가 지적했듯이, 수신기가 버퍼의 시작 부분에서 다음 SOH까지 바이트를 버리는 것이 훨씬 더 나은 방법입니다. 이를 통해 수신자는 (데이터 패킷에서 여러 SOH 바이트를 통해 작업 한 후) 두 번째 패킷에서 즉시 동기화 할 수 있습니다.

위의 목록에서 쉽게 해결할 수있는 단점을 지적하여 제거 할 수 있습니까?

Nicholas Clark이 지적했듯이 COBS (constant -overhead byte stuffing )에는 고정 크기 프레임과 잘 작동하는 고정 오버 헤드가 있습니다.

종종 간과되는 한 가지 기술은 전용 프레임 끝 마커 바이트입니다. 수신기가 전송 도중에 켜지면 전용 프레임 끝 마커 바이트가 수신기가 더 빠르게 동기화하는 데 도움이됩니다.

패킷 중간에 수신기가 켜져 있고 패킷의 데이터 필드에 패킷의 시작 (의사 패킷의 시작) 인 것처럼 보이는 바이트가 포함되어 있으면 송신기는 일련의 삽입 할 수 있습니다. 데이터 필드의 이러한 의사 시작 패킷 바이트는 다음 패킷 을 즉시 동기화하고 올바르게 디코딩하는 데 방해가되지 않습니다. 그 의사 패킷 중 올바른 것으로 나타납니다.

행운을 빕니다.

바이트 스터핑 방식은 몇 년 동안 나에게 큰 도움이되었다. 소프트웨어 또는 하드웨어에서 구현하기 쉽기 때문에 표준 USB-UART 케이블을 사용하여 데이터 패킷을 보낼 수 있으며 걱정할 필요없이 양질의 프레임을 얻을 수 있습니다. 타임 아웃, 핫스왑 또는 이와 유사한 것

길이 바이트 (패킷 길이 모듈로 256) 및 패킷 레벨 CRC와 결합 된 바이트 스터핑 방법을 옹호 한 다음 UART를 패리티 비트와 함께 사용합니다. 길이 바이트는 삭제 된 바이트 감지를 보장하며, 이는 대부분의 UART가 패리티에 실패한 바이트를 삭제하기 때문에 패리티 비트와 잘 작동합니다. 그런 다음 패킷 수준 CRC는 추가 보안을 제공합니다.

바이트 스터핑 오버 헤드에 대해서는 COBS 프로토콜을 살펴 보셨습니까? 전송되는 254마다 1 바이트의 고정 오버 헤드 (프레이밍, CRC, LEN 등)로 바이트 스터핑을하는 천재적인 방법입니다.

https://ko.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing

옵션 # 1, SOH + 체크섬, 신뢰할 수 있으며 다음의 손상되지 않은 프레임에서 복구됩니다.

메시지 길이를 이미 알고 있거나 길이가 SOH 바로 다음 바이트로 인코딩된다고 가정합니다. 검사 바이트는 메시지 끝에 나타납니다. 또한 가장 긴 메시지만큼 긴 데이터에 대한 수신 측 버퍼가 필요합니다.

버퍼 헤드에서 SOH 바이트를 볼 때마다 잠재적으로 메시지의 시작입니다. 버퍼를 스캔하여 해당 메시지의 확인 값을 계산하고 버퍼의 확인 바이트와 일치하는지 확인하십시오. 그렇다면 완료된 것입니다. 그렇지 않으면 다음 SOH 바이트에 도달 할 때까지 버퍼에서 데이터를 버립니다.

메시지에 실제로 데이터 오류가있는 경우이 알고리즘은 메시지를 삭제하지만 어쨌든 그렇게 할 것입니다. 점검 알고리즘에 순방향 오류 정정이 포함 된 경우, 각 잠재적 메시지 정렬에서 정정 가능한 오류를 점검 할 수 있습니다.

메시지의 길이가 고정되어 있으면 SOH 바이트를 모두 사용할 수 있습니다. 유효한 모든 확인 위치에 대해 가능한 모든 시작 위치를 테스트하십시오.

검사 알고리즘을 생략하고 SOH 바이트 만 유지할 수도 있지만 이로 인해 알고리즘의 결정 성이 떨어집니다. 올바른 메시지 정렬을 위해서는 항상 메시지 시작시 SOH가 나타납니다. 정렬이 잘못되면 데이터 스트림의 다음 바이트 가 다른 SOH 일 가능성 이 낮 습니다 (메시지 데이터에 SOH가 얼마나 자주 나타나는지에 따라 다름). 이 기준으로 만 유효한 SOH 바이트를 선택할 수 있습니다. (이것은 기본적으로 T1 및 E1과 같은 동기 통신 서비스의 프레이밍이 작동하는 방식입니다.)

언급되지 않았지만 널리 사용되는 (특히 인터넷에서) 옵션은 ASCII / 텍스트 인코딩입니다 (실제로 대부분의 최신 구현에서는 UTF-8을 가정합니다). 내 경험에 따르면 하드웨어 사용자는이 작업을 싫어하지만 소프트웨어 사람들은 거의 모든 것을 선호합니다 (대부분 텍스트 기반의 모든 것을 만드는 유닉스 전통에 해당합니다).

텍스트 인코딩의 장점은 인쇄 할 수없는 문자를 프레임에 사용할 수 있다는 것입니다. 예를 들어, 가장 간단한 방법은 0x00프레임 시작 및 프레임 0xff끝 을 나타내는 것과 같은 것을 사용하는 것 입니다.

데이터가 텍스트로 인코딩되는 두 가지 주요 방법을 보았습니다.

1. 하드웨어 / 어셈블리가이 작업을 요청하면 16 진 인코딩으로 구현 될 것입니다. 이것은 단순히 바이트를 ASCII의 16 진 값으로 변환하는 것입니다. 오버 헤드가 큽니다. 기본적으로 모든 실제 데이터 바이트마다 2 바이트를 전송합니다.

2. 소프트웨어 담당자가 요청하면 base64 인코딩으로 구현 될 수 있습니다. 이것은 인터넷의 사실상의 인코딩입니다. 이메일 MIME 첨부 파일에서 URL 데이터 인코딩에 이르는 모든 것에 사용됩니다. 오버 헤드는 정확히 33 %입니다. 단순한 16 진 인코딩보다 훨씬 좋습니다.

또는 이진 데이터를 완전히 버리고 텍스트를 전송할 수 있습니다. 이 경우 가장 일반적인 기술은 데이터를 줄 바꿈 (정의 "\n"또는로 "\r\n") 으로 구분하는 것입니다 . NMEA (GPS), 모뎀 AT 명령 및 Adventech ADAM 센서가 가장 일반적인 예입니다.

이러한 모든 텍스트 기반 프로토콜 / 프레이밍에는 다음과 같은 장단점이 있습니다.

찬성:

• 쉽게 디버깅
• 스크립팅 언어로 쉽게 구현
• 하이퍼 터미널 / 미니 콤을 사용하여 하드웨어를 간단히 테스트 할 수 있습니다.
• 하드웨어에서 쉽게 구현할 수 있습니다 (PIC와 같이 아주 작은 마이크로 미터가 아닌 한)
• 고정 크기 프레임 또는 다양한 크기 일 수 있습니다.
• 예측 가능한 프레이밍 및 빠른 동기화 복구 시간 (현재 프레임의 끝에서 복구)

범죄자:

• 순수 이진 전송에 비해 매우 큰 오버 헤드 (다시 말해 텍스트 I / O는 "0"4 바이트 0x00000000 대신 1 바이트 (0x30) 전송과 같은 숫자를 "압축"할 수 있음 )
• PIC와 같은 매우 작은 마이크로에 구현하기에는 너무 깨끗하지 않습니다 (라이브러리에 sprintf()함수가 포함되어 있지 않은 한 )

나에게 개인적으로 찬반 양론은 찬반 양론을 능가합니다. 디버깅의 용이성은 5 포인트로 계산됩니다 (따라서 단일 포인트만으로도 이미 두 가지 단점을 모두 초과합니다).

그런 다음 소프트웨어 사용자가 자주 생각하지 않는 솔루션이 있습니다. 프레이밍에 대해 생각하지 않고 인코딩 된 데이터를 보냅니다.

과거에 원시 XML을 보낸 하드웨어와 인터페이스해야했습니다. XML은 모든 프레임이었습니다. 다행히도 <xml></xml>태그 별로 프레임 경계를 파악하는 것이 매우 쉽습니다 . 저에게 가장 큰 단점은 프레이밍에 둘 이상의 바이트를 사용한다는 것입니다. 또한 태그에는 속성이 포함될 수 있으므로 프레임 자체는 수정되지 않을 수 있습니다.<tag foo="bar"></tag> 따라서 프레임 시작을 찾으려면 최악의 경우 버퍼링해야합니다.

최근에 사람들이 직렬 포트에서 JSON을 보내기 시작하는 것을 보았습니다. JSON 프레임을 사용하면 추측 할 수 있습니다. 프레임을 감지 할 수 있는 "{"(또는 "[") 문자 만 있지만 데이터에도 포함되어 있습니다. 따라서 프레임을 계산하기 위해 재귀 강하 파서 (또는 적어도 중괄호 카운터)가 필요합니다. 적어도 현재 프레임이 조기에 종료되는지 "}{"또는 "]["JSON에서 불법 인지 여부를 아는 것은 사소한 일입니다. 따라서 이전 프레임이 종료되었고 새 프레임이 시작되었음을 나타냅니다.

"X 번째 비트 마킹"이라고하는 것은 데이터를 일정한 비율로 확장하는 속성을 가진 다른 코드로 일반화 할 수 있으며 일부 코드 워드는 구분 기호로 자유롭게 사용할 수 있습니다. 이러한 코드는 종종 다른 이점도 제공합니다. CD는 8 개에서 14 개의 변조를 사용 하여 각 1 사이의 최대 실행 길이를 0 비트로 보장합니다. 다른 예로는 순방향 오류 수정 블록 코드가 있습니다. 오류 감지 및 수정 정보를 인코딩하기 위해 추가 비트를 사용하는 있습니다.

언급하지 않은 다른 시스템은 칩 선택 라인과 같은 대역 외 정보를 사용하여 트랜잭션이나 패킷을 구분하는 것입니다.

또 다른 옵션은 라인 코딩 입니다. 라인 코딩은 신호를 전송하기 쉽게하는 특정 전기적 특성 (DC 밸런스 및 최대 런 길이 보장)을 제공하며 프레이밍 및 클록 동기화를위한 제어 문자를 지원합니다. 라인 코드는 모든 최신 고속 직렬 프로토콜 (10M, 100M, 1G 및 10G 이더넷, 직렬 ATA, FireWire, USB 3, PCIe 등)에 사용됩니다. 공통 라인 코드는 8b / 10b , 64b / 66b 및 128b / 130b입니다.. 프레이밍 정보를 제공하지 않고 DC 밸런스 및 클럭 동기화 만 제공하는 더 간단한 라인 코드도 있습니다. 이러한 예로는 Machester와 NRZ가 있습니다. 빠르게 동기화하려면 8b / 10b를 사용하고 싶을 것입니다. 다른 라인 코드는 서둘러 동기화하도록 설계되지 않았습니다. 위의 제품과 같은 라인 코드를 사용하려면 송수신하기 위해 사용자 정의 하드웨어를 사용해야합니다.

옵션 5의 경우 표준 RS232 직렬은 회선이 몇 바이트 동안 유휴 상태 인 경우 휴식 및 송수신을 지원해야합니다. 그러나 일부 시스템에서는이 기능이 지원되지 않을 수 있습니다.

일반적으로 가장 간단하고 신뢰할 수있는 프레이밍 방법은 길이 필드 및 간단한 CRC 또는 체크섬 루틴과 함께 옵션 1입니다. 디코딩 루틴은 간단하다 : 시작 바이트를 얻을 때까지 바이트를 버리고, 길이 필드를 읽고, 전체 프레임을 기다렸다가, 체크섬을 점검하고, 양호하다면 유지한다. 체크섬이 잘못된 경우 시작 바이트를 가져 와서 반복 할 때까지 버퍼에서 바이트 폐기를 시작하십시오. 이 기술의 주요 문제점은 실제로 프레임 바이트의 시작이 아닌 프레임 바이트의 시작을 찾는 것입니다. 이 문제를 완화하기 위해 한 가지 기술은 다른 제어 문자로 프레임 바이트의 시작과 동일한 값을 가진 바이트를 이스케이프 한 다음 이스케이프 된 바이트를 변경하여 다른 값을 갖도록하는 것입니다. 이 경우 새 제어 바이트에서도 동일한 작업을 수행해야합니다.