Exact match. Not showing close matches.
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?
|Joe Jansen <mit.edu> wrote: piclist
> 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
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.
=== Andrew Warren - ix.netcom.comfastfwd
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.
On 4/12/05, Joe Jansen <gmail.com> wrote: joe.jansen
On 4/13/05, Ben Hencke <gmail.com> wrote: brainstar
> 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.
err, that should read as "movwf gpio". Moving W into the GPIO.
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!
On 4/13/05, Andrew Warren <ix.netcom.com> wrote: fastfwd
More... (looser matching)
- Last day of these posts
- In 2005
, 2006 only
- New search...