Coordination
The Tyranny of Waiting
The simplest way to control a machine eventually becomes its greatest limitation.
PollingBare-MetalLatencyReal-Time ConstraintsCPU Overhead
1. The Infinite Loop
At the root of almost every bare-metal embedded system is a simple, inescapable fact: a processor must never stop executing instructions. Unlike desktop software that can run, finish its task, and cleanly return to an operating system, a microcontroller is the operating system. It has nowhere to go. If the CPU is allowed to reach the end of the program counter, it falls off a digital cliff, entering an undefined state where it may execute random garbage RAM contents. To maintain absolute control, the core must loop forever.
This is why embedded firmware fundamentally revolves around an endless loop:
int main(void) {
// Initialize peripherals
SystemInit();
while(1) {
// The engine of the system
}
}
This simple while(1) structure is the structural spine of bare-metal computing. It keeps the CPU active, heartbeat regular, and program execution contained. In a quiet, simple machine, this loop is the perfect foundation. But it is also an empty arena, waiting for responsibilities.
The circular flow of the infinite while(1) loop.
2. The Birth of Polling
Suppose we want our microcontroller to react when a user presses a button. How does the software know the button was pressed? The simplest and most intuitive way is to write code that actively, repeatedly checks the state of the pin connected to that button. We place a check function inside our loop:
while(1) {
if (ReadPin(BUTTON_PIN) == PIN_LOW) {
ToggleLED();
}
}
This is the birth of Polling. The central processing unit (CPU) is placed in a perpetual state of interrogation. It reads the input port register, compares the bit with its target state, and takes action if necessary. It asks: 'Has anything happened?' Then, nanoseconds later, it asks again: 'Has anything happened?'
This direct checking pattern is incredibly elegant because it is deterministic and easy to reason about. There are no background threads, no complex scheduler structures, and no preemption. The CPU does one thing: it waits, inspects, and reacts.
3. The Cost of Curiosity
But this curiosity is not free. When a processor polls, it consumes energy at its maximum operating rate. Even if the button is pressed once an hour, the processor does not rest. It spends millions of CPU cycles every second checking the same pin, reading the same registry value, and getting the exact same answer: 'No. Nothing has changed.'
In a battery-powered device, this is a disaster. Polling wastes massive amounts of power. The core is 100% active, running at full speed and drawing full current, simply to confirm that the world is quiet. The processor is trapped in a loop of wasted effort, spinning its wheels at top speed while waiting for something to happen.
Wasted CPU cycles: 99.9% of checks return no change, keeping core load at 100%.
4. The Growing System
The limitations of polling become severe when we add more responsibilities. Let's design a real-world system. It needs to read a UART command interface, sample an ADC temperature sensor, monitor a CAN bus network for safety alerts, and toggle an indicator LED. If we stick to our polling strategy, our loop grows to handle all of them:
while(1) {
CheckButton();
CheckUART();
CheckADC();
CheckCAN();
UpdateLEDs();
}
Now, the central processing unit is no longer just checking the button. It must perform a sequence of duties. Each check requires time. If CheckUART() has to read a packet, it executes instructions. If CheckADC() must wait for a conversion, it spins. As we add more peripherals, the total execution time of a single pass through the loop—the loop cycle time—stretches.
The expanding loop: as more peripherals are added, loop cycle time grows significantly.
5. Latency: The Unnoticed Gap
This brings us to the critical bottleneck of polling: Latency. In embedded engineering, latency is the delay between the occurrence of a physical event and the processor's response to it.
Imagine a UART message packet arriving at the exact millisecond CheckUART() finishes. The CPU moves to CheckADC(), then CheckCAN(), then UpdateLEDs(), and finally loops back to CheckButton(). Only when the execution path returns to CheckUART() does the CPU finally detect the packet. The worst-case response latency is directly proportional to the total loop cycle time:
Max Latency = Σi=1N} Time(Checki)
If the loop cycle time exceeds the arrival rate of new data, we encounter a catastrophic failure mode: missed events. If a second UART character arrives before the loop finishes its round to read the first, the hardware's internal buffer overflows, and data is permanently lost.
Timing timeline: showing the latency delay between an event's occurrence and its detection by the polling CPU.
6. Real Embedded Examples
Despite these limits, polling is still widely used in modern systems. In simple, low-cost microcontrollers running household appliances—like a toaster, a digital clock, or a basic toy—polling is perfectly sufficient. The event rates are low, power saving is achieved by sleeping the entire system when inactive, and latency is human-scale (a 50ms delay in a button press is imperceptible to a human user).
However, in high-speed and complex applications—such as CAN communication in automotive ECUs, high-rate sensor acquisition in flight stabilizers, or audio stream buffers—polling fails. High-speed systems cannot afford to wait for a loop to spin; they require immediate, microsecond-accurate responses.
7. The Fundamental Limitation
The core design flaw of polling is structural: it ties coordination to the execution path of the software. The CPU spends almost all its time and power asking if something has happened, only to receive 'no' as an answer. It is a system built on active waiting, where the processor is both a bottleneck and a victim of its own loop structure.
The Tyranny of the Loop
Polling works because the processor is simple, tireless, and constantly asks whether something has happened. It is the easiest way to control a machine, but as complexity grows, it becomes a structural straightjacket.
But what if the processor could stop asking? What if the hardware could announce events instead? What if the machine only reacted when something actually changed, leaving the processor free to sleep or run other tasks in the meantime?
That question would fundamentally change embedded software design. And it would lead directly to interrupts.
To free the processor from the tyranny of waiting, we must stop asking the hardware if it is ready, and teach the hardware to speak up when it is.
Current Exploration
The Tyranny of Waiting
