การตรวจสอบสถานะเทียบกับอินเทอร์รัปต์

So far your loop uses polling: it runs around and around, asking each sensor and button over and over whether anything changed.

A typical poll reads a pin every pass of the loop. If the value matches what you want, you react; otherwise you simply keep looping. 🔁

Polling works, but it wastes effort asking when nothing has changed. Your board burns cycles checking a pin that stays the same for a long time.

If a slow task or a long delay holds the loop, a quick press can come and go before you ever read the pin again.

Some signals are fast and brief: a sensor spike, an encoder edge, a short pulse. Miss the moment and the event is gone for good.

An interrupt flips the model: instead of you asking, the hardware taps your shoulder the instant something happens on a pin.

When an interrupt fires, the chip pauses whatever the loop was doing, runs your handler, then returns exactly where it left off. ⚡

Because the hardware watches the pin for you, even a tiny pulse triggers your code. You catch events a slow loop would skip.

With interrupts handling urgent signals, your loop stays clean and responsive, free to do its slower work without constant checking.

Not everything needs an interrupt. For a button a human presses slowly, polling is simpler and perfectly good enough.

Reach for an interrupt when an event is fast, brief, or might arrive while the loop is busy. Otherwise polling keeps things easy.

Which situation is the best reason to choose an interrupt over polling?

You saw that polling keeps asking while an interrupt gets notified. Use interrupts for fast events and polling for relaxed ones. 🎉