Quote Originally Posted by Darrel Taylor View Post
When using ON INTERRUPT, the GIE bit is controlled by PBP.
Any attempts to change it manually will cause problems.
I didn't understand that when I read PBP manual section dedicated to INTERRUPTS.

And the IOC port change interrupt, doesn't save the state of the PINs for you. If you're just getting a quick pulse, it's possible that the pulse is gone by the time you try to display the pins, or determine who shot you with what.

The very first statement in the interrupt handler should read PORTA and save the value in a variable. Then use that variable throughout your handler, instead of the pins themselves.
I understand but then I need to poll the pin that triggered the int because I'm reading a PWM signal on a Infrared Sensor (that pulls the pin LOW) that looks like:
a header (1200us ON, 600us OFF, 1200us ON, 600us OFF), then 8 times (8bits) either 600us ON or OFF followed by 600us OFF spacers, then a 600us OFF (trailer).

By the way, is the following indexed byte variable bit accessing "variable.0(indexvariable)" correct? Everyone on the forum does not seem to agree.

a VAR BYTE
...
a = porta
for i = 0 to 5
LCDOUT #a.0(i)
next i




The IOC interrupt also triggers on any pins transition from low to high, or high to low.
But your program is only looking for HIGH states.
In fact, pins are HIGH because of the WPU, I'm looking for HIGH->LOW transitions.
Am I wrong about the use of WPU?

By the way, something strange in PIC16f684 datasheet: to enable individual WPU, OPTION_REG bit 7 has to be "0"... Strange, isn't it? Shouldn't the bit be set instead of cleared?


If it makes it all the way through the handler before the pulse goes away, then you will get another interrupt at the end of the input pulse. This time it'll look like all the pins are at their default state, as if nothing changed. You'll need to account for the second interrupt, somehow.

In my routine, there is a block that will scan the input on the triggering pin for the duration of the expected signal (about 14.4ms) so the interrupts will not be re-enabled until the 14.4ms duration has elapsed. Efter that, yes, another interrupt may occur if some signal arrives on a pin and the int handler will check if the signal has the right structure, duration and if the data carried is valid. I hope my algorythm was fine.

You're also clearing the interrupt flag in 2 places in the handler, one at the beginning, and another at the end of the handler. The first one attempts to clear the flag, before PORTA has been read. But it won't clear the flag, because the mismatch condition still exists.
Read PORTA first, then clear the flag.
Right.

At the end of the handler, it clears the flag, but doesn't read PORTA.
With things like LCDOUT's in the handler, it can take quite a while to complete the handler, and the PINs may have changed in the mean time, so it would be necessary to read PORTA again before clearing the flag.

hth,
You are geat, thank you so much for your explanations.