최근 진행중인 한 프로젝트에서 SBC와 MCU간에 통신이 필요한 일이 있었습니다. SBC에서 GPIO를 직접 제어하기는 여러모로 제약이 있으니 MCU를 통해 액추에이터를 움직이고 센서 데이터를 받아오는것이었습니다.
항상 하던대로 NMEA와 비슷한 나름의 통신 규칙을 만들고 SBC와 MCU 양쪽에 송신 및 파싱 코드를 작성했습니다. 당장은 작동 자체는 잘 되지만, 크리티컬한 환경에서 사용하자니 점점 제가 짠 코드에 불신이 생기기 시작했습니다. 아니나다를까, 코드를 다시 들여다봤더니 sscanf()를 남발하는건 기본이고 strtok()와 함께 중간중간 박혀있는 atof(), strncpy() 등이 버퍼를 어떻게 터뜨려먹을지 전혀 상상이 되지 않았습니다.
엄청난 씽크빅으로 예외를 전부 찾고 여기저기 NULL체크하는 if문을 칠해둬야 할까.. 아니 그전에 알고리즘 강의를 더 집중해야 했었나.. 아무튼 이런 상황에서 제가 직접 통신 코드를 작성하는건 그렇게 좋은 선택지가 아니라는 것은 확실해보였습니다.
그러던중 떠오른것이 바로 직전에 리뷰했던 UNO Q였습니다. UNO Q도 SBC와 MCU의 조합인데, SBC의 파이썬 코드와 MCU의 C언어 코드가 서로 소통하기 위해 RPC라는것을 사용하고 있었습니다. SBC의 파이썬 코드에서 Bridge.call(”key”, value)를 날리면 UART로 데이터가 날아가서 MCU의 C쪽에서 미리 등록한 callback이 argument와 함께 호출되는 것이었습니다.
이거 뭔가 통신을 날로먹을 수 있는 희망이 보입니다. UNO Q쪽을 조금 더 조사해봤습니다.
NanoPB에 통신 짬때리기 (Pico-SDK + NanoPB + CRC32 + COBS)
