0

I'm using an Arduino Mega and four of its interrupts. Each interrupt is only used to start/stop a timer, depending if it's rising or falling, so effectively runs the same function. Does anyone know if theres a way to differentiate between which interrupt has been triggered? This way I can attach them all to the same ISR and just start/stop different timers.

Thanks, Shaun

2 Answers 2

0

The only sure-fire way of knowing which interrupt triggered your ISR is to examine the GPIO pin that the interrupt is associated with.

You need to use CHANGE interrupts so that you can keep track of the state of the pins - both HIGH and LOW. When you get an interrupt and read all the GPIO pins you have tied to the ISR you can then compare their values to the previously stored values. Any pins that have changed since the last ISR (or a pre-defined initial state) can be processed and handled accordingly.

Yes, it adds a certain amount of overhead to your code, and using digitalRead() may not be the most efficient way of doing it. Instead you may want to use direct port access to read the pin's state directly.

1
  • Thanks, I will have to look into direct port access as I haven't done this before. May 23, 2016 at 14:36
0

Assuming that by "Mega" you mean the Mega 2560, see sections 15.2.4 and 15.2.5 of the 2/2014 datasheet referring to the External Interrupt Flags and Pin Change Interrupt flags:

When an edge or logic change on the INT7:0 pin triggers an interrupt request, INTF7:0 becomes set (one). If the I-bit in SREG and the corresponding interrupt enable bit, INT7:0 in EIMSK, are set (one), the MCU will jump to the interrupt vector. The flag is cleared when the interrupt routine is executed. Alternatively, the flag can be cleared by writing a logical one to it. These flags are always cleared when INT7:0 are configured as level interrupt.

It is not clear from the above when specifically "The flag is cleared when the interrupt routine is executed" happens. It wouldn't be much use if it happened on ISR entry so I'll take a guess that it happens on return from interrupt, in which case the flags would be available to read in the ISR. An experiment would be in order, here. These flag registers are known to the compiler as EIFR and PCIFR, respectively.

5
  • My reading of the datasheet (see section 7.8) makes me think the flags are cleared at ISR entry. Only the GIE is enabled during RETI (it specifically mentions it) and it reads like it's at the start of the ISR that the flag is cleared: "The first type is triggered by an event that sets the Interrupt Flag. For these interrupts, the Program Counter is vectored to the actual Interrupt Vector in order to execute the interrupt handling routine, and hardware clears the corresponding Interrupt Flag.".
    – Majenko
    May 23, 2016 at 13:15
  • For the RETI it says: "A return from an interrupt handling routine takes five clock cycles. During these five clock cycles, the Program Counter (three bytes) is popped back from the Stack, the Stack Pointer is incremented by three, and the I-bit in SREG is set." - So yes, it is very very woolly in its wording, but I would lean towards the interrupt flags not being available to read in the ISR, which is a bit poor really. Personally I prefer the Microchip method where it is up to the user to manually clear the interrupt flag when it is finished with.
    – Majenko
    May 23, 2016 at 13:16
  • Thanks for the response, I'll test this method and post whether or not I can get it to work. May 23, 2016 at 14:34
  • @Majenko: The only reason I hold out any hope at all that they'd be readable within the ISR is that someone designed those registers to be readable, which would be pointless if it is cleared during ISR vectoring (not to say it wasn't done that way!). The program would only ever be able to read zero.
    – JRobert
    May 23, 2016 at 16:33
  • You can read them outside an ISR when the interrupt is disabled. You can use it like a flag that is set by hardware which you can then check as and when you want. You get the notification but you don't have to respond immediately.
    – Majenko
    May 23, 2016 at 16:34

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.