{"id":52267,"date":"2026-11-01T10:50:48","date_gmt":"2026-11-01T10:50:48","guid":{"rendered":"http:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/"},"modified":"2026-11-01T10:50:48","modified_gmt":"2026-11-01T10:50:48","slug":"interrupts-and-timers","status":"publish","type":"siratek_tutorial","link":"https:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/","title":{"rendered":"Responding Immediately with Interrupts"},"content":{"rendered":"

<\/p>\n

What this covers<\/h2>\n

Everything so far has worked by checking: loop()<\/code> runs round, reads a pin, and decides. That is fine while the loop is quick, and it starts to fail when the loop has real work in it.<\/p>\n

An interrupt is the other way round. You tell the chip \u201cwhen this pin changes, stop whatever you are doing and run this function\u201d. The hardware watches the pin, not your code, so the response happens in microseconds regardless of what the sketch was in the middle of.<\/p>\n

It is the right tool for a narrow set of jobs and the wrong one for most. Knowing which is which is most of this page.<\/p>\n

Before you begin<\/h2>\n

Nothing new to wire. A push button on pin 2 is enough, and Read a Push Button<\/em> already built it.<\/p>\n

When you need one<\/h3>\n
    \n
  • A pulse too short to catch by polling.<\/strong> A rotary encoder turned quickly, or a flow meter\u2019s pulses. Miss one and the count is permanently wrong.<\/li>\n
  • Something that must respond immediately<\/strong>, such as an emergency stop.<\/li>\n
  • Waking a sleeping board<\/strong>, which is how a battery project lasts months instead of days.<\/li>\n<\/ul>\n

    When you do not<\/h3>\n
      \n
    • A button a person presses.<\/strong> Human fingers are slow and millis()<\/code> polling catches every press. Using an interrupt here adds bounce problems and buys nothing.<\/li>\n
    • Reading a sensor regularly.<\/strong> That is what the millis()<\/code> pattern is for.<\/li>\n
    • Anything that takes time to handle.<\/strong> The handler must be short, and most work is not.<\/li>\n<\/ul>\n

      The honest summary: if Timing Without delay()<\/em> solves it, use that. Interrupts are for things polling genuinely cannot catch.<\/p>\n

      \"Two
      A pulse that starts and ends between two checks is lost for ever. The hardware does not have to be looking.<\/figcaption><\/figure>\n

      The two interrupt pins<\/h2>\n

      On an Uno only pin 2 and pin 3<\/strong> support attachInterrupt()<\/code>. That is the whole list.<\/p>\n

      attachInterrupt(digitalPinToInterrupt(2), myHandler, FALLING);<\/code><\/pre>\n
      digitalPinToInterrupt()<\/code> converts the pin number into the interrupt number the hardware uses. Writing attachInterrupt(0, ...)<\/code> happens to mean pin 2 on an Uno and something else on a Mega, so use the macro and the sketch stays portable.<\/p>\n
      The modes are RISING<\/code>, FALLING<\/code>, CHANGE<\/code> and LOW<\/code>. FALLING<\/code> is right for a button to ground with INPUT_PULLUP<\/code>.<\/p>\n
      A Mega has six interrupt pins and an ESP32 allows any pin, which is one more reason to check the board before designing around two.<\/p>\n
      The rules for a handler<\/h2>\n
      An interrupt handler, or ISR, runs with the rest of the sketch frozen. That imposes real constraints, and breaking them produces faults that are very hard to find because they are intermittent.<\/p>\n
      Keep it short.<\/strong> Set a flag, increment a counter, record micros()<\/code>. Nothing else. While it runs, nothing else on the board does.<\/p>\n
      Do not use delay()<\/code>.<\/strong> It needs interrupts to work and they are off. It will hang.<\/p>\n
      Do not use Serial.print()<\/code>.<\/strong> It needs interrupts too. It sometimes appears to work, which is worse than failing.<\/p>\n
      millis()<\/code> does not advance.<\/strong> You can read it, and it will not move while the handler runs. micros()<\/code> is usable for short measurements.<\/p>\n
      Variables shared with loop()<\/code> must be volatile<\/code>.<\/strong> This is the rule most often broken, so it gets its own section.<\/p>\n
      Why volatile, and what goes wrong without it<\/h3>\n
      The compiler optimises. If it sees a loop reading a variable that nothing in that loop changes, it is entitled to read it once and reuse the value.<\/p>\n
      That is correct reasoning and wrong here, because the ISR does change it, invisibly.<\/p>\n
      volatile bool pressed = false;      \/\/ volatile: the ISR changes this\n\nvoid handler() {\n  pressed = true;\n}\n\nvoid loop() {\n  if (pressed) {                    \/\/ without volatile, this may be read once, forever\n    pressed = false;\n    Serial.println(\"pressed\");\n  }\n}<\/code><\/pre>\n
      The symptom is a sketch that works at one optimisation level and not another, or works until you add an unrelated line. Mark every variable shared with an ISR volatile<\/code> and the problem does not arise.<\/p>\n
      Reading a multi-byte variable safely<\/h3>\n
      volatile<\/code> is not enough on its own for anything larger than a byte.<\/p>\n
      An ATmega328P is 8-bit, so reading a long<\/code> takes four separate operations. If an interrupt fires between the second and the third, you get half the old value and half the new one, which can be a number that never existed.<\/p>\n
      volatile unsigned long pulseCount = 0;\n\nunsigned long readCount() {\n  noInterrupts();                   \/\/ briefly block, so the read is not split\n  unsigned long value = pulseCount;\n  interrupts();\n  return value;\n}<\/code><\/pre>\n
      Keep the blocked section to the copy itself. Anything longer starts costing you the interrupts you went to the trouble of setting up.<\/p>\n
      Bounce, which interrupts make worse<\/h2>\n
      A mechanical button bounces: one press produces several electrical transitions. Polling with a debounce delay hides this; an interrupt catches every one of them.<\/p>\n
      So an interrupt-driven button counts one press as three or four. If you need a button on an interrupt, debounce in the handler by time:<\/p>\n
      volatile unsigned long lastInterrupt = 0;\nvolatile int count = 0;\n\nvoid handler() {\n  unsigned long now = micros();\n  if (now - lastInterrupt > 200000) {    \/\/ ignore anything within 200 ms\n    count++;\n    lastInterrupt = now;\n  }\n}<\/code><\/pre>\n
      micros()<\/code> works in a handler, and comparing unsigned values this way survives the rollover for the same reason the millis()<\/code> pattern does.<\/p>\n
      A worked example: counting fast pulses<\/h2>\n
      This is a job polling cannot do reliably.<\/p>\n
      \/\/ Siratek: counting pulses that are too short and too frequent to poll for.\n\nconst int pulsePin = 2;\n\nvolatile unsigned long pulseCount = 0;\n\nvoid onPulse() {\n  pulseCount++;                     \/\/ short, and nothing else\n}\n\nunsigned long readCount() {\n  noInterrupts();\n  unsigned long value = pulseCount;\n  interrupts();\n  return value;\n}\n\nvoid setup() {\n  pinMode(pulsePin, INPUT_PULLUP);\n  attachInterrupt(digitalPinToInterrupt(pulsePin), onPulse, FALLING);\n\n  Serial.begin(9600);\n  Serial.println(\"Siratek: counting pulses on pin 2.\");\n}\n\nvoid loop() {\n  \/\/ The loop can be as slow as it likes. No pulse is missed.\n  delay(1000);\n\n  Serial.print(\"pulses so far: \");\n  Serial.println(readCount());\n}<\/code><\/pre>\n
      The delay(1000)<\/code> is deliberate. It would make a polling version useless, and here it costs nothing: the hardware is counting whether the sketch is paying attention or not. That is the whole argument for interrupts in one sketch.<\/p>\n
      Timer interrupts, and a warning<\/h2>\n
      The other kind fires on a timer rather than a pin, which is how you run something at an exact interval regardless of the loop.<\/p>\n
      It is genuinely useful, for refreshing a multiplexed display or sampling at a fixed rate. It is also where beginners break things, because the Uno\u2019s three timers are already in use<\/strong>:<\/p>\n
        \n
      • Timer0<\/strong> runs millis()<\/code>, micros()<\/code> and delay()<\/code>. Touch it and all three break.<\/li>\n
      • Timer1<\/strong> drives PWM on pins 9 and 10, and the Servo<\/code> library takes it.<\/li>\n
      • Timer2<\/strong> drives PWM on pins 3 and 11, and tone()<\/code> and IRremote take it.<\/li>\n<\/ul>\n
        So there is no free timer on an Uno, only a choice about what to give up. Before reconfiguring one, know which pins and libraries stop working.<\/p>\n
        The MsTimer2<\/strong> and TimerOne<\/strong> libraries wrap this up safely and are the sensible starting point. Writing timer registers directly is worth learning and is not the place to begin.<\/p>\n
        If you want a fixed interval and do not need microsecond accuracy, the millis()<\/code> pattern is simpler, portable, and breaks nothing.<\/p>\n
        Check yourself<\/h2>\n
          \n
        1. A button on an interrupt counts three presses for one. Why?<\/li>\n
        2. A sketch works, you add an unrelated line, and a flag set by an ISR stops being noticed. What is missing?<\/li>\n
        3. Why can Serial.print()<\/code> not go in a handler?<\/li>\n
        4. You reconfigure Timer1 and the servo stops working. Why?<\/li>\n<\/ol>\n
          Answers in order: contact bounce, which an interrupt catches every transition of; debounce by time in the handler. volatile<\/code> on the shared flag. Serial transmission depends on interrupts, which are disabled inside a handler. The Servo<\/code> library uses Timer1, and reconfiguring it takes that away.<\/p>\n
          Troubleshooting<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
          Symptom<\/th>\nLikely cause<\/th>\nCheck or fix<\/th>\n<\/tr>\n<\/thead>\n
          Handler never runs<\/td>\nNot on pin 2 or 3<\/td>\nOnly those two on an Uno<\/td>\n<\/tr>\n
          Flag set but never noticed<\/td>\nMissing volatile<\/code><\/td>\nMark every shared variable<\/td>\n<\/tr>\n
          Board hangs when it triggers<\/td>\ndelay()<\/code> in the handler<\/td>\nRemove it<\/td>\n<\/tr>\n
          Serial output garbled or missing<\/td>\nSerial.print()<\/code> in the handler<\/td>\nSet a flag; print in loop()<\/code><\/td>\n<\/tr>\n
          Counter occasionally absurd<\/td>\nMulti-byte read torn<\/td>\nCopy it inside noInterrupts()<\/code><\/td>\n<\/tr>\n
          One press counted several times<\/td>\nBounce<\/td>\nDebounce by time in the handler<\/td>\n<\/tr>\n
          millis()<\/code> frozen<\/td>\nExpected inside a handler<\/td>\nUse micros()<\/code> for short spans<\/td>\n<\/tr>\n
          delay()<\/code> and millis()<\/code> both broken<\/td>\nTimer0 reconfigured<\/td>\nLeave Timer0 alone<\/td>\n<\/tr>\n
          Servo stopped after adding a timer<\/td>\nTimer1 taken<\/td>\nUse a different timer, or the millis()<\/code> pattern<\/td>\n<\/tr>\n
          Works on an Uno, not a Mega<\/td>\nInterrupt pin numbers differ<\/td>\nUse digitalPinToInterrupt()<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
          Next steps<\/h2>\n
            \n
          • Easier first:<\/strong> Timing Without delay()<\/em>, which solves most of what people reach for interrupts to solve.<\/li>\n
          • Related:<\/strong> Making a Button Behave<\/em>, for why bounce matters here.<\/li>\n
          • Next:<\/strong> a rotary encoder or a flow meter, which are the classic jobs for this.<\/li>\n<\/ul>\n
            Sources and attribution<\/h2>\n
            All text and code in this tutorial are original Siratek work.<\/p>\n
              \n
            • ATmega328P datasheet for the external interrupt pins, the timer assignments and the 8-bit register access that makes torn multi-byte reads possible.<\/li>\n
            • Arduino core documentation for attachInterrupt()<\/code>, digitalPinToInterrupt()<\/code> and the timers used by millis()<\/code>, Servo<\/code> and tone()<\/code>.<\/li>\n<\/ul>\n
              No third-party tutorial text, diagrams, photographs or code has been reproduced here.<\/p>\n
              <\/p>\n<\/body>","protected":false},"excerpt":{"rendered":"
              Everything so far has worked by checking: loop() runs round, reads a pin, and decides. That is fine while the loop is quick, and it starts to fail when the loop has real work in it.<\/p>\n","protected":false},"featured_media":0,"template":"","siratek_tutorial_level":[],"class_list":["post-52267","siratek_tutorial","type-siratek_tutorial","status-publish","hentry"],"yoast_head":"\nResponding Immediately with Interrupts - siratek<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"http:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Responding Immediately with Interrupts - siratek\" \/>\n<meta property=\"og:description\" content=\"Everything so far has worked by checking: loop() runs round, reads a pin, and decides. That is fine while the loop is quick, and it starts to fail when the loop has real work in it.\" \/>\n<meta property=\"og:url\" content=\"http:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/\" \/>\n<meta property=\"og:site_name\" content=\"siratek\" \/>\n<meta property=\"og:image\" content=\"http:\/\/siratek.net\/wp-content\/uploads\/2026\/11\/interrupts-and-timers-polling-vs-interrupt.svg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data1\" content=\"7 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"http:\\\/\\\/siratek.net\\\/index.php\\\/tutorials\\\/interrupts-and-timers\\\/\",\"url\":\"http:\\\/\\\/siratek.net\\\/index.php\\\/tutorials\\\/interrupts-and-timers\\\/\",\"name\":\"Responding Immediately with Interrupts - siratek\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/siratek.net\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"http:\\\/\\\/siratek.net\\\/index.php\\\/tutorials\\\/interrupts-and-timers\\\/#primaryimage\"},\"image\":{\"@id\":\"http:\\\/\\\/siratek.net\\\/index.php\\\/tutorials\\\/interrupts-and-timers\\\/#primaryimage\"},\"thumbnailUrl\":\"http:\\\/\\\/siratek.net\\\/wp-content\\\/uploads\\\/2026\\\/11\\\/interrupts-and-timers-polling-vs-interrupt.svg\",\"datePublished\":\"2026-11-01T10:50:48+00:00\",\"breadcrumb\":{\"@id\":\"http:\\\/\\\/siratek.net\\\/index.php\\\/tutorials\\\/interrupts-and-timers\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"http:\\\/\\\/siratek.net\\\/index.php\\\/tutorials\\\/interrupts-and-timers\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"http:\\\/\\\/siratek.net\\\/index.php\\\/tutorials\\\/interrupts-and-timers\\\/#primaryimage\",\"url\":\"https:\\\/\\\/siratek.net\\\/wp-content\\\/uploads\\\/2026\\\/11\\\/interrupts-and-timers-polling-vs-interrupt.svg\",\"contentUrl\":\"https:\\\/\\\/siratek.net\\\/wp-content\\\/uploads\\\/2026\\\/11\\\/interrupts-and-timers-polling-vs-interrupt.svg\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"http:\\\/\\\/siratek.net\\\/index.php\\\/tutorials\\\/interrupts-and-timers\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/siratek.net\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Tutorials\",\"item\":\"https:\\\/\\\/siratek.net\\\/index.php\\\/tutorials\\\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Responding Immediately with Interrupts\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/siratek.net\\\/#website\",\"url\":\"https:\\\/\\\/siratek.net\\\/\",\"name\":\"siratek\",\"description\":\"Your Best Electronic Retail Shop\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/siratek.net\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Responding Immediately with Interrupts - siratek","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"http:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/","og_locale":"en_US","og_type":"article","og_title":"Responding Immediately with Interrupts - siratek","og_description":"Everything so far has worked by checking: loop() runs round, reads a pin, and decides. That is fine while the loop is quick, and it starts to fail when the loop has real work in it.","og_url":"http:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/","og_site_name":"siratek","og_image":[{"url":"http:\/\/siratek.net\/wp-content\/uploads\/2026\/11\/interrupts-and-timers-polling-vs-interrupt.svg","type":"","width":"","height":""}],"twitter_card":"summary_large_image","twitter_misc":{"Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"http:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/","url":"http:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/","name":"Responding Immediately with Interrupts - siratek","isPartOf":{"@id":"https:\/\/siratek.net\/#website"},"primaryImageOfPage":{"@id":"http:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/#primaryimage"},"image":{"@id":"http:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/#primaryimage"},"thumbnailUrl":"http:\/\/siratek.net\/wp-content\/uploads\/2026\/11\/interrupts-and-timers-polling-vs-interrupt.svg","datePublished":"2026-11-01T10:50:48+00:00","breadcrumb":{"@id":"http:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["http:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"http:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/#primaryimage","url":"https:\/\/siratek.net\/wp-content\/uploads\/2026\/11\/interrupts-and-timers-polling-vs-interrupt.svg","contentUrl":"https:\/\/siratek.net\/wp-content\/uploads\/2026\/11\/interrupts-and-timers-polling-vs-interrupt.svg"},{"@type":"BreadcrumbList","@id":"http:\/\/siratek.net\/index.php\/tutorials\/interrupts-and-timers\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/siratek.net\/"},{"@type":"ListItem","position":2,"name":"Tutorials","item":"https:\/\/siratek.net\/index.php\/tutorials\/"},{"@type":"ListItem","position":3,"name":"Responding Immediately with Interrupts"}]},{"@type":"WebSite","@id":"https:\/\/siratek.net\/#website","url":"https:\/\/siratek.net\/","name":"siratek","description":"Your Best Electronic Retail Shop","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/siratek.net\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"}]}},"jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/siratek.net\/index.php\/wp-json\/wp\/v2\/siratek_tutorial\/52267","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/siratek.net\/index.php\/wp-json\/wp\/v2\/siratek_tutorial"}],"about":[{"href":"https:\/\/siratek.net\/index.php\/wp-json\/wp\/v2\/types\/siratek_tutorial"}],"version-history":[{"count":0,"href":"https:\/\/siratek.net\/index.php\/wp-json\/wp\/v2\/siratek_tutorial\/52267\/revisions"}],"wp:attachment":[{"href":"https:\/\/siratek.net\/index.php\/wp-json\/wp\/v2\/media?parent=52267"}],"wp:term":[{"taxonomy":"siratek_tutorial_level","embeddable":true,"href":"https:\/\/siratek.net\/index.php\/wp-json\/wp\/v2\/siratek_tutorial_level?post=52267"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}