Electronics 118: Control Loop Timing & Real-Time Constraints
A practical engineering guide to real-time behavior in control systems: why timing matters more than raw CPU speed, how jitter destroys stability, and how to design predictable control loops on microcontrollers, embedded Linux systems, and industrial controllers.
1) What “real-time” actually means
A real-time system is one where correctness depends not only on logical results, but also on when those results are produced.
- Hard real-time: Missing a deadline is a failure
- Soft real-time: Occasional misses degrade performance
2) Why timing matters in control systems
Control algorithms (like PID) assume a fixed time step. When timing varies, the math no longer matches reality.
Cause: Timing jitter.
3) Control loop frequency selection
Control loops must run faster than the system they control.
- Rule of thumb: 10× mechanical bandwidth
- Motors: 500Hz–5kHz typical
- Temperature control: 1–10Hz typical
4) Latency vs jitter
| Term | Meaning | Impact |
|---|---|---|
| Latency | Fixed delay | Usually tolerable |
| Jitter | Variable delay | Destroys stability |
5) Sampling theory (practical view)
Sensors sample continuous reality at discrete intervals. Poor sampling creates aliasing and instability.
- Sample at least 2× highest signal frequency (Nyquist)
- In practice: 5–10× gives margin
- Use filtering before control
6) Deadlines, overruns & missed cycles
Every control loop iteration must complete before the next one begins.
Result: Skipped updates, erratic output, instability.
7) Interrupts, timers & scheduling
Reliable timing requires hardware support.
- Hardware timers define loop rate
- Interrupts trigger execution
- Main loop handles non-critical tasks
8) Bare-metal vs RTOS vs Linux
| Platform | Timing Predictability | Typical Use |
|---|---|---|
| Bare-metal MCU | Excellent | Motor control, safety loops |
| RTOS | Very good | Complex embedded systems |
| Linux | Poor–Moderate | High-level coordination |
9) Measuring real-time performance
You cannot fix timing issues you cannot see.
- Toggle GPIO pins to measure loop timing
- Use logic analyzers or oscilloscopes
- Log timestamps sparingly
10) Robust real-time design patterns
- Fixed-rate control loop
- Double-buffered sensor data
- Priority separation (control vs UI)
- Fail-safe outputs on overrun
11) Common timing failures
- Blocking I/O in control loop
- Variable execution paths
- Shared resources without protection
- Assuming desktop timing applies to embedded
- Ignoring worst-case execution time
12) Design rules for predictable systems
- Measure worst-case execution time
- Fix loop rate in hardware
- Separate real-time and non-real-time tasks
- Fail safely when deadlines are missed
- Test under maximum load
