Interrupts vs. Polling: The Battle for CPU Cycles

Author: Srihari Maddula

Reading Time: 18 mins

Category: System Architecture & Efficiency

Every clock cycle has a cost. Photo by Unsplash.

In your first "Intro to Microcontrollers" class, you likely learned how to read a button press. The code probably looked like this: while(1) { if(digitalRead(BUTTON_PIN) == LOW) { // do something } }. This is Polling. It’s simple, it’s intuitive, and it works—on a desk, with one button, and no other tasks.

But here’s the cold, hard truth: Polling is a CPU-killing addiction. For a junior engineer, polling feels safe because you can "see" the flow of execution. For a senior engineer, polling is usually a sign of a poorly architected system that is wasting power, missing deadlines, and burning through CPU cycles that could be used for something far more important.

1. Technical Pillar 1: The Economics of CPU Cycles

To understand why we move to Interrupts, you have to understand the "Opportunity Cost" of a CPU cycle. If your MCU is running at 100MHz, it has 100 million cycles per second. How many of those are you willing to waste?

The Professional Reality: The Efficiency Gap

• Polling: Imagine you are waiting for a very important delivery. In a polling-based system, you walk to your front door every 5 seconds, open it, check the porch, and walk back. You can't start cooking, you can't sleep, and you're exhausted from walking back and forth. This is exactly what a while(1) loop checking a status flag does to your silicon.

• Interrupts: Now, imagine you install a doorbell. You go inside, start your work, and only when the bell rings do you stop what you're doing, handle the delivery, and return to your task. The "Doorbell" is an interrupt.

Key Insight: A polling system has a CPU utilization of 100% even when it's doing absolutely nothing. An interrupt-driven system can achieve 0.1% utilization while maintaining the same responsiveness. This isn't just about efficiency—it's about battery life. You can't put a CPU into "Deep Sleep" if it has to stay awake to check a button every 10ms.

Power efficiency starts with efficient software. Photo by Unsplash.

2. Technical Pillar 2: Interrupt Latency & The "NVIC"

When the "Doorbell" (Interrupt) rings, the CPU doesn't jump instantly to the code. There is a cost. This is known as Interrupt Latency.

The Professional Reality: Decoding the NVIC

Modern ARM Cortex-M processors use a Nested Vectored Interrupt Controller (NVIC). This is a sophisticated hardware block that handles the "Chaos" of multiple interrupts firing at once.

• Context Switching: When an interrupt occurs, the CPU must "Save" the current state (Registers R0-R12, Program Counter, etc.) to the Stack. This takes a specific number of clock cycles (usually 12-16 cycles on a Cortex-M4).

• Tail-Chaining: If one interrupt is finishing and another is already pending, the NVIC doesn't bother restoring the registers only to save them again. It jumps directly to the next handler. This saves time and is critical for high-speed motor control.

• Prioritization: What happens if the Doorbell rings while the Fire Alarm is going off? You need Priority Grouping. A Senior Engineer designs an interrupt hierarchy where critical safety tasks (like an Over-Current fault) can "Pre-empt" (interrupt) a less important task (like a UART print).

"Interrupts are the heartbeat of real-time systems. If you don't control the priority, you don't control the system."

3. Technical Pillar 3: The Danger Zone—Re-entrancy & Shared Resources

The most common source of "Ghost Bugs" in embedded systems is the misuse of global variables between an Interrupt Service Routine (ISR) and the main loop. These are the bugs that only appear once every three days in the field and are impossible to reproduce on the bench.

The "Atomic" Problem

Imagine your main loop is updating a 32-bit variable system_runtime. A 32-bit update on an 8-bit or 16-bit processor takes multiple instructions. If an interrupt occurs in the middle of those instructions and reads that same variable, it will get a corrupted value—half of the old value and half of the new one.

• The Right Way: Always use the volatile keyword for shared variables to tell the compiler "Don't optimize this; it can change at any time."

• Critical Sections: For multi-byte updates, you must disable interrupts briefly to ensure the operation is "Atomic."

__disable_irq(); // Enter Critical Section
global_counter += 1000;
__enable_irq();  // Exit Critical Section

Warning: Keeping interrupts disabled for too long is the #1 cause of "System Jitter." A Senior Engineer keeps their ISRs extremely short—usually just clearing a flag and pushing data to a buffer for a background task to process.

Software architecture is about managing data flow and shared state. Photo by Unsplash.

4. The "Missing Middle": The RTOS Integration

In a professional production environment, we rarely use just "Bare Metal" interrupts for everything. We use a Real-Time Operating System (RTOS) like FreeRTOS or Zephyr.

From ISR to Task

In an RTOS, the ISR's job is not to do the work. Its job is to "Signal" a high-priority Task to do the work. We use Semaphores or Direct-to-Task Notifications to achieve this.

• The Workflow: Hardware Interrupt fires -> ISR clears the hardware flag -> ISR "Gives" a Semaphore -> RTOS Scheduler switches to the Task -> The Task performs the complex processing.

Summary: The Roadmap to Efficiency

1. Stop Polling by Default: If your peripheral has an "Interrupt Enable" bit, use it. Save your CPU for the real work.

2. Keep ISRs Lean: Never use printf, delay, or complex math inside an interrupt. Clear the flag and get out.

3. Use Volatile & Atomics: Protect your data integrity. "Race Conditions" are the hardest bugs to find; don't invite them into your code.

4. Measure Your Latency: Use a GPIO toggle and an oscilloscope to measure exactly how long it takes your system to respond to a hardware trigger.

At EurthTech, we design systems that respect every single clock cycle. We build products that don't just work—they work with precision, reliability, and extreme power efficiency.

Want to build high-performance firmware? Master the interrupt.