구성과 면접 설명 인계
90분 안팎
학습 목표
HAL 구성·통신 규격·전이도·실측 조건·신입 면접 답변을 연결한 인계 문서를 제출합니다.
개념
인계 문서는 다음 사람이 실행할 지도입니다
완성한 코드가 자기 노트북에서 돌아가는 것과 팀이 유지할 수 있는 것은 다릅니다. 새 담당자는 어느 HAL을 바꾸면 실물로 옮길 수 있는지, 어떤 오류가 자동 복구인지, 보고된 시간과 메모리가 무엇을 포함하는지 알아야 합니다. 이번 레슨은 미션의 구성·통신·오류·측정·면접 근거 다섯 문서를 연결합니다. 문서 길이로 평가하지 않고 주장 하나에서 소스와 재현 명령으로 이동할 수 있는지 평가합니다.
CONFIG.md에는 버튼 bit0에서 Controller·EventQueue·Recovery·MessageQueue·소비자로 이어지는 흐름을 글이나 표로 표현합니다. 소비자는 Buffer·SPI·UART로 결과를 보냅니다. GPIO 출력 bit1은 LED입니다. 모형 비트 번호를 실제 보드 핀 번호로 적지 않습니다. 장치 의존 인터페이스와 fixture 제어 인터페이스를 구분하고 hal_sim_set_time을 제품 로직이 호출해야 한다는 잘못된 인계를 피합니다.
각 저장 공간의 소유자·용량·반환 시점을 적습니다. 이벤트 큐는 8건, 메시지 큐는 16건, 기록은 16건, SPI 모형은 256바이트입니다. pthread 큐에는 mutex와 조건 변수가 있으며 값 복사로 메시지를 넘깁니다. 임시 측정 구조체의 포인터를 큐에 넣는 방식으로 바꾸지 않습니다. 공간 부족에서는 기존 정책과 시험 sink의 예외를 나누어 써서 재생 편의를 실제 제품 요구로 오해하지 않게 합니다.
통신 규격에는 숫자의 위치와 실패 의미가 필요합니다
PROTOCOL.md는 가상 I2C 주소 0x48·레지스터 0·읽기 길이 2·타임아웃 20ms를 적습니다. 온도 word는 부호 있는 16비트 표현을 256으로 나눈 도 모델이고 코드는 milli-degree 정수로 바꿉니다. ADC 0부터 4095를 0부터 3300mV로 환산합니다. 실제 부품 데이터시트에서 가져온 전압 조건이라고 쓰지 않습니다. 이 가상 규격을 실물에 적용하려면 센서 데이터시트와 주소 표기부터 확인해야 합니다.
UART 프레임은 13바이트입니다. 시작 0xA5·payload 길이 10 다음에 timestamp 4바이트·temp_mc 4바이트·adc_mv 2바이트·XOR 1바이트가 옵니다. 정수는 상위 바이트부터 저장하고 XOR은 인덱스 1부터 11까지 계산합니다. raw 구조체의 sizeof를 wire 길이로 소개하면 padding 때문에 다른 환경에서 어긋납니다. 필드별 인덱스와 단위를 적어 수신 프로그램 작성자가 코드 내부 구조체 배치에 의존하지 않게 합니다.
SPI 문서에는 mode 0의 select·write·release 순서와 실패에도 CS 해제를 적습니다. checksum은 간단 오류 검출이며 악의적 변경을 막는 인증은 아닙니다. 모형에 baudrate나 실제 전압 파형이 없는데 통신 전기 조건까지 통과했다고 쓰지 않습니다. test_buses.c의 길이·주소·부호·checksum·CS 조건을 규격 행 옆에 연결합니다. 숫자만 맞는 표보다 실패시 유지할 출력과 반환값까지 적은 표가 구현 인계에 유용합니다.
전이도와 측정 표를 같은 근거로 연결합니다
FAULTS.md에서 IDLE은 이벤트 대기, MEASURE는 새 값 확인, TRANSMIT은 큐 발행으로 설명합니다. 이 구조에서 UART·SPI 소비는 pipeline_dispatch가 담당하므로 TRANSMIT 이름만 보고 전송 완료라 말하지 않습니다. RECOVER는 분리 또는 예산 안의 재시도이고 ERROR는 지속 실패 또는 소비 실패가 고정된 상태입니다. 버튼을 멈춘다고 ERROR가 지워지는 것은 아닙니다. reconnect 동작과 일반 연결 회복을 분리합니다.
오류 전이 옆에는 valid와 필터 초기화·이벤트 폐기·메시지 취소·저장 이력 보존을 적습니다. 상태 이름 화살표만 있으면 오래된 온도를 다음 정상 값처럼 쓰는 문제를 검토할 수 없습니다. 각 전이의 근거는 F01부터 F07의 fixture와 해당 CHECK입니다. 최종 오류 상태를 기대한 경우와 실제 재연결 뒤 새 값 저장 성공을 기대한 경우를 나눠 복구 성공을 과장하지 않습니다.
MEASUREMENTS.md에는 seed·시작점·간격·건수·가상 시각 범위·sink 정책을 적고 raw.csv·summary.json·environment.json을 연결합니다. 가상 최대 지연 2ms는 관심 사건이 due부터 발행/소비까지라는 설명이 필요합니다. 측정 timestamp는 due+1로 따로 보존합니다. 호스트 시간 숫자를 덧붙이려면 측정 API·구간·워밍업·반복·컴파일 옵션을 새 행에 적으며 가상 값과 같은 열의 최악 실행 시간으로 합치지 않습니다.
앞 모듈의 owned_bytes는 고정 소유 객체 sizeof 합입니다. 전체 링커 정적 영역이나 스택·힙 최고점 실측이 아닙니다. 전력은 독립 100ms 구간에서 3.3V·활성 10mA·절전 1mA를 가정한 모델입니다. wake 0의 0.924mJ와 wake 5의 1.0725mJ를 기록하되 하루 재생 전체 전류를 측정했다고 쓰지 않습니다. 숫자의 단위와 계산 구간을 확인하면 큰 숫자보다 믿을 수 있는 짧은 표를 만들 수 있습니다.
면접 답변은 선택과 근거를 포함합니다
INTERVIEW.md에는 센서 무응답 점검과 상태 머신 질문에 대한 60초 답변을 씁니다. 증상·가설·주입 조건·관찰 값·정책 선택·한계 순서로 정리합니다. 무응답은 connected·NACK·delay를 구분하고 실제 보드에서는 전원·배선·pull-up·주소·파형을 확인한다고 연결합니다. 하지 않은 실물 측정을 경험으로 말하지 않습니다. PC에서 직접 재현한 코드와 로그 위치를 제시하는 것만으로도 판단 과정을 설명할 수 있습니다.
DROP_NEW를 선택한 이유에는 기존 대기 순서 보존과 새 사건 손실이라는 비용이 같이 있어야 합니다. 용량을 늘리면 영원히 해결된다고 답하지 않습니다. 정상 high 1과 과부하 high 16·drop 4를 대조하고 장치 처리율·정책·메모리 예산을 다음 실험으로 제시합니다. 답변을 읽는 사람은 이 결정을 유지해야 할 조건과 다시 검토할 조건을 모두 이해할 수 있어야 합니다.
make test는 문서 존재·최소 길이·TODO 부재를 검사하지만 기술 내용이 사실인지 자동으로 이해하지 않습니다. 문서를 채워 넣었다는 판정과 인간 리뷰를 나눕니다. 주장마다 소스 함수·fixture·명령·실제 출력 중 적절한 근거를 붙이고 solution의 예시 수치와 자신의 환경을 비교합니다. 잘못된 측정 단위나 실제 MCU라고 쓴 범위는 테스트가 녹색이어도 수정해야 합니다.
최종 제출은 압축의 완성 소스와 evidence 문서·원시 관찰·요약·환경·회귀 로그입니다. 다른 사람은 새 폴더에서 make test를 실행하고 로그의 실패 수를 확인한 뒤 문서의 수치를 대조합니다. 실패하면 컴파일 오류·조건 실패·증거 불일치·sanitizer 진단 중 어느 종류인지 보고합니다. 실행 파일은 make clean으로 정리하고 사용했던 명령과 결과는 남깁니다. 이것이 릴리스 근거를 재생 가능한 프로젝트와 함께 인계하는 완료 조건입니다.
따라하기
문서 다섯 개의 근거 연결
CONFIG에서 pipeline.h와hal.h, PROTOCOL에서 buses.c, FAULTS에서 test_recovery.c와test_pipeline.c, MEASUREMENTS에서 release_check.py와resource.c, INTERVIEW에서 각 주장에 대응하는 파일을 연결합니다. 채워야 할 텍스트는 실습 압축의 evidence에 있습니다. 모형과 실물 조건을 구분해 작성합니다.
실행 근거와 문서 존재 대조
문서5개를 작성한 solution에서 실행한 출력입니다. 길이·TODO 확인은 내용 사실 검토를 대신하지 않습니다. 자신의 설명이 fixture와 같은 정책인지 사람이 대조합니다.
python3 release_check.py실행 결과
replay: same seed equal; different seed differs; rollover and invalid inputs pass virtual24h: samples=864000 errors=0 max_latency_ms=2 dropped=0 queue_high=1 evidence: raw.csv and summary.json match replay; 5 handoff documents present
자원 보고서의 범위를 확인
이 호스트의 소유 객체 크기와 독립100ms 모델 출력입니다. 자신의 환경에서는 owned_bytes가 달라질 수 있습니다. 가상 응답과 전력 모델·실물 미검증을 각기 다른 항목에 씁니다.
make -s resource-demo
./resource-demo실행 결과
owned_bytes=1137 budget=4096 scope=host_objects model wake_ms=0 button_ms=20 sample_ms=2 high=1 button_pass=1 sample_pass=1 avg_ma=2.80 power_mw=9.240 energy_mj=0.9240 model wake_ms=5 button_ms=25 sample_ms=7 high=1 button_pass=1 sample_pass=1 avg_ma=3.25 power_mw=10.725 energy_mj=1.0725
한 번의 검증 명령으로 인계하기
완성한 미션 폴더에서 실행합니다. 누적 회귀와 릴리스 검사가 모두 통과하고 종료0인지 확인한 뒤 터미널의 실제 출력을 evidence/regression.txt로 보관합니다. 오류와 진단도 함께 보관하고 이전 로그를 새 실행과 혼동하지 않습니다. 새 압축 해제 폴더에서 동료가 재현할 수 있는지 검토합니다.
make test확인 문제
실습
미션 압축의 evidence/CONFIG.md·PROTOCOL.md·FAULTS.md·MEASUREMENTS.md·INTERVIEW.md를 제출합니다. 구성에는 HAL 경계·소유권·용량·sink 정책, 규격에는 주소·바이트 순서·필드 인덱스·오류 반환, 오류에는 전이와 데이터 유지/폐기, 측정에는 환경·관찰 구간·원시집계 대응·모델 가정, 면접에는 무응답 점검과 상태 머신의 선택 이유를 적습니다. make test의 실제 회귀 로그와 raw.csv·summary.json·environment.json을 연결합니다. 각 주장에서 소스·명령·관찰로 이동할 수 있어야 하며 실제 보드 후속 측정 목록을 포함합니다.
더 읽기
면접 질문
- 센서가 응답하지 않을 때 점검할 순서를 설명해 주시면 됩니다.
- 센서 기록기의 상태 머신을 설명해 주시면 됩니다.