한 시스템에서 다른 시스템으로 데이터를 전송하기위한 일반 프로토콜?

한 시스템에서 다른 시스템으로 정보를 전송하는 일반적인 프로토콜은 무엇입니까? 예를 들어, 다른 마이크로 컨트롤러로 보내려는 일정 시간 동안 마이크로 컨트롤러에서 일부 정보를 수집했다고 가정 해 보겠습니다. SPI 및 I2C 인터페이스에 대해 들었지만 한 방법을 다른 방법으로 사용하고 구현 방법을 잘 모르겠습니다. SPI 및 I2C 외에 일반적인 다른 방법이 있습니까? 구현 프로세스가 다른 마이크로 컨트롤러와 유사합니까? 수신 마이크로 컨트롤러에서 기본적으로 바이트 단위의 데이터를 구문 분석합니까?

SPI와 I2C는 실제로 시스템간에 데이터를 전송하는 것보다 주변 장치를 컨트롤러 또는 CPU에 연결하는 데 더 많이 사용된다는 점에서 비슷합니다. USB는 사람들이 통신 시스템으로 취급하기를 원하는 또 다른 인터페이스로, 실제로 주변 장치 연결 버스입니다.

시스템 간의 통신은 장치를 버스에 연결하는 것과 정확히 다릅니다. 버스 연결을 통해 프로세서가 장치의 레지스터를 직접 뱅킹 할 수있는 반면, 통신 인터페이스를 통해 데이터 스트림을 송수신 할 수 있습니다. 버스에 연결된 장치는 일반적으로 통신을, 정말 문제가되지 않는 반면, 장치 드라이버를 필요로 어떤 까지 호스트 컴퓨터에 관한 한, 다른 쪽 끝에 연결되어 있습니다.

물론 이것은 항상 더 위험한 경계가되고 있습니다. PCI와 ISA와 같은 것은 틀림없이 버스입니다. I2C, SPI, USB는 아마도 버스입니다. RS232, RS485 및 이더넷은 확실히 통신 인터페이스입니다. 그러나 CAN 버스 및 1553과 같은 것은 데이터 이동에 관한 것이지만 매우 관련이 있습니다.

데이터를 전송하는 한 가지 방법이 없으며 거리, 데이터 속도, 환경, 응용 프로그램에 따라 통신하는 여러 가지 방법이 있습니다 ...

가장 낮은 레이어는 실제 레이어 이며 실제로 비트를 움직입니다.

• SPI 및 I²C는 전송을 방해 할 수있는 잡음이 많지 않은 장치 내부의 단거리 용입니다.

• RS-232를 통한 최대 수십 미터 거리의 직렬 통신은 너무 빠르지 않은 통신에 적합합니다.

• 예를 들어 RS-485와 같이 노이즈가 많거나 더 긴 거리 차동 신호가 사용되는 경우. 더 빠른 데이터 전송을 위해 이더넷이 점점 더 많이 사용되고 있습니다.

• 그런 다음 다양한 무선 표준도 있습니다.

물리 계층 이외에도 전송 오류, 네트워크에서의 라우팅 및 기타 여러 가지를 감지하고 수정하기 위해 데이터 전송 방법을 구성하는 더 많은 계층이 있습니다. 예를 들어, 인터넷 프로토콜은 일반적으로 이더넷 프로토콜 위에 여러 계층의 다소 복잡한 스택입니다.

간단한 직렬 UART (별도 클록이없는 하나의 Tx 및 하나의 Rx 라인)를 사용할 수 있으며 광절 연기 또는 자기 절연기를 사용 하여 서로 다른 전위 (1 차 및 2 차 회로) 사이를 쉽게 교차하도록 조정할 수 있습니다 .

프로토콜이 진행되는 한, 정의 된 명령 바이트 및 체크섬 체계가있는 모든 것이 잘 작동합니다. 실제로 모든 유형의 통신에 적합한 포괄적 인 표준 프로토콜은 없습니다. I2C는 시그널링 표준 (어드레싱, 중지, 시작 등 정의)을 가지고 있지만 실제로 전달되는 프로토콜은 전적으로 개발자에게 달려 있습니다.

예를 들어 PMBus 는 I2C를 물리적 매체로 사용하는 전원 공급 장치 통신 프로토콜입니다.

실제로는 "일반적인"프로토콜이 없습니다. 결국 사용하는 것은 응용 프로그램에 따라 다릅니다. 더 나은 답변을 제공하기 위해서는 귀하의 요구 사항을 조금 더 이해해야합니다. 서브 시스템으로서 서로 대화하는 별도의 마이크로 컨트롤러를 갖고 싶다고 언급했습니다.

이 응용 프로그램에 대한 몇 가지 질문 :

1. 이 프로젝트에 2 개 이상의 마이크로 컨트롤러가 있습니까?
2. 속도 및 처리량 요구 사항은 무엇입니까? 정보가 얼마나 빨리 도착하고 얼마나 자주 데이터를주고 받습니까?

질문 1에 NO라고 대답 한 경우 :

이 프로젝트에 2 개의 micrco 컨트롤러 만있는 경우 UART를 확실히 사용할 수 있습니다. 둘 다 통신을 시작해야하는 경우 흐름 제어를 사용하십시오. 그렇지 않으면 한 방향으로 데이터를 전송하는 것이 쉽지 않습니다. 대부분의 경우 더 높은 전송 속도 중 하나를 선택하면 "충분히 빠릅니다". I2C 및 SPI는 일반적으로 마스터 / 슬레이브 아키텍처에만 적합합니다.

질문 1에 YES (2 개 이상의 컨트롤러)로 대답 한 경우 1

• 프로젝트에 둘 이상의 마이크로 컨트롤러가있는 경우 어느 컨트롤러가 통신을 시작합니까? 마스터 컨트롤러 만 하나입니까 (예 : 마스터-슬레이브 아키텍처)? 아니면 언제라도 서브 시스템이 말할 수 있습니까?
• 서로 통신 할 서브 시스템이 필요합니까? 예 : 장치 A, B 및 C의 경우 : A는 B와 C로, B는 A와 C로 모두 보낼 수 있습니다.

따라서 이제는 주소 지정 가능한 장치를 공통 버스에 놓을 수있는 확장 성이 뛰어난 것이 필요합니다. 이 후속 질문에 대한 답변은 I2C와 SPI (마스터-슬레이브) 또는 CAN (멀티 마스터)과 같은 것을 결정하는 데 도움이됩니다.

마이크로 컨트롤러에는 UART 주변 장치가있을 가능성이 높으며 다른 장치 (특히 CAN)는 더 높은 엔드 칩에서만 사용할 수 있습니다. 두 경우 모두 이러한 주변 장치를 사용하여 바이트를 이동하는 방법에 대한 많은 설명서가 있어야합니다.

@Jon이 지적했듯이, 통신 인터페이스를 선택할 때 한 가지 문제는 한 개체가 항상 통신을 시작해야하는지 또는 두 개 이상의 개체가 그렇게 책임을 지는지 여부입니다. 관련된 문제는 한 엔티티가 항상 원치 않는 통신을 수신 할 수 있는지 여부입니다. SPI는 한 쪽에서 항상 통신을받을 수있는 응용 프로그램에서 자주 사용됩니다. 예를 들어 74HC595 시프트 레지스터와 같은 것은 결코 "사용 중"이 아닙니다. SPI는 마이크로 컨트롤러와 마이크로가 제어해야하는 하드웨어 간의 통신에는 좋지만 실제로는 두 마이크로 컨트롤러 간의 통신에는 좋지 않습니다. I2C 하드웨어가있는 두 개의 프로세서가이를 사용하여 통신하는 경우, 소프트웨어는 매우 관대 한 제약 조건 내에서 진행중인 작업을 처리하는 데 원하는 시간이 소요될 수 있습니다. 데이터 손실을 유발하지 않습니다. 프로세서가 들어오는 각 바이트를 처리하는 데 100 마이크로 초가 걸리면 처리량이 심각하게 제한되지만 발신자가 수신자가 유지할 수있을 정도로 속도가 느려집니다. 일반적으로 SPI에서 발생할 수있는 유일한 방법은 핸드 셰이 킹을위한 별도의 와이어가있는 경우입니다.

I2C는 정말 훌륭한 프로토콜입니다. 상상할 수있는 가장 완벽한 프로토콜이되는 것을 막는 가장 큰 한계는

1. 속도는 다소 제한적입니다. SPI는 훨씬 빨라질 수 있으며 UART조차도 조금 더 빨라질 수 있습니다.
2. (2) I2C에는 두 개의 전선 만 있으면되는 것이 매우 편리하지만 두 전선 모두 양방향 오픈 컬렉터 통신이 가능해야합니다. 따라서 리피터를 통해 I2C를 전송하기가 어렵습니다.

개인적으로, 컨트롤러 벤더가 핸드 셰이 킹을 포함한 3 선 SPI 변형을 지원하고 싶습니다. 그래도 그렇게하는 컨트롤러는 알지 못합니다.

같은 순서로 2 개의 CPU에서 가장 많이 사용되는 물리 계층 인스턴스는 특별한 순서가없는 것 같습니다.

• 데이지 체인 SPI (예 : JTAG에서 사용)
• 슬레이브 당 선택 와이어 SPI
• "비동기식 스타트-스톱 직렬 통신"(일명 CPU의 UART TX 핀을 다른 CPU의 UART RX 핀에 직접 연결) "TTL 수준 RS-232"
• I2C
• 8 비트 데이터 + 스트로브 (예 : IEEE 1284 프린터 포트 병렬 포트)
• 공유 메모리 (한 번에 하나의 CPU 만 주소 / 데이터 / 제어 버스를 구동 함)

이러한 물리적 계층 인스턴스 (별도의 상자에 2 개의 CPU에 대한 다른 물리적 계층 인스턴스)는 일반적으로 높은 수준의 통신 시스템을 구현하는 바이트 스트림을 소프트웨어에 제공합니다.

스마트 프로그래머는 하드웨어 담당자가 하나의 물리적 계층 인스턴스를 제거하고 완전히 다른 물리적 계층 인스턴스로 교체하기로 결정하는 경우 출력 스트림 바이트를 공급하기 위해 몇 가지 기능 만 다시 작성하면됩니다. 하드웨어로 전송하고 하드웨어에서 바이트 스트림을 다시 읽으며 모든 상위 레벨 프로토콜 항목은 계속 변경되지 않습니다.

한 CPU에서 다른 CPU로 정보를 전송하는 프로토콜은 거의 항상 일련의 패킷으로 바이트 스트림을 해석합니다.

1. 전문
2. 머리글
3. 직렬화 된 데이터 (아마도 탈출)
4. 트레일러

어떤 사람들은 (2) 많은 종류의 헤더 구조 중 하나와 (3a) 많은 종류의 직렬화 데이터 중 하나와 (3b) 여러 종류 중 하나를 혼합하여 일치시켜 완전히 새로운 맞춤형의 호환되지 않는 프로토콜을 만드는 것을 좋아합니다. (4) 많은 종류의 트레일러 중 하나를 사용하여 직렬화 된 데이터를 탈출합니다.

데이터를 패킷으로 캡슐화하는 가장 간단한 프로토콜 중 일부는 다음과 같습니다.

• 세 바이트 미니 SSC 프로토콜
• 넷 스트링 형식

패킷으로 데이터를 캡슐화하기위한 약간 더 복잡한 프로토콜은 다음과 같습니다.

• vscp-매우 간단한 제어 프로토콜
• 직렬 연결을 통한 IP

에 프로토콜의 긴 목록이 있습니다

• 임베디드 시스템에서 사용되는 일반적인 프로토콜
• 시리얼 프로그래밍 : 데이터 패킷 형성

프로토콜 디자인이 어떻게 잘못 될 수 있는지 설명하는 Radia Perlman의 "Protocol Design Folklore" 를 읽을 수 있습니다 .

단일 '일반'프로토콜이 없습니다. 선택은 (예를 들어) 다음에 따라 달라질 수 있습니다.

• 거리
• 필요한 처리량
• 특수 주변 장치의 가용성
• 소음 수준
• 광학적 분리 필요
• 중요도 (허용 가능한 고장률)
• 양단의 가용 CPU 전원
• 양쪽 끝에 사용 가능한 I / O 핀

많은 경우 데이터 링크 계층 (데이터 인코딩 방식 +/-)에서 물리 계층 (신호 수준)을 분리해야합니다 (OSI 모델, 하위 ..4 계층 확인). 가능한 물리층은 다음과 같습니다.

• 간단한 5V 또는 3.3V 또는 1.8V TTL
• 푸시 풀 대신 위의 오픈 컬렉터 중 하나
• 균형 잡힌 전압 신호 (종종 FPGA와 함께 사용)
• 밸런스 하 이거 전압 (RS485, RS432)
• 단일 종단 고전압 (RS232)
• 균형 잡힌 트라 포 커플 링 (다양한 이더넷 버전, PDIF 오디오)
• 광학 (광 이더넷, 토 링크)

한 줄을 사용하여 데이터 및 시계 정보를 전달하거나 여러 줄로 나눌 수 있습니다. 후자는 인기가 있었지만 요즘 대부분의 새로운 / 빠른 프로토콜은 한 줄 (또는 한 줄로 작동하는 한 줄)을 사용하는 경향이 있습니다.

그것들은 데이터를 인코딩하고 한 줄에 클럭하는 많은 방법입니다. RS232는 전통적으로 NRZ를 사용하고, Machester 인코딩이 있으며, 호기심 많은 이름이 2.7 RLL 인 하드 디스크에서 다양한 형식을 사용합니다.

요약하자면 : 시스템간에 의사 소통을하는 방법은 여러 가지가 있습니다. 그리고 오류 감지 및 복구, 데이터 인코딩, 압축 및 암호화와 같은 커넥터 또는 높은 수준의 측면조차 언급하지 않았습니다 ...