5

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:

Mark
  • 185
  • 1
  • 9
  • 1
  • 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)
  • – zeqL Oct 14 '14 at 07:55
  • 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. – Mark Oct 14 '14 at 07:57
  • 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.
  • – zeqL Oct 14 '14 at 08:00
  • @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. – Mark Oct 14 '14 at 08:07