Lawrence Lile wrote :

> The short answer is, never do bit operations on a port. 
> Period. Do your bit operation on a mirror byte, then write 
> that byte to the port.  If you must violate this rule, then 
> tread carefully. 

IMHO, better learn when direct bit op's on PORT regs
can be a problem, and take action. As far as I understand,
it's only in some specific cases that you can run into
problems. The interrupt-on-change is (might be) one (but it's not given
that you *will* get problems, since, as Olin correctly pointed
out, the RBIF flag will still be set anyway). Having large
capacitive loads on output pins is another (a RC constant
larger then the time from one Q4 cycle to the next Q2 cycle.
If you know your design, a few NOPs or a rearangement of
a few instructions can solve that.

And, as pointed out, the PIC18's LATx regs is another way of
playing safe.
 
Alan B. Pearce wrote :

> But that does not answer the original question, which was why 
> the R-M-W operation affects the RBIF flag. Your method [only
> writing from a shadow reg to PORTx] still affects  the RBIF flag,...

Now, here is something I don't understand. I thought that a
MOVWF to a PORTx register was "safe" (that is, PORTx is
never *read*. But a few data sheets I have checked still says
"read 'f'" in Q2. Such as PIC18Fxx2, DS39564B, page 237".
Also the "Midrange Ref Manual".

*But*, the "PIC18 Ref Manual" says "Read WREG reg" in Q2
in the same instruction. (DS39532A, page 31-89).

I think the latter document is correct here.

And if so, Lawrence method should be safe even from an
RBIF standpoint (I still don't understand what the problem
would be...).

> Jan-Erik gave a very good treatise on why any operation on 
> the port affects the RBIF flag, which did answer the original
> question. About the only thing he did not point out is that
>this "bug" (or "feature", depending on how you look at it)
> limits the usefulness of the Interrupt on Port Change
> feature unless very careful coding practices are used.

I'm not that sure...
Any read from PORTB with clear the *condition* that set
RBIF in the first place. It will not clear RBIF as such and the
interrupt will still fire. It should still be possible
to read PORTB (again) later to find out what actualy "happend".
RBIF can only be cleared by a direct instruction in the code.

Note that you can not "see" that condition anyway, you still
have to keep your own copy of the old PORTB value (at least
the pins enabled for interrupt-on-change) and make your own
compare with the actual values.

It would have been another issue if there was a "condition register"
where the actual port change that set RBIF was latched so you
could see that even if the actual pin value already have changed back
to the original value before the interrupt. Then I can see why the read
in a bcf/bsf instruction could be a problem, if that would clear the
"interrupt-on-change-latch-register"...

Jan-Erik.

_______________________________________________
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist