Myke and Neil seem to be asking much the same question this afternoon, so
just one reply to both.  :-)

On Wed, 12 Jun 1996, myke predko wrote:

> Now, I'm curious to know if I can use other PORTB bits for Input.  ie will a
> "movf PORTB, w" instruction to poll other bits cause a problem with port
> change bits?

In earlier PICs with the interrupt on change (again, sorry, I don't seem
to have saved the message that mentioned when this was (supposed to be?)
fixed - perhaps the 16CxxA and recent non-A parts?), basically any
access, read or write, to PORTB will cause the latch that is part of the
change-detect logic to be reset.  This is exactly how you were intended
to reset it, in fact, but it proves to restrict the use one can make of
the interrutp on change for any application other than waking the PIC up
from sleep.  The PIC does internal reads (as part of a generic
read/operate/write cycle) of PORTB for at least reads, writes, or bit
operations on PORTB.

However, you can use PORTB pins for output if you're willing to go to
some small bother, and you can live with what amounts to an
open-collector output.  The trick would be to write all zeros to the
PORTB pins not used for interrupt-on-change, and to control the state of
these pins through TRISB.  Come to think of it, you could get active pull
up or down from each pin, depending on whether you set it to 0 or 1,
couldn't you?

Warning!  Warning!  I haven't tested this idea!  It's probably not
original with me, but I can't recall seeing it described before -
probably memory failure on my part, as it's pretty obvious after it's
been described, isn't it?  ;-)

There's been some discussion about when the PIC might unexpectedly read
PORTB, but I don't recall that we've ever gotten an authoritative answer
to some fascinating (and troublesome, if you want to use interrupt on
change) speculations about this.


PS: nothing is new... I was about to send this off when I remembered that
I've seen the trick of controlling an output by writing to TRIS instead
of the data register in a couple places - I think it's suggested for
driving the I2C bus, for example.  I've been browsing the specs and app
notes for this recently, so that's probably the spark.