Kvel
Junior Member level 1
- Joined
- Apr 20, 2011
- Messages
- 17
- Helped
- 0
- Reputation
- 0
- Reaction score
- 0
- Trophy points
- 1,281
- Activity points
- 1,403
Dear all,
Beginner here.
I'm programming an LPC2368 board (ETT CP-JR ARM7) and am setting up P2.0 - P2.7 as GPIOs with rising edge interrupts. As far as the user manual suggests, when an interrupt occurs it will generate a VICVectAddr17, which is shared by EINT3 and all GPIO interrupts.
Since I'll need to service each pin interrupt differently, I'll need to find which pin caused the interrupt to service it properly. Now, as I'm understanding it, a simple if(FIO2PIN0 & 0x01) would tell me if P2.7 is high, and thus probably the one that generated the interrupt.
My issue is that, having multiple if() checks for the various pins, I suspect there will be a possibility of a situation arising where P2.6 generates an interrupt, is serviced properly, then P2.7 generates an interrupt. When the loops is checking for high bits, P2.6 may still be high from the previous already serviced interrupt, and if I check for the interrupt pin using the aformention if(FIO2PIN0 & 0x02) method, the P2.6 ISR loop might be called again unnecessarily.
Is there a way to go around this and have a cleaner way of checking the interrupts? The interrupt register IOIntStatus only states which port the interrupt came from, so is not really of any help to determine which pin produced the interrupt.
An idea that I'm considering is making the interrupts double-edge triggered (if at all possible, but the manual doesn't seem to exclude it) and using a software flag as a state machine of sorts to eliminate duplicate ISR calls before a signal falls back down.
Any input, suggestions or comments would be greatly appreciated.
Beginner here.
I'm programming an LPC2368 board (ETT CP-JR ARM7) and am setting up P2.0 - P2.7 as GPIOs with rising edge interrupts. As far as the user manual suggests, when an interrupt occurs it will generate a VICVectAddr17, which is shared by EINT3 and all GPIO interrupts.
Since I'll need to service each pin interrupt differently, I'll need to find which pin caused the interrupt to service it properly. Now, as I'm understanding it, a simple if(FIO2PIN0 & 0x01) would tell me if P2.7 is high, and thus probably the one that generated the interrupt.
My issue is that, having multiple if() checks for the various pins, I suspect there will be a possibility of a situation arising where P2.6 generates an interrupt, is serviced properly, then P2.7 generates an interrupt. When the loops is checking for high bits, P2.6 may still be high from the previous already serviced interrupt, and if I check for the interrupt pin using the aformention if(FIO2PIN0 & 0x02) method, the P2.6 ISR loop might be called again unnecessarily.
Is there a way to go around this and have a cleaner way of checking the interrupts? The interrupt register IOIntStatus only states which port the interrupt came from, so is not really of any help to determine which pin produced the interrupt.
An idea that I'm considering is making the interrupts double-edge triggered (if at all possible, but the manual doesn't seem to exclude it) and using a software flag as a state machine of sorts to eliminate duplicate ISR calls before a signal falls back down.
Any input, suggestions or comments would be greatly appreciated.