카드뉴스
임베디드 통신은 이름보다 연결 구조를 먼저 봐야 합니다
UART, SPI, I2C, CAN은 모두 임베디드에서 자주 나오는 통신이지만, 쓰임은 꽤 다릅니다. 처음에는 약어를 외우기보다 선 개수, 클럭 유무, 일대일 연결인지 버스 구조인지, 어느 정도 거리와 노이즈 환경을 가정하는지부터 보는 편이 좋습니다. 통신이 안 될 때도 이 기준으로 보면 문제를 좁히기 쉽습니다.
UART는 TX와 RX를 중심으로 한 비동기 직렬 통신입니다. 클럭 선을 따로 공유하지 않기 때문에 양쪽 장치의 baud rate, 데이터 비트, parity, stop bit 설정이 맞아야 합니다. 디버그 로그, GPS 모듈, 블루투스 모듈, PC 시리얼 연결처럼 단순한 일대일 통신에 자주 쓰입니다. 신호가 뒤집혀 있거나 전압 레벨이 맞지 않으면 글자가 깨지거나 아무 데이터도 보이지 않을 수 있습니다.
UART는 간단해 보이지만 디버깅 포인트가 분명합니다. TX와 RX가 교차 연결됐는지, 3.3V와 5V 레벨이 맞는지, USB-UART 변환기의 GND가 보드와 공통인지 확인해야 합니다. 로그가 깨질 때는 코드보다 baud rate와 클럭 설정을 먼저 의심하는 경우도 많습니다.
프로토콜 위의 데이터 형식도 따로 봐야 합니다. 같은 UART라도 ASCII 로그인지, 바이너리 프레임인지, 체크섬이 있는지에 따라 파싱 방식과 오류 처리 방식이 달라집니다.
SPI와 I2C는 주변장치 연결 방식이 다릅니다
SPI는 클럭, MOSI, MISO, CS 신호를 기준으로 동작하는 동기식 통신입니다. 구조가 단순하고 빠른 편이라 플래시 메모리, ADC, 디스플레이, 고속 센서에서 자주 사용됩니다. 대신 장치가 늘어나면 칩 셀렉트 선이 추가되고, CPOL/CPHA 같은 클럭 모드가 맞지 않으면 데이터가 한 비트씩 밀리거나 엉뚱하게 읽힐 수 있습니다. 로직 애널라이저로 클럭과 데이터가 동시에 맞는지 보는 습관이 중요합니다.
I2C는 SDA와 SCL 두 선으로 여러 장치를 연결하는 버스입니다. 장치를 주소로 구분하므로 배선은 간단하지만, 풀업 저항과 버스 용량의 영향을 받습니다. 온도 센서, EEPROM, RTC, IMU처럼 비교적 저속 주변장치에 많이 쓰입니다. 주소 충돌, ACK 미응답, 너무 긴 배선, 풀업 값 부적절 같은 문제가 흔하므로 데이터시트의 주소 표와 파형을 같이 확인해야 합니다.
CAN은 여러 제어기가 같은 버스에서 통신하는 구조입니다
CAN은 자동차와 산업 장비에서 자주 쓰이는 차동 버스 통신입니다. CAN_H와 CAN_L 두 선을 사용하고, 여러 노드가 같은 버스에 붙어 메시지 기반으로 데이터를 주고받습니다. 노이즈에 비교적 강하고 우선순위 중재 구조가 있어 ECU, BMS, 인버터, 모터 제어기처럼 여러 제어기가 연결되는 환경에서 많이 사용됩니다.
CAN 디버깅에서는 baud rate, 종단저항, CAN transceiver, GND 기준, 메시지 ID를 함께 봐야 합니다. 소프트웨어에서 송신 함수를 호출했는데 버스에는 아무 변화가 없다면 MCU 핀 설정뿐 아니라 트랜시버 전원과 standby 핀도 확인해야 합니다. 네 가지 통신을 구분하는 가장 실용적인 방법은 “어떤 장치를, 몇 개의 선으로, 어느 거리에서, 어떤 속도와 안정성으로 연결하려는가”를 먼저 정리하는 것입니다.
