On Tue, 12 Aug 2003, Jan-Erik Soderholm XA (TN/PAC) wrote:

> If you do *not* clear the "mismatch condition"
> (buy reading the GPIO), and still tries to
> clear the GPIF, the GPIF flag will be re-set
> one or two instructions cycles later. So it's
> a constant interrupt.

I seem to recall that's what I saw.

> Also note that there is a race condition
> (as noted in the grey box on side 20
> of the data sheet) thay says that, if you
> are unlucky, you can miss a port change
> if it occures in the "start of th 2 cycle"
> when reading the GPIO port. The GPIF flag
> might not be set.
>
> It doesn't specify any workaround, but I'd
> guess that you could re-read the GPIO port
> (first once to clear the mismatch condition,
> then a second time to see if there was a
> pin change during the first read) in your code.

In my case, it's moot - I wrote the function that uses the port so that it
can deal with a spurious pin change indication.  It just means the chip
stays out of sleep mode for an extra second or so.  I just use GPIF to
wake up from sleep mode, then check the port to see what happened - if
nothing happened, go back to sleep.  Of course this would not work for
everyone.

Dale
--
It's a thankless job, but I've got a lot of Karma to burn off.
PicoKeyer is available for the Rock-Mite! http://www.hamgadgets.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.