GPIO interrupts in both directions

[yyrkoon 250]

So I'm reading the users guide and see that you can only set one directions for interrupt pin transitions. Or am I missing something ?

 

One thing did occur to me, but I'm not sure yet if it's a good idea or not. I could just set the transition to one direction, then when that transition is detected, I could switch that pins transition direction. Good idea or not ?

 

I need this functionality because I need both transition directions to set or clear a bit flag.

[enl 226]

That works fine. Eats a couple cycles, but probably about the same as if you needed to test state (and possibly be bamboozled by a short pulse) in the ISR. This is how I coded a quadrature decoder a few years ago for a positioner.

[yyrkoon 250]

This is what I had in mind.

. . .
P1IES |= (BIT5);
. . .
_attribute__( (interrupt (PORT1_VECTOR)) )
void PORT1_ISR(void)
{
        if(P1IFG & BIT5){
                flags ^= BITx;
                P1IES ^= (BIT5);
                P1IFG &= (~BIT5);
        }
}

But actually, I only need to check this pins state under certain conditions, so maybe a . . .

if(P1IN & BIT5) {
        . . .
}

would be better ?

[yyrkoon 250]

My main concern is that I have more than one interrupt happening. one is a timer interrupt and will take priority. But this pins transition interrupt is something I do not expect to happen very often. So . . . Maybe I'm over thinking things ?

 

I think I got it worked out everyone. Since I only need to know the pins state in two very specific situations, I think polling would probably be fine. Especially since these two specific conditions should not be happening very often.

[NurseBob 106]

After a bit of wandering through various posts regarding Energia and interrupts, it does look like polling is a solution.  This is one of the areas where a standard C approach would be almost trivial and very conservative of battery...

[Clavier 34]

Toggling the PxIES bit once has a race condition, when the signal switches again before the interrupt has run. You also have to check the current state of the PxIN bit to ensure that PxIES catches the next edge.

 

But the easiest way to get interrupts for both edges is to route the signal to two pins.

[yyrkoon 250]

Toggling the PxIES bit once has a race condition, when the signal switches again before the interrupt has run. You also have to check the current state of the PxIN bit to ensure that PxIES catches the next edge.

 

But the easiest way to get interrupts for both edges is to route the signal to two pins.

Unfortunately using two pins for the current project is unacceptable. However, this interrupt would occur only very rarely, and then once triggered would only need to be tested for every 60 seconds until the operating conditions return to "normal" So, in this context, I could just test PxIN & BITx every 60 seconds, when the code is running in "abnormal mode". So, I do not need an interrupt after all, but talking with you all helped me realize this.

[abecedarian 330]

never mind

[USWaterRockets 57]

Does changing the interrupt trigger to the current state of the pin generate an interrupt? If so, then you would have to be careful when toggling the trigger state because doing so could set the flag and cause another interrupt as soon as you leave the interrupt handler. This would only happen if the pulse on the pin were shorter than the time it took you to interrupt and flip the trigger condition. You can probably work around this by checking the pin state before leaving the interrupt and setting the trigger level accordingly.