On Mon, 29 Dec 1997 00:35:37 -0400 Paul Haas <paulh@hamjudo.com> writes:

>Or, if you have some PORTA pins available, connect them in parallel
>with
>the PORTB pins.

I don't see any advantage to doing this.  Software will always read the
PORTB pins correctly.  Though this read could cause a change interrupt to
be missed, it would be at the exact moment that the software change
detector is looking for it.  If there are extra PORTA pins, use them for
I/O so PORTB doesn't need to be accessed.  Kalle's idea to control PORTB
outputs in simulated open-collector mode using the TRIS register is a
good one.

For combined hardware/software change detection, the ISR should read the
port (to reset the hardware change detector) and save the last accepted
value of the pins in RAM.  The software change detector (invoked after
every access of the port for other reasons) would read PORTB and force
the interrupt directly if different from the accepted value in RAM.  The
interrupt should be disabled during a software compare to prevent
multiple interrupts.  It should be possible to force a change interrupt
by directly setting the flag bit.

Of course, the latency to detect a change becomes large and variable
using this workaround.  It may help to organize things to only use the
hardware change detector during parts of the program that won't disrupt
it, and software detection at other times.