Limits of the super loop: when you need an RTOS
Run everything from a single while(1) and the slowest job sets the response time of the whole system. The signs that it is time to move to an RTOS.
while (1) {
read_imu(); // 1 ms
update_display(); // 30 ms ← nothing else can happen meanwhile
parse_uart();
control_step();
}
The problems that appear
- Delay: the control loop and communication stop for the 30 ms of a display update.
- Timing jitter: one pass of the loop takes a different time each round, so the control period is not constant.
- Complexity: state variables and flags multiply as you split long jobs, and the code gets tangled.
How to get by with a super loop
- Time-critical work goes to a timer interrupt
- Long jobs are cut into small pieces with a state machine, a little at a time
- Remove blocking functions (
HAL_Delay, polling waits)
Plenty of products need nothing more. It is small, simple and easy to verify.
Signs it is time for an RTOS
- Four or five or more jobs with different periods
- You need a communication stack (TCP/IP, USB, BLE)
- Jobs have different deadlines, and an urgent job has to cut into a less urgent one
- State machines are layered so deep that nobody can explain the whole