LabHub
배우기 러닝패스 코스

냉장고가 255°C라고 우긴다 · 고장 난 읽기가 마지막 표본을 덮었다 · 이론

고장 난 읽기가 마지막 표본을 덮었다

LabHub 에서 이어서 보기

한 줄 요약

드라이버는 정상 온도를 반환하는 함수가 아니라 실패할 때 무엇을 바꾸지 않을지도 정하는 경계입니다.

왜 이게 필요했나

전송 함수가 실패했는데 버퍼 첫 바이트는 바뀌었습니다. 이전 값과 새 값이 섞이면 그럴듯하지만 존재한 적 없는 온도가 됩니다. 에러 코드만 검사하는 것과 실패 결과를 사용자에게 공개하지 않는 것은 다른 일입니다. 작업용 버퍼에서 변환과 검증을 끝내고 성공 경로의 마지막에서 표본을 갱신합니다.

이번 실습은 실제 C 컴파일러로 여러분의 드라이버를 실행하지만 I2C 선에 전압을 걸지는 않습니다. 하드웨어 추상화 계층인 HAL을 함수 포인터 묶음으로 제공합니다. ctx는 모델의 상태를 가리키고 transfer·now_ms·recover가 그 상태를 사용합니다. 학생은 모델의 내부를 고치지 않고 이 공개 인터페이스로만 통신합니다.

어떻게 동작하나

주소는 0x48~0x4b의 7비트 값으로 전달합니다. R/W 비트를 붙이려고 왼쪽으로 한 번 더 미는 것은 이 HAL 계약에서는 잘못입니다. 실제 드라이버 라이브러리를 옮길 때도 인자가 7비트 주소인지 전송용 주소 바이트인지 문서를 먼저 확인해야 합니다.

한 번의 transfer 호출에 포인터 0x00 한 바이트 쓰기와 두 바이트 읽기를 같이 넘깁니다. 실제 버스의 반복 START·마지막 읽기 NACK·STOP은 HAL의 책임으로 둡니다. 이 수업의 검사기는 결합 호출의 주소·길이·포인터·기한을 검증하지 전기적 파형을 측정하지 않습니다. 센서 데이터시트와 HAL API 계약은 서로 다른 문서입니다.

오류 정책도 명시합니다. SENSOR_NACK는 전송 실패 상태이고 마지막 읽기 바이트에 제어기가 보내는 정상 NACK 신호와 같은 뜻으로 쓰지 않습니다. SENSOR_SHORT는 필요한 바이트를 모두 얻지 못했다는 뜻입니다. 이 두 상태와 형식 오류는 재시도하지 않습니다. SENSOR_BUS만 한 번 recover한 뒤 한 번 다시 읽습니다. 재시도도 실패하면 그대로 종료합니다. 모든 오류를 무한 재시도하는 구현은 잘못된 주소를 고치지도 못하면서 호출자를 붙잡습니다.

모델의 recover는 걸린 상태를 초기화합니다. SCL을 아홉 번 토글하거나 전원을 껐다 켜는 동작을 대신했다고 주장할 수 없습니다. 실물 복구는 버스 구성과 부품 규격에 맞춰 별도로 설계해야 합니다. 여기서는 복구가 실제 상태를 바꿔야 다음 전송이 성공하도록 모델을 만들어, 함수 이름만 호출하고 결과를 무시하는 실수를 구별합니다.

현장에서 만나는 모습

2026-09-10 확인한 Orion Sleep의 공식 임베디드 엔지니어 공고에는 C/C++, 하드웨어 인터페이스, 제한된 자원에서의 디버깅과 시험 체계가 함께 나옵니다. 이번 코스는 그 중 드라이버 계약과 재현 시험을 연습합니다. 하나의 해외 시니어 공고를 국내 전체 채용 수요로 일반화하지 않으며, 이 코스만으로 RTOS·보드 bring-up 경험을 대체하지 않습니다. 공고의 현재 지원 접수 여부도 별도로 확인해야 합니다.

실무 포트폴리오에는 정상 사례와 고장 주입 사례를 함께 남기세요. 부분 읽기 전에 저장한 온도와 시각이 오류 뒤에도 같은지, 복구 횟수가 정말 한 번인지가 관찰 가능한 근거입니다. 그 증거 없이 ‘안정적인 드라이버’라고만 적으면 무엇을 확인했는지 알 수 없습니다.

다음 실습에서 할 것

4~6단계에서 정상 전송을 연결하고, 실패 시 표본 보존과 제한된 복구를 더합니다. 처음에는 정상 경로만 다루므로 각 중간 버전은 아직 제품용 드라이버가 아닙니다. 이전 구현을 유지하면서 현재 단계의 계약을 추가하세요.