슈퍼루프의 한계: 언제 RTOS가 필요한가
while(1) 하나로 모든 일을 돌리면 가장 느린 작업이 전체 반응 속도를 정합니다. RTOS로 넘어갈 신호들.
while (1) {
read_imu(); // 1ms
update_display(); // 30ms ← 이 동안 아무것도 못 함
parse_uart();
control_step();
}
생기는 문제
- 지연: 디스플레이 갱신 30ms 동안 제어 루프와 통신이 멈춥니다.
- 타이밍 흔들림: 루프 한 바퀴 시간이 매번 달라 제어 주기가 일정하지 않습니다.
- 복잡도: 긴 작업을 쪼개려고 상태 변수와 플래그가 늘어나고 코드가 얽힙니다.
슈퍼루프로 버티는 방법
- 시간이 중요한 일은 타이머 인터럽트로
- 긴 작업은 상태 머신으로 잘게 나눠 한 번에 조금씩
- 블로킹 함수(
HAL_Delay, 폴링 대기) 제거
이것으로 충분한 제품도 많습니다. 작고 단순하며 검증이 쉽기 때문입니다.
RTOS로 넘어갈 신호
- 서로 다른 주기의 작업이 4~5개 이상
- 통신 스택(TCP/IP, USB, BLE)을 써야 함
- 작업마다 마감 시간이 다르고, 급한 일이 덜 급한 일을 끊고 들어가야 함
- 상태 머신이 여러 겹으로 얽혀 아무도 전체를 설명하지 못함