You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Prevously, when attachInterrupt was called but the (previously
configured or default) interrupt condition has already occured while the
interrupt was (still) detached, the interrupt triggers immediately once
after attaching, even though the condition didn't occur then.
This fixes this problem by clearing any pending interrupts after
configuring the interrupt level, but before enabling it.
Note that some libraries actually depend on this broken behaviour. Paul
Stoffregen wrote:
> As a matter of principle, I agree, this is a bug. In practice, this
> behavior really is needed by libraries that use attachInterrupt(),
> but need to temporarily prevent the interrupt from occurring while
> they do lengthy operations which shouldn't globally disable
> interrupts. When they reenable the interrupt, the desired behavior
> of course it to immediately respond to any pending interrupt that
> was detected during that disabled time.
However, now that the enableInterupt and disabledInterrupt functions are
available, these libraries can use those instead of relying on this bug
in attachInterrupt.
On the SAM core, the only way to clear pending
interrupt flags is to read the Interrupt Status Register.
However, this always clears _all_ flags at once. To not lose
any interrupts, after reading the status register to clear it, interrupt
handlers for any pending interrupts are called.
This does mean that if attachInterrupt is called with interrupts
globally disabled, interrupt handlers are called nonetheless. This seems
to be the lesser of three evils:
- Not clearing the status register can cause a bogus
interrupt shortly after calling attachInterrupt (this
happened in earlier Arduino versions).
- Reading the status register but not running interrupts can
cause interrupts to be missed when attachInterrupts is
called with interrupts disabled (and depending on timing
probably also with them enabled).
- Running the handlers (as now) causes interrupt handlers to
run while calling attachInterrupt with interrupts
disabled.
This fixes #510.
0 commit comments