Post by thread:[PIC]:12F675 Interrupt-On-Change

Hi all, I am reading through the datasheet in the 12F629/675 reading, specifically, the info in section 3.2.2 on page 21. There is a note that states: 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. elsewhere in that section, it says that: For enabled interrupt-on-change pins, the values are compared with the old value latched on the last read of GPIO. The 'mismatch' outputs of the last read are OR'd together to set, the GP Port Change Interrupt flag bit (GPIF) in the INTCON register. and goes on to warn that you have to read or write the GPIO register before you can clear the GPIF flag, since the GPIF will continue to be set every time the comparison is made to the old value latch. As I am currently away from home, I was wondering if anyone could offer insight: Is the note (the first copied block) stating, basically, that there is a 25% chance that I will miss any interrupt on change event? Or is it stating that the timing could be off by an instruction clock cycle, but will still occur the next time the comparison is made? Thanks! --Joe Jansen

Joe Jansen <spam_OUTpiclistTakeThisOuTmit.edu> wrote: > I am reading through the datasheet in the 12F629/675 reading, > specifically, the info in section 3.2.2 on page 21. There is a note > that states: > > 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. > > Is the note .... stating, basically, that there is a 25% chance that I > will miss any interrupt on change event? Or is it stating that the > timing could be off by an instruction clock cycle, but will still occur > the next time the comparison is made? Neither, Joe... Although its meaning is closer to your first guess than your second. The note says that if an I/O-pin change occurs at just the right moment DURING THE EXECUTION OF AN INSTRUCTION THAT READS THE I/O PORT, the interrupt flag may not be set. In other words, if your code never accesses the I/O port while interrupts are enabled, you won't miss any interrupts... And if you happen to have particularly unfortunate pin-change timing coupled with code that accesses the I/O port all the time, you could potentially miss ALL I/O-pin-change interrupts. Note that I wrote "accesses", not "reads". As it turns out, even writes to the I/O port perform a dummy read operation during Q2, so ANY operation on the port can cause interrupts to be missed... Which is why it's often best to rely on the I/O-pin-change interrupt only for waking the PIC from sleep mode. Some newer, larger PICs don't have this bug; I don't know if there are any 12Fxxx parts without it, though. -Andy === Andrew Warren - .....fastfwdKILLspam@spam@ix.netcom.com

If you do anything to the GPIO with a read (or R-M-W) instruction (there is some debate as to exactly what instructions count for this) there is a chance you will miss an IOC if it occurs while that instruction is executing. I have had luck when doing heavy movfw gpio in a tight loop and still reading button presses with IOC. I think if I was reading from GPIO or doing bsf directly on GPIO, it would be another story. - Ben On 4/12/05, Joe Jansen <joe.jansenKILLspamgmail.com> wrote: {Quote hidden}> > Hi all, > > I am reading through the datasheet in the 12F629/675 reading, > specifically, > the info in section 3.2.2 on page 21. There is a note that states: > > 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. > > elsewhere in that section, it says that: > > For enabled interrupt-on-change pins, the values are > compared with the old value latched on the last read of > GPIO. The 'mismatch' outputs of the last read are OR'd > together to set, the GP Port Change Interrupt flag bit > (GPIF) in the INTCON register. > > and goes on to warn that you have to read or write the GPIO register > before > you can clear the GPIF flag, since the GPIF will continue to be set every > time the comparison is made to the old value latch. > > As I am currently away from home, I was wondering if anyone could offer > insight: Is the note (the first copied block) stating, basically, that > there > is a 25% chance that I will miss any interrupt on change event? Or is it > stating that the timing could be off by an instruction clock cycle, but > will > still occur the next time the comparison is made? > > Thanks! > > --Joe Jansen >

Ok, Thanks! Fortunately, this application will just sit in a loop, waiting for one of 3 pins to change, then react, so it shouldn't be an issue! --Joe Jansen On 4/13/05, Andrew Warren <EraseMEfastfwdspam_OUTTakeThisOuTix.netcom.com> wrote: {Quote hidden}> > > Neither, Joe... Although its meaning is closer to your first guess > than your second. > > The note says that if an I/O-pin change occurs at just the right > moment DURING THE EXECUTION OF AN INSTRUCTION THAT READS THE I/O > PORT, the interrupt flag may not be set. In other words, if your > code never accesses the I/O port while interrupts are enabled, you > won't miss any interrupts... And if you happen to have particularly > unfortunate pin-change timing coupled with code that accesses the I/O > port all the time, you could potentially miss ALL I/O-pin-change > interrupts. > > Note that I wrote "accesses", not "reads". As it turns out, even > writes to the I/O port perform a dummy read operation during Q2, so > ANY operation on the port can cause interrupts to be missed... Which > is why it's often best to rely on the I/O-pin-change interrupt only > for waking the PIC from sleep mode. > > Some newer, larger PICs don't have this bug; I don't know if there > are any 12Fxxx parts without it, though. > > -Andy > > === Andrew Warren - fastfwdspam_OUTix.netcom.com > >