I have four pins set up to trigger interrupts. They are configured using the following attachInterrupts(.. ) calls:
attachInterrupt(digitalPinToInterrupt(FL_MTR_SNSE), pinISRFL, FALLING);
attachInterrupt(digitalPinToInterrupt(FR_MTR_SNSE), pinISRFR, FALLING);
attachInterrupt(digitalPinToInterrupt(RL_MTR_SNSE), pinISRRL, FALLING);
attachInterrupt(digitalPinToInterrupt(RR_MTR_SNSE), pinISRRR, FALLING);
The four interrupt handlers (pinISRFL, .. pinISRRR) get called appropriately. I.e., the code works that's not the problem.
If I look at: https://www.pjrc.com/teensy/interrupts.html#names I see that behind the scenes there's likely only one interrupt vector allocated for pin interrupts. Likely one of the PCINT0_vect or PCINT1_vect. But I'm configuring four interrupt sources to four separate interrupt handlers. This suggests that behind the scenes there's a single pin change ISR that's looking up what pin has changed and matches it to the handler defined by the attachInterrrupt( .. ) call and then calling the correct handler.
I'm asking if my understanding is correct. I don't like code that does magic stuff, and I would prefer to understand how it works. I also have interrupts coming in rather fast. Will this magic code do the right thing if there are multiple pin changes very close together? As an ISR, it's in the fast path. How optimal is this code?
Thx, tom.c
attachInterrupt(digitalPinToInterrupt(FL_MTR_SNSE), pinISRFL, FALLING);
attachInterrupt(digitalPinToInterrupt(FR_MTR_SNSE), pinISRFR, FALLING);
attachInterrupt(digitalPinToInterrupt(RL_MTR_SNSE), pinISRRL, FALLING);
attachInterrupt(digitalPinToInterrupt(RR_MTR_SNSE), pinISRRR, FALLING);
The four interrupt handlers (pinISRFL, .. pinISRRR) get called appropriately. I.e., the code works that's not the problem.
If I look at: https://www.pjrc.com/teensy/interrupts.html#names I see that behind the scenes there's likely only one interrupt vector allocated for pin interrupts. Likely one of the PCINT0_vect or PCINT1_vect. But I'm configuring four interrupt sources to four separate interrupt handlers. This suggests that behind the scenes there's a single pin change ISR that's looking up what pin has changed and matches it to the handler defined by the attachInterrrupt( .. ) call and then calling the correct handler.
I'm asking if my understanding is correct. I don't like code that does magic stuff, and I would prefer to understand how it works. I also have interrupts coming in rather fast. Will this magic code do the right thing if there are multiple pin changes very close together? As an ISR, it's in the fast path. How optimal is this code?
Thx, tom.c