On Wed, 24 Dec 1997 10:26:16 +0000 Alan Hall writes: >What is the problem with RB change interrupts, other than the caution >mentioned in the data sheets regarding mixing of polling with >interrupt >detection? Maybe this is a little harsh to say never to use it. Because of the way it is implemented, there are circumstances that can cause a change to occasionally be missed (no interrupt generated). In some applications, occasional missed changes may be OK. The change detector is implemented with a new register which holds the *last value read* from PORTB. The current state of the pins is xor'd with this register to detect a change. The register is not directly accessable. If the port is being read at the exact instant that an external change occurs, the change detector won't trigger. This seems easy to work around at first, but realize that the architecture of the PIC causes some extra reads. For example, a movwf PORTB reads the port first, discards the value, then writes the value from W. So attempting to use the other 4 bits of the port in any way could prevent changes from being detected. In older silicon, a RETURN would also access PORTB (the opcode also executed as MOVWF PORTB,w which would ordinarily do nothing). I think that additional logic has been added to prevent this. The CLRW 'instruction' used to be encoded as CLRF INDF,w which would be trouble if FSR pointed to PORTB. Newer assemblers encode it as CLRF 3,W. These 2 problems have been quietly dealt with by Microchip. Keeping all this in mind, it is still possible to work around the limitations of the change detector and use the RB change interrupt in a program. The primary consideration would be not to read or write PORTB except as a response to a detected change.