Pages: 1 [2]   Go Down
Author Topic: External interrupt fires early?  (Read 1849 times)
0 Members and 1 Guest are viewing this topic.
Grand Blanc, MI, USA
Offline Offline
Faraday Member
**
Karma: 95
Posts: 4094
CODE is a mass noun and should not be used in the plural or with an indefinite article.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

So the cli() and sei() can be dispensed with, and the minimal code to do the job ends up like this, assuming the interrupt is disabled going in:

Code:
   EICRA = _BV(ISC11);          //external interrupt 1 on falling edge
    _delay_loop_1(2);            //allow time for the interrupt caused by setting ISCxx (#include <util/delay_basic.h>)
    EIFR = _BV(INTF1);           //clear the interrupt flag
    EIMSK = _BV(INT1);           //enable external interrupt 1

Edit 26Jan2013: Playing with this again today, it looks like the call to _delay_loop_1() is not needed. Might have gotten myself wrapped around the axle a bit there last night smiley-red

I wonder if External Interrupts work differently by design, accident, or mistake.

Knowing what I know now, it seems it would have to be one of the latter. Maybe someone can think of a reason that it should work this way, but at the moment, I am at a loss  smiley-roll
« Last Edit: January 26, 2013, 01:13:46 pm by Jack Christensen » Logged

MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 212
Posts: 13072
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
...the minimal code to do the job ends up like this...

Nice!
Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 137
Posts: 6805
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Maybe someone can think of a reason that it should work this way
From a HW point of view, I can imagine circuitry that detects falling and rising edges, as well as levels, that would be active all the time (whether or not interrupts are enabled.)  Enabling the pin change interrupt causes an immediate interrupt, because sure enough there HAS BEEN a falling edge some time in the past, even though it wasn't set up to cause interrupts.  I think the timer interrupts work like this too.  If you've been running the timer for a while without paying attention to the pieces that cause interrupts, the "overflow" bit will be set (you never cleared it, after all) and will cause an interrupt as soon as you enable timer overflow interrupts.
Logged

Grand Blanc, MI, USA
Offline Offline
Faraday Member
**
Karma: 95
Posts: 4094
CODE is a mass noun and should not be used in the plural or with an indefinite article.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Maybe someone can think of a reason that it should work this way
From a HW point of view, I can imagine circuitry that detects falling and rising edges, as well as levels, that would be active all the time (whether or not interrupts are enabled.)  Enabling the pin change interrupt causes an immediate interrupt, because sure enough there HAS BEEN a falling edge some time in the past, even though it wasn't set up to cause interrupts.  I think the timer interrupts work like this too.  If you've been running the timer for a while without paying attention to the pieces that cause interrupts, the "overflow" bit will be set (you never cleared it, after all) and will cause an interrupt as soon as you enable timer overflow interrupts.

Good point. And indeed as one example the datasheet has a similar warning that changing the settings for the analog comparator can cause an interrupt. Unless I missed it though, they must have forgotten to mention this one in connection with external interrupts.

I did google around and also searched the forum a bit to see if anyone had noticed this before, and didn't come up with anything. On the one hand that's hard to believe, but being a sort of boundary condition thing, people might just tend to code around it if it makes a difference to them rather than digging into it.

As I also discovered (code in #9 above), the Arduino interrupt functions also cause this spurious interrupt. Do you guys think it's worth raising an issue on? Seems pretty serious to me, I don't expect a freebie interrupt just because I enable them. Simple enough fix, but I was looking at WInterrupts.c and I see it would have to be made in a couple dozen places! smiley-eek
« Last Edit: January 26, 2013, 09:31:03 am by Jack Christensen » Logged

MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

Grand Blanc, MI, USA
Offline Offline
Faraday Member
**
Karma: 95
Posts: 4094
CODE is a mass noun and should not be used in the plural or with an indefinite article.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I see there already is an issue, #510, https://github.com/arduino/Arduino/issues/510
Logged

MCP79411/12 RTC ... "One Million Ohms" ATtiny kit ... available at http://www.tindie.com/stores/JChristensen/

Global Moderator
Dallas
Offline Offline
Shannon Member
*****
Karma: 212
Posts: 13072
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

From a HW point of view, I can imagine circuitry that detects falling and rising edges, as well as levels, that would be active all the time...

But the interrupt flag can be cleared when the interrupt is enabled.  I tested either a timer related interrupt or the pin change interrupts for that behaviour (can't remember which or why) and the flag is indeed cleared when the interrupt is enabled.

Out of paranoia, I have a tendency to always clear the flag.

I'm starting to suspect the behaviour is by-design.  Working the way it does eliminates a race condition in applications that have to be able to enable/disable external interrupts (an RTOS might need to do that).
« Last Edit: January 27, 2013, 04:24:53 am by Coding Badly » Logged

Pages: 1 [2]   Go Up
Jump to: