주말 작업실에서 I2C 통신 LCD가 멈췄던 날
주말 작업대에서 LCD가 멈춘 순간
처음에는 코드 문제가 아니라고 믿었습니다
토요일 오후, 작은 온습도 기록 장치를 만들려고 아두이노에 I2C LCD와 온습도 센서를 함께 연결했습니다. 배선은 단순해 보였고, 예제 코드도 이미 여러 번 써본 형태라서 금방 끝날 줄 알았습니다. 그런데 전원을 넣자 LCD 첫 줄에 글자가 반쯤 뜬 채로 멈추고, 시리얼 모니터에는 센서 값이 한 번만 찍힌 뒤 더 이상 갱신되지 않았습니다.
이럴 때 가장 먼저 의심하게 되는 것은 라이브러리입니다. 저도 처음에는 LiquidCrystal_I2C 버전, Wire.begin 위치, delay 값을 바꿔 보았습니다. 하지만 실제 원인은 코드보다 훨씬 손에 잡히는 곳, 즉 I2C 통신 배선과 전원 안정성에 있었습니다.
아두이노 자체가 어떤 보드인지 다시 확인하고 싶다면 아두이노의 기본 개념을 먼저 훑어보는 것도 좋습니다. 보드가 쉬워 보인다고 해서 통신 버스까지 항상 쉬운 것은 아니기 때문입니다.
- 증상 1: LCD 백라이트는 켜지지만 글자가 일부만 표시되었습니다.
- 증상 2: 센서 값은 첫 측정 이후 갱신되지 않았습니다.
- 증상 3: 리셋 버튼을 누르면 다시 한두 번 동작하다가 멈췄습니다.
- 증상 4: USB 포트를 바꾸면 동작 시간이 조금 달라졌습니다.
팁: I2C 장치가 가끔만 동작한다면 코드보다 먼저 전원, GND 공통, SDA/SCL 접촉 상태를 확인하는 편이 빠릅니다.
책상 위 배선이 짧아도 I2C 통신은 흔들렸습니다
브레드보드에서는 접촉 불량이 생각보다 자주 납니다
제가 쓴 구성은 아두이노 우노, 1602 I2C LCD, 온습도 센서 모듈, 30cm 점퍼선 네 가닥이었습니다. 회로도만 보면 VCC, GND, SDA, SCL 네 줄이면 끝입니다. 하지만 실제 작업대에서는 점퍼선이 느슨하게 꽂히거나, LCD 백팩 핀이 살짝 들려 있거나, 센서 모듈의 전원선이 브레드보드 레일에서 반 칸 어긋나는 일이 쉽게 생깁니다.
특히 I2C 통신은 여러 장치가 같은 두 선을 공유하기 때문에 한 장치의 접촉 상태가 나쁘면 전체 버스가 같이 흔들립니다. LCD만 이상한 줄 알았는데 센서까지 멈춘 이유도 여기에 있었습니다. 장치 하나가 SDA 선을 제대로 놓지 못하면 마이크로컨트롤러 입장에서는 다음 대화를 시작하기 어렵습니다.
저는 처음에 점퍼선을 모두 새것으로 바꾸고, 브레드보드 전원 레일을 멀티미터로 찍어 보았습니다. 5V라고 믿고 있던 지점이 LCD 백라이트가 켜질 때 순간적으로 내려가는 것을 보고 나서야, 문제를 소프트웨어가 아니라 회로 쪽으로 돌려볼 수 있었습니다.
- 짧은 배선도 안심 금지: 10cm 안팎의 점퍼선이라도 접촉이 헐거우면 클럭 신호가 깨질 수 있습니다.
- 브레드보드 레일 확인: 일부 브레드보드는 전원 레일이 중간에서 끊겨 있어 별도 연결이 필요합니다.
- GND 공통 확인: 센서와 LCD, 보드의 기준점이 다르면 정상 주소를 찾아도 값이 이상하게 나옵니다.
- 전원 여유 확인: LCD 백라이트, 센서 히터, 무선 모듈을 함께 쓰면 USB 전원만으로 부족할 수 있습니다.
주소 스캔은 출발점일 뿐이었습니다
I2C 주소 스캐너를 돌렸을 때 LCD 주소 0x27, 센서 주소 0x44가 잘 잡혔습니다. 그래서 처음에는 주소 충돌이 아니라고 판단했습니다. 하지만 주소가 보인다는 사실은 장치가 완전히 안정적으로 통신한다는 뜻은 아니었습니다.
실제로 제 경우 주소 스캐너는 성공했지만, LCD에 문자열을 계속 쓰고 센서 값을 반복해서 읽는 순간 오류가 났습니다. 짧은 인사만 하는 것과 계속 대화하는 것은 다릅니다. 프로젝트 단계에서는 주소 확인 다음에 반복 읽기, 화면 갱신, 장시간 전원 유지까지 확인해야 합니다.
- 주소 스캐너로 장치가 보이는지 확인합니다.
- 각 장치를 하나씩 단독 연결해 5분 이상 반복 테스트합니다.
- 두 장치를 함께 연결한 뒤 LCD 갱신 주기를 늦춰 봅니다.
- USB 전원과 외부 전원을 바꿔 증상 차이를 비교합니다.
제가 실제로 효과를 본 수정 순서
풀업 저항보다 먼저 본 것은 전원과 갱신 주기였습니다
검색을 하다 보면 I2C 문제의 답으로 풀업 저항이 자주 나옵니다. 물론 맞는 말입니다. 하지만 모듈형 LCD와 센서에는 이미 풀업 저항이 붙어 있는 경우가 많아, 무작정 저항을 추가하면 오히려 버스가 무거워질 수 있습니다. 저는 먼저 전원, 배선 길이, 코드의 갱신 주기를 조정했습니다.
가장 효과가 컸던 것은 LCD를 너무 자주 지우지 않는 것이었습니다. loop 안에서 lcd.clear()를 반복 호출하니 화면이 깜박이는 수준을 넘어 통신이 불안정해졌습니다. 표시 내용이 바뀔 때만 특정 위치에 덮어 쓰도록 바꾸자 멈춤 빈도가 크게 줄었습니다.
임베디드 개발에서는 보드와 주변 장치 사이의 소프트웨어 계층도 중요합니다. 관련 개념을 넓게 보려면 디바이스 드라이버 통합개발환경의 개요처럼 장치 제어 구조를 설명한 자료도 도움이 됩니다. 작은 아두이노 프로젝트라도 결국은 하드웨어와 코드가 맞물려 움직입니다.
- 1순위: VCC와 GND를 다시 꽂고, 가능하면 납땜된 모듈 핀 상태를 확인했습니다.
- 2순위: LCD 갱신 간격을 200ms 단위에서 1초 이상으로 늘렸습니다.
- 3순위: lcd.clear() 대신 cursor 이동 후 필요한 글자만 다시 출력했습니다.
- 4순위: 센서 읽기 실패 시 바로 멈추지 않고 한 번 건너뛰도록 예외 처리를 넣었습니다.
- 5순위: 모듈에 이미 풀업이 있는지 확인한 뒤 추가 저항 여부를 판단했습니다.
현장 팁: 화면 표시 장치는 사람이 보기 위한 속도만 맞추면 됩니다. 센서를 10번 읽는 동안 LCD는 1번만 갱신해도 충분한 경우가 많습니다.
작은 표를 만들어 보니 원인이 더 빨리 보였습니다
그날 이후 저는 I2C 센서 연결을 할 때마다 간단한 기록표를 남깁니다. 대단한 문서가 아니라, 어떤 전원에서 몇 분 동안 버텼는지 적는 정도입니다. 그런데 이 습관이 꽤 유용했습니다. 나중에 같은 증상이 나왔을 때 기억에 기대지 않고 이전 값을 바로 비교할 수 있었기 때문입니다.
아래 표는 제가 실제로 작업하면서 적었던 형식을 조금 다듬은 것입니다. 프로젝트가 커질수록 이런 기록이 디버깅 시간을 줄여 줍니다.
- USB 전원만 사용: LCD와 센서 1개는 동작했지만, 백라이트 밝기를 높이면 간헐적으로 멈췄습니다.
- 외부 5V 전원 사용: 표시 안정성은 좋아졌지만 GND 공통을 빼먹으면 센서 값이 튀었습니다.
- LCD 갱신 1초 간격: 체감상 화면은 충분히 자연스럽고 멈춤이 줄었습니다.
- LCD 갱신 100ms 간격: 보기에도 산만하고 통신 오류 가능성이 높아졌습니다.
라즈베리파이로 옮길 때 달라진 부분
3.3V 기준을 놓치면 센서 연결이 위험해집니다
같은 회로를 라즈베리파이로 옮기면 또 다른 문제가 생깁니다. 아두이노 우노에서는 5V 기준으로 자연스럽게 연결하던 모듈이, 라즈베리파이에서는 3.3V 로직과 맞지 않을 수 있습니다. 특히 SDA와 SCL에 5V가 걸리는 모듈을 그대로 연결하는 것은 조심해야 합니다.
저는 테스트용으로 레벨 시프터를 넣고, 라즈베리파이의 i2cdetect 명령으로 장치를 확인했습니다. 여기서도 주소가 보인다고 끝은 아니었습니다. 파이에서는 운영체제, 파이썬 라이브러리, 권한 설정, 버스 번호가 함께 얽히기 때문에 아두이노보다 점검 지점이 조금 더 많았습니다.
사물인터넷 프로젝트 관점에서는 단순히 값이 찍히는 것보다 데이터가 어떻게 쌓이고 활용되는지도 중요합니다. 생활 기록이나 기기 데이터 흐름을 이해할 때는 라이프로그 서비스 설명처럼 센서 데이터가 서비스로 이어지는 맥락도 참고할 만합니다.
- 전압 확인: 라즈베리파이 GPIO는 3.3V 기준이므로 5V 풀업 모듈은 바로 꽂지 않았습니다.
- 버스 활성화: 설정에서 I2C 인터페이스가 켜져 있는지 확인했습니다.
- 주소 확인: i2cdetect 결과가 매번 같은지 반복해서 보았습니다.
- 권한 문제: 파이썬 스크립트 실행 계정이 I2C 장치에 접근 가능한지 확인했습니다.
시간이 지나면 보드와 모듈 선택 기준도 바뀝니다
지금 작업대에서 쓰는 센서 모듈이 몇 달 뒤에도 최선이라는 보장은 없습니다. 같은 온습도 센서라도 새 리비전에서는 풀업 구성, 전원 허용 범위, 라이브러리 지원 상태가 달라질 수 있습니다. 그래서 저는 부품을 살 때 가격만 보지 않고 데이터시트 날짜, 판매 페이지의 회로 사진, 최근 라이브러리 업데이트 여부를 함께 봅니다.
가격대도 계속 달라집니다. 입문용 I2C LCD나 기본 센서 모듈은 부담이 적지만, 정밀 환경 센서나 산업용 센서는 단가가 훨씬 올라갑니다. 취미 프로젝트라면 저렴한 모듈로 충분할 때가 많지만, 장시간 켜 두는 사물인터넷 장치라면 안정성이 비용보다 더 중요해지는 순간이 옵니다.
- 새로 살 때: 같은 칩 이름이라도 보드 설계가 다른 제품인지 확인합니다.
- 재사용할 때: 예전에 되던 모듈이라도 납땜 균열과 핀 산화를 먼저 봅니다.
- 라이브러리 선택: 최근까지 관리되는 저장소인지 확인하고 예제 코드 날짜를 봅니다.
- 장기 설치: 점퍼선 대신 커넥터, 납땜, 케이블 고정을 고려합니다.
주말의 작은 먹통 사건 덕분에 제 작업 순서는 꽤 달라졌습니다. 이제는 I2C 장치를 꽂자마자 코드부터 고치지 않습니다. 전원, 접지, 갱신 주기, 전압 기준을 먼저 보고, 그다음에 라이브러리와 로직을 손봅니다. 부품과 보드 생태계가 계속 바뀌는 만큼, 다음 프로젝트에서는 같은 증상이라도 다른 원인이 숨어 있을 수 있다는 점을 염두에 두는 편이 좋습니다.

- 이전글I2C 센서 연결 예산은 보드보다 검증비가 좌우한다 26.10.14
- 다음글I2C 통신 주소만 알면 끝이라는 착각이 회로를 멈춘다 26.10.12
등록된 댓글이 없습니다.
