I want to ask about pin change interrupts on a 1284P chip using MightyCore. I have a question about the timing of multiple interrupts on one port. Specifically, if I am servicing a PCINT vector and another pin in the port changes while I am in the ISR, will it generate another interrupt immediately following the one I am servicing?

When I read the datasheet I see:

Bit 2 – PCIF2: Pin Change Interrupt Flag 2 When a logic change on any PCINT[23:16] pin triggers an interrupt request, PCIF2 will be set. If the I-bit in SREG and the PCIE2 bit in PCICR are set, the MCU will jump to the corresponding Interrupt Vector. The flag is cleared when the interrupt routine is executed. Alternatively, the flag can be cleared by writing '1' to it.

When it says that the flag is cleared when the interrupt routine is executed, does that mean when it enters or exits the ISR? If it is at the end, can I clear the flag in the first line of the ISR and allow another pin change to set it again even if it happens before I exit the ISR?

1 Answer 1


When it is entered. The wording is slightly vague but I think "when the interrupt routine is executed" means the commencement of execution. Otherwise multiple pin-change interrupts could be easily missed, depending on how long you took inside the ISR.

I suggest writing a simple test that saves somewhere what the flag is, upon entering the ISR, and check it is cleared already.

I wrote this test for the Uno (which is the same basic architecture):

volatile bool firstTime = true;
volatile byte PCIFR_copy = 0;

ISR (PCINT0_vect)
 // handle pin change interrupt for D8 to D13 here

 if (!firstTime)

 firstTime = false;
 PCIFR_copy = PCIFR;
 }  // end of PCINT0_vect

void setup ()
  pinMode (9, INPUT_PULLUP);
  Serial.begin (115200);
  // pin change interrupt (for D9)
  PCMSK0 |= bit (PCINT1);  // want pin 9
  PCIFR  |= bit (PCIF0);   // clear any outstanding interrupts
  PCICR  |= bit (PCIE0);   // enable pin change interrupts for D8 to D13
  }  // end of setup

void loop ()
  Serial.print ("First time is ");
  Serial.print ((int) firstTime);
  Serial.print (", Flag is ");
  Serial.println ((int) PCIFR_copy);
  delay (1000);
  }  // end of loop

The PCIFR flag was always zero, even after triggering the pin-change interrupt, which shows that it was cleared upon entering the ISR.

will it generate another interrupt immediately following the one I am servicing?

So, based on the above, the answer is yes it will. Upon leaving the ISR one more instruction will be executed and then the next interrupt will be serviced (assuming a higher-priority interrupt doesn't get in first).

Another way of looking at it is that the pin change will always set that flag. Between instructions the processor would check that flag (and the flags for the other interrupts) and for the highest priority interrupt, if that flag is set, then it would clear that flag and then commencing processing that interrupt. That is really the only logical way it could work.

Also, it makes more sense from the design of the processor to clear the flag upon entering the ISR. Apart from the problem that interrupts could be missed if it didn't, when it enters the ISR the processor "knows" which interrupt it is servicing, because it would have checked the PCIFx flag, it would have checked the PCIEx flag (to see if the interrupt should be executed) and it would have then changed the program counter to the appropriate address for that interrupt, after pushing the current program counter onto the stack. This would be the logical time to clear that flag while all this information is in the processor's "head" so to speak.

At the end of the ISR the code simply executes a RTI (Return from Interrupt) instruction which doesn't have associated with it which interrupt it is returning from. Thus it would be hard to clear the flag at that point.

  • Thanks for the quick and thorough (and tested) response.
    – Delta_G
    Jul 15 at 6:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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