내가 겪었던 수많은 시행착오들을 적어본다.
납땜 불량
보통 납땜을 할 땐 주의를 기울여서 하기 때문에 납땜을 잘못해서 문제가 생기는 일은 별로 없다.
내 경우에는 오히려 납땜을 해야하는데 납땜을 하지 않아서 문제가 생겼다.
몇몇 SBC나 센서모듈을 보면 아래 그림처럼 핀이 보드에 강하게 결속되게 나오는 제품이 있다.
납땜을 하지 않고도 사용할 수 있게끔 배려를 해놓았구나 생각하면서 사용하고 있었는데
알고보니 몇몇 핀들에서 접촉불량이 발생했었다.
이런 경우 반드시 납땜을 해줘야 한다.
참고로 납땜은 아래처럼 하는게 편하다.
보드 아랫면에서 핀을 넣어 납땜하는게 편하다는 말이다.
케이블 불량
점퍼 케이블이 불량일 일은 거의 없고, 데이터 및 파워 케이블의 불량에 대한 것이다.
데이터 전송 기능이 없는 USB로 펌웨어를 굽는다든가
AWG(전선굵기)가 높아서(얇아서) 필요한 전류량만큼 못끌어썼다든가 (흔히 스께아가 낮다고도 한다)
Modbus 커넥터에 케이블이 잘 안꽂혔거나 단선돼서 불량이 생겼다든가 하는 이슈이다.
통신이 안되길래 소프트웨어 문제인가 열심히 확인해봤는데 알고보니 단선이 되어있었다는 슬픈 이야기
라이브러리 불량
믿기 힘들지만 가끔 라이브러리가 불량일 때도 있다.
예를들어 paho의 MQTT 라이브러리가 그랬다.
라이브러리에서 제공하는 함수에서 커널 패닉을 일으켜서 한참 고민했었는데
알고보니 라이브러리 자체가 문제임을 확인했던 적이 있다.
라이브러리의 버전 문제도 있을 수 있다.
버그픽스가 적용되지 않은 라이브러리를 사용한 경우 피똥을 싸게된다.
데이터시트 이해 부족
가장 억울하고 짜증나는 부분이다.
예를들어 DS3231 RTC 모듈이 그랬다.
타이머(알람) 인터럽트가 발생하지 않아 한참을 앓다가
기존에 발생했던 알람 레지스터를 리셋하지 않으면 다음 인터럽트가 발생하지 않는다는 데이터시트에 쓰여있지도 않은 사실을 깨닫게 됐다.
가장 화가 나는 경우는
위의 네 가지 경우가 한번에 찾아오는 경우이다.
그럴 땐 조용히 유서를 쓰면 된다.
농담이고, 낮은 곳부터 유닛 테스트를 수행하면서 하나씩 클리어해가면 어느샌가 고쳐져 있을 것이다.
네트워크 디버깅과 마찬가지로 OSI 밑바닥부터 차근차근 올라가면 된다.
하드웨어부터 확인하고 테스터기로 찍어본 후에야 소프트웨어로 넘어가서 유닛 테스트를 진행하면 된다.
순서를 안정하고 이것저것 찔러보다가는 며칠째 ‘왜 안되지?’만 반복하다가 자살하게 된다.