On Tue, 30 Dec 1997 09:01:09 -0400 (EDTO) Paul Haas writes: >On Mon, 29 Dec 1997, Mike Keitz wrote: > >> 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. > >If the PORTB pins can change independently, your scheme can still miss >a >change. Say B6 changes causing an interrupt. The interrupt routine >must >read PORTB to reset the comparison latch. This could be handled by placing a software change detector in the ISR. If the value read from PORTB the second time is not the same as the one accepted the first time, the RBIF flag would be set again, or just not cleared, causing another interrupt. Every time PORTB is read or written, the inputs need to be compared to see if they changed (and may not have been detected by hardware). In general the principle is to keep interrupting until the value actually present on the PORTB pins is the same as the one last accepted by the ISR, copied into RAM, and acted upon. If a pin changes, then changes back within the time that the change detect ISR requires, it may not be processed properly. If multiple pins change, there may not be time to process them all in the right order. Very short pulses may fire the hardware or software change detectors, but not remain long enough to be read and recognized by the ISR. These would be problems even if the hardware change detector worked ideally. It only detects changes, it doesn't queue and remember them.