절전과 지연의 균형

절전의 이익에 응답 비용을 붙입니다

활성 시간을 줄이는 정책은 기록기의 응답 요구도 만족해야 합니다. 이번 레슨은 앞 모듈의 수집·전송 파이프라인을 이어받아 가상 깨우기 지연0ms와5ms를 비교합니다. 버튼 반응30ms, 타이머 예정 시각부터 샘플 발행20ms, 고정 소유 객체4096바이트라는 각각의 예산을 검사합니다. 에너지 추정치가 좋아도 하나의 응답 예산을 어기면 그 정책은 요구사항을 충족하지 못합니다.

미션 starter에는 m08 solution의 소스·HAL·회귀 테스트가 들어 있습니다. 기존 mq_push의 값 복사와 DROP_NEW 정책, 분리·STALE·CANCEL·재연결 정책을 새로 구현할 필요는 없습니다. resource.c의 지연 초과 집계와 상태별 에너지 계산을 완성합니다. make test는 앞 단계 전체 회귀와 새 자원 검사를 함께 실행합니다. 이전 동작을 삭제해서 새 테스트만 통과하는 변경은 통합 완료가 아닙니다.

resource_run은 원시 버튼이30ms에서 바뀌는 fixture를1ms씩 진행합니다. 깨우기0에서는 버튼 후보가30ms에 관찰되고20ms 디바운스 뒤50ms에 기록을 켭니다. 반응은20ms입니다. 깨우기5에서는 후보 관찰이35ms로 미뤄지고55ms에 켜져 반응25ms입니다. 측정 시작점을 디바운스 확정 시각으로 옮기지 않습니다. 두 숫자는 PC 실측이 아니라 HAL 가상 시각에서 얻은 결과입니다.

예정 시각과 샘플 시각을 보존합니다

타이머는100ms 간격의 due를 이벤트 큐에 넣습니다. 수집 상태는 IDLE에서 이벤트를 꺼내 MEASURE로, 다음 tick에서 센서를 읽어 TRANSMIT으로, 그 다음 tick에서 MessageQueue에 발행합니다. 지연0 조건은 due부터 발행까지2ms입니다. 깨우기5 조건은 이벤트 처리 시작을5ms 미뤄7ms가 됩니다. 발행은 전송 완료와 다른 사건이므로 보고서에는 발행 기준이라고 표시합니다.

미션은 IDLE 상태에서 큐의 첫 due를 읽어 별도 보관합니다. 센서 timestamp_ms는 실제 가상 측정 시각으로 그대로 둡니다. 앞 모듈의 STALE 검사는 측정된 값의 나이를 사용하기 때문입니다. 지연을 재려고 timestamp를due로 덮어쓰면 데이터 신선도 계약을 바꾸게 됩니다. 관심 사건마다 독립된 시각을 남기되 같은 seq로 연결하는 방식이 원인 분석에 유리합니다.

깨우기 지연은 이번 모델에서 버튼 폴링과 타이머 처리 시작을 늦춥니다. 운영체제 sleep 호출로 시간을 기다리는 실험이 아닙니다. 실제 MCU의 클록 안정화·레지스터 유지·웨이크 핀·타이머 동작도 구현하지 않았습니다. 모형은 선택한 가정의 영향을 계산하는 데 쓰고 보드에서 확인할 항목은 따로 적습니다. 새로운 깨우기 원인을 추가한다면 그 사건도 지연 시작 조건에 포함해야 합니다.

새 resource 테스트는 깨우기19ms도 실행합니다. 버튼39ms와 샘플21ms로 예산을 넘는 대조군입니다. resource_run이 성공 반환하는 것은 fixture의 파이프라인이 정상적으로 기록3건을 만들었다는 의미이며 모든 마감을 만족했다는 뜻이 아닙니다. 응답 예산은 측정한 숫자를 별도로 비교합니다. 정상 기능과 시간 요구를 분리해야 늦게 끝난 정상 작업도 요구 위반으로 드러낼 수 있습니다.

큐 최고점과 소유 메모리를 보고합니다

정상 루프는 발행 뒤 같은 tick에서 소비하므로 큐 최고점은1입니다. 이 조건의 최고점1을 보고 큐 용량을1로 줄여도 안전하다고 말할 수 없습니다. 앞 모듈의 부하 fixture는16까지 차고 DROP_NEW도 발생합니다. 최고점에는 관찰 조건을 붙이고 정상부하와 과부하 표를 나눕니다. p.queue.high는 이미 push에서 갱신되므로 출력 시점 count가0이어도 최고점은 사라지지 않습니다.

pthread와 공유하는 통계를 읽을 때는 큐 갱신과 같은 mutex를 사용합니다. 슬롯만 보호하고 high·dropped는 잠금 없이 읽으면 관찰 코드가 경쟁 조건을 새로 만들 수 있습니다. resource_run은 결정적 단일 루프이지만 snapshot에도 동일 규칙을 적용합니다. 잠금 도중 printf 같은 긴 작업을 넣는 대신 값을 복사하고 해제 뒤 보고하는 습관을 유지합니다. 측정 코드도 동시성 계약의 일부입니다.

owned_bytes는 누적 프로젝트의 고정 소유 객체를 sizeof로 합산합니다. 기록16건·메시지16건·이벤트8건·SPI 저장256바이트와 각 관리 필드가 구조체 안에 포함됩니다. 출력 크기는 호스트 ABI에 따라 변할 수 있으므로 정답을 특정 숫자로 고정하지 않고 범위0초과4096이하로 확인합니다. 실제 MCU SRAM 사용량이나 전체 프로세스 메모리로 이름을 바꾸지 않습니다. 타깃 배치와 스택 최고점은 후속 실물 검증입니다.

에너지는 동일 관찰 구간에서 비교합니다

전력 표는100ms 모델에서 유효 작업20ms를 공통으로 둡니다. 깨우기0의 활성 시간은20ms이고 절전80ms입니다. 깨우기5의 활성 시간은25ms이며 절전75ms입니다. 깨우기5ms를 총 구간에 더해105ms로 만들지 않습니다. 이 가정에서 평균 전류는2.8에서3.25mA로, 평균 전력은9.24에서10.725mW로 늘어납니다. 깨우기 비용도 활성 전류를 사용한다는 모델의 선택입니다.

같은 정책을 전부 활성100ms와 비교하면 절전의 이익을 볼 수 있습니다. 그 기준은10mA·33mW·3.3mJ입니다. 깨우기5 정책은1.0725mJ이므로 이 기준보다 작지만 깨우기0의0.924mJ보다 큽니다. 어떤 두 정책을 비교하는지 표시하지 않고 절전이 전력을 늘린다고 요약하면 기준이 사라집니다. 지연·소비·데이터 손실·저장 예산을 각각 표시하여 선택의 이유를 설명합니다.

가상 루프는0~350ms를 진행해3건을 발행하지만 에너지 표는 별도의100ms 상태 비율 모델입니다. 따라서 그 에너지를 루프 전체 소비라고 소개하면 틀립니다. 미션 보고서에서는 가상 기능 fixture 구간과 에너지 모델 관찰 구간을 서로 다른 항목으로 씁니다. 실제 동작 이력을 통합해 에너지를 누적하려면 모든 상태의 진입·종료 시각을 기록하고 기간 합을 검사하는 추가 구현이 필요합니다.

회귀와 증거를 함께 인계합니다

FAIL line과 조건이 나오면 해당 조건을 읽습니다. energy_mj(20,100)가0.924와 다르면 절전 항과1000 환산을, missed가1이 아니면 등호 경계를 확인합니다. 오래된 pipeline 회귀가 실패하면 새 측정 때문에 소비자가 두 번 실행됐거나 timestamp 의미가 바뀌었는지 봅니다. 옛 recovery_tick이나 bus_consume을 새 루프의 추가 소비자로 호출하지 않습니다. 새 계측은 기존 기록·복구 경로를 보존해야 합니다.

RESOURCE-EVIDENCE.md에는 실제 명령 출력과 환경, 미구현 starter의 실패 이유, solution의 누적 통과, 가상 지연과 예산 판정, 모델 소비와 적용 한계를 적습니다. 호스트 구간 계측은 첫 레슨의 명령으로 별도 실행해 수치를 붙일 수 있습니다. 독자는 보고서만 보고 어떤 숫자가 직접 실행 결과이고 어떤 값이 명세 가정인지 구별할 수 있어야 합니다. 실물 응답·전류·스택·최악 시간은 향후 확인할 근거로 남깁니다.