PIC interrupt-on-change problem

[weazuul]

I tried to make a program for the PIC 12F629 using interrupts and i have almost done it all, it works just fine with one exception IOC(interrupt-on-change). When it goes in the interrupt service routine it treats the apropiate interrupt but it doesn't change the GPIF flag back to 0 in the IOC routine unless the pin status gets back to the status it had before the interrupt(the interrupt was generated by a pass from 0 to 1 on pin3 but unless i change it's state back to 0 the GPIF will keep being set to 1 regardless of what i set it). What can i do because i need to generat an interrupt when the pin changes state and then wait and see how long it passes untill the pin changes state again.
THX

[rjet]

Interrupts can be tricky and take a lot of time to debug. But check that the port is read in the ISR (ex: btfss portb, 0) as the I/O pin is compared to the input latch in the chip. When a mismatch is found, the interrupt-on-change flag is set, and an interrupt generated. You must now read in that port, which will put the I/O pin state into the latch. Then there is no mismatch between the I/O pin and the latch. Also make sure to clear the interrupt flag before leaving the ISR.

[Mr.RC-CAM]

...the interrupt was generated by a pass from 0 to 1 on pin3 but unless i change it's state back to 0 the GPIF will keep being set to 1 regardless of what i set it)Actually, the GP4 (pin-3) interrupt will occur on the 0-to-1 edge, as well as the follow up 1-to-0. That's two interrupts per external signal excursion.

You will need to add some code to ignore the second one. You can just check the logic level upon interrupt entry to determine if the logic state is the one you wish to act upon. Or, use the GP2 (INT) Interrupt -- it has hardware edge masking. Be sure to clear the flags and exit with a RETFIE.

RC-CAM

[AndyKunz]

Warning - you will miss about 25% of the edges. There's a bug in the IOC hardware that's been there for ages and is well-documented. It used to be an errata, now it's a "feature."

You can't use the port for any polled inputs or outputs if you are using IOC mode.

Andy

[weazuul]

Thx guys.
@ rjet
Reading the port before clearing the flag did the trick. If i finish this i will post the code. It's for a IR remote control and written in C so it cand be easily ajusted.

@Mr.RC-CAM
I am interested in only one change 1-to-0 or 0-to-1 but i will be realy carefull with this as i intend to do some error handeling and failsafes

@AndyKunz
Thanks for the info. I will keep that in mind

[JMP_blackfoot]

Warning - you will miss about 25% of the edges. There's a bug in the IOC hardware that's been there for ages and is well-documented. It used to be an errata, now it's a "feature."

You can't use the port for any polled inputs or outputs if you are using IOC mode.

From the 12F629 datasheet :
"If a change on the I/O pin should occur when the read operation is being executed (start of the Q2 cycle), then the GPIF interrupt flag may not get set".
Much less than 25% of transitions are actually lost - note that the datasheet says "start of the Q2 cycle", not "at any time during..." -, but still enough to cause trouble in some cases.
I have used a software trick to eliminate the effect of missed transitions, by checking that each detected transition is of the opposite direction to the previous one.
In the case of my JMP Rxcombo, depending on the actual transmitter frame rate, missed transitions caused a predictable periodic small glitch of one of the actuator channels, which has been eliminated in this manner.

[AndyKunz]

How long does "the start of the Q2 cycle" last? Does it overlap with Q1? Does it last 50% of Q2? Does it need to be aligned within the rise of the of the oscillator? Notice how Microchip weasel-worded it?

25% is possible, depending upon your clock speed and the rise time of the input. My own tests show that the problem is manifested when the oscillator rises while the signal is within the undefined region for the input (1.5-3.5V).

It is important to know what your input signals look like, and condition them to reduce the likelihood of an error with respect to your oscillator speed.

I have implemented firmware workarounds as well for it. When you know what the data should look like, it's easy to build a filter as well.

Andy

[JMP_blackfoot]

I have implemented firmware workarounds as well for it. When you know what the data should look like, it's easy to build a filter as well.
That was my point. The inbuilt bug of Microchip controllers is fairly easy to get around, once one knows how it occurs.

[k.j.ren]

all
I have same problem, gpio 3 some time no interrupt generated,Why?
please check software and wave photo.

[JMP_blackfoot]

From the 12F629 datasheet :
"If a change on the I/O pin should occur when the read operation is being executed (start of the Q2 cycle), then the GPIF interrupt flag may not get set".
This is when a GP3 interrupt may be missed.

[weazuul]

I have used a software trick to eliminate the effect of missed transitions, by checking that each detected transition is of the opposite direction to the previous one.


I have implemented this and can only say as much about it as I have simulated with PIC Simulator IDE that it works just fine as it finds the missed IOC.
THX guys

[JMP_blackfoot]

A simple application of the principle that what goes up must come down... :)

Using GPIO,2 external interrupt instead of IOC ensures that no transition is missed. But this loses one output since GPIO,3 is input only....