Polling checks for an event on a fixed schedule, wasting cycles and sometimes missing brief events between checks. An interrupt lets hardware immediately signal the processor the moment the event actually occurs.
An embedded system is a microcontroller-based system dedicated to a specific function — a thermostat controller, an engine control unit, a sensor node. How that system detects and responds to external events (a button press, a sensor threshold, incoming data) is a fundamental design decision with real consequences for both efficiency and correctness: polling versus interrupt-driven design.
Polling means the processor repeatedly checks a status flag or input on a fixed schedule, in a loop, to see if an event has occurred. It's simple to implement and reason about, but it wastes processor cycles checking when nothing has happened, and — critically — an event occurring between two scheduled checks isn't noticed until the next check, adding real response latency and potentially missing very brief events entirely if they don't persist until the next poll.
An interrupt lets a hardware event directly signal the processor, which pauses its current work, runs a dedicated interrupt service routine (ISR) to handle the event, and then resumes exactly where it left off. This responds to the event immediately (within the hardware's interrupt latency, typically far faster than a polling interval) and frees the processor to do other useful work — or sleep in a low-power state — instead of continuously checking for something that hasn't happened yet.
Interrupts aren't universally better — for extremely high-frequency events, the overhead of repeatedly entering and exiting an ISR can exceed the cost of simple polling, and polling avoids the added complexity of managing interrupt priorities, race conditions, and reentrancy concerns. Real embedded designs often use a hybrid: an interrupt to detect that data is ready, followed by polling-style processing of that data in the main loop.
Yes — if an event is brief enough (a short pulse) and occurs then ends entirely between two scheduled polling checks, the polling loop will never observe it happened at all, since it only sees the input's state at each discrete check, not a continuous record of everything that occurred between checks.
The dedicated function that executes immediately when a specific interrupt occurs — it handles the event (reading data, clearing a flag, signaling other code) as quickly as possible, then returns control to whatever the processor was doing before the interrupt occurred, resuming it as if uninterrupted.
Interrupts add real complexity: managing priorities between multiple simultaneous interrupt sources, protecting shared data from being corrupted if an ISR and the main program access it at the same time (race conditions), and the fixed overhead cost of entering/exiting an ISR — for very high-frequency, predictable events, efficient polling can outperform interrupt-driven handling.
Try our STEM Learning Studio
More calculators, simulators, and guides for this discipline.