Many processors / µCs / dev-platforms (BeagleBoard, Arduino,...) use interrupts.
These can be triggered by the detection of:

  • HIGH level
  • RISING edge
  • CHANGING level (either FALLING or RISING edge)
  • FALLING edge
  • LOW level

Now either of two things must be true:

  1. FALLING and LOW (/ RISING and HIGH) are virtually the same
  2. When a LOW (/HIGH) level is applied over a non-trivial time, the controller is stuck repeating the interrupt service routine over and over

Both of these don't make sense to me:

The first cannot be true, since it would be totally useless to make the difference in the first place then.

So if the second one is true: how could this be useful? What application is there that is not better off with a combination of RISING and FALLING instead of HIGH?

Research so far:

  • 1
    \$\begingroup\$ 2. Why will it be stuck ? You can have a kind of lock feature that will trigger the interrupt only one time until another condition is true (for instance if you trigger at LOW level, it will trigger one time and will wait that you pass to HIGH level to re-engage the trigger) \$\endgroup\$ – zeqL Oct 14 '14 at 7:55
  • \$\begingroup\$ true that, however I don't see how this approach is not the same as using FALLING. Constant polling of other conditions might as well be done in a program-only loop that is started by the interrupt. \$\endgroup\$ – Mark Oct 14 '14 at 7:57
  • \$\begingroup\$ 1. the difference between edge and level may be (to be confirmed according to each datasheet) that you'll trigger directly when you pass the high/low level limit for the edge and for the level you'll wait a little that the level is established before triggering. \$\endgroup\$ – zeqL Oct 14 '14 at 8:00
  • \$\begingroup\$ @zeqL yeah, that was explained in one of the threads I linked. One datasheet stated that the purpose of the earlier triggering of the edge-interrupts was to allow the input to be closed before the device reacts, in case that had effects on the input-signal. \$\endgroup\$ – Mark Oct 14 '14 at 8:07

Level triggered (high or low) can allow the source to say "nevermind" or to keep the trigger active until the ISR gets around to it. Interrupt latency is not guaranteed on a single core with multiple triggers, though it's usually pretty fast. Generally, the signal for a level-triggered interrupt is itself edge-triggered and you have to clear it in the ISR or else you'll come right back into it again.

As Ignacio said, level triggered can also do something continuously while active, though you should write your software to not get stuck in an "interrupt loop". Not getting to your main code can be somewhat difficult to debug.

Edge triggered is good for things that happen once on some event. If the event happens again, then your response will happen again, so you'll need to be careful about repeated events like switch bounce.


As an addition to the other answers, another look from a practical perspective:

The level triggered interrupt is an indication that a device needs attention. As long as it needs attention, the line is asserted. A device may want the master to clock data out of the devices buffer. It may need immediate attention to prevent buffer overflow (so using interrupt is a good choice vs polling) but it wouldn't be practical if the device has to keep switching edges while the buffer still contains data. The master does its processing as fast as possible, clears the interrupt flag when ready and immediately recognizes that there is more to do.

Edge triggered interrupt is an event notification. When some particular thing happens, the device generates a pulse on the interrupt line and its done (fire and forget). The master just takes notice of it and goes on.

My point is, there is practical use for both.


Edge sensitive interrupt only fires when it detects appropriate edge. That means, only single interrupt will happen. If interrupt is enabled AFTER transition it will not react and message ia lost. Usable when certain event must be captured.

Level sensitive interrupt will happen whenever it will be enabled and appropriate level present. Thus request will be serviced even if interrupt is enabled some time later. Furthermore, multiple devices can be attached to single interrupt line. Usable when state or condition is important.

Your nr. 2 statement is correct. Either interrupt must be disabled or level cause serviced.

In other words, you use edge sensitive when you are waiting for something and level sensitive when something might be already waiting for you.

  • \$\begingroup\$ That's something I hadn't considered. \$\endgroup\$ – Mark Oct 20 '14 at 5:29

Level triggering is useful when a continuous action requires firing off repeated events, e.g. ringing a bell while an alarm is active. In this case the ISR would be responsible for energizing and deenergizing a solenoid only once; the fact that the interrupt trigger is still present would be responsible for extending the ring duration.

  • 2
    \$\begingroup\$ Yes, but it's generally bad practice to do it that way. You want to leave some time for the main code to do its thing, even if it's only to reset a watchdog or something else simple. I would detect both edges and set/clear a bit that makes it ring or not. \$\endgroup\$ – AaronD Oct 14 '14 at 17:58
  • \$\begingroup\$ @AaronD that is exactly what I referred to as "being stuck in the ISR" and why I favored the combined use of RISING and FALLING. \$\endgroup\$ – Mark Oct 20 '14 at 5:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.