Ok, Thanks!

Fortunately, this application will just sit in a loop, waiting for one of 3=
=20
pins to change, then react, so it shouldn't be an issue!

--Joe Jansen

On 4/13/05, Andrew Warren <fastfwd@ix.netcom.com> wrote:
>=20
>=20
> Neither, Joe... Although its meaning is closer to your first guess
> than your second.
>=20
> 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.
>=20
> 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.
>=20
> Some newer, larger PICs don't have this bug; I don't know if there
> are any 12Fxxx parts without it, though.
>=20
> -Andy
>=20
> =3D=3D=3D Andrew Warren - fastfwd@ix.netcom.com
>=20
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist