Hmmm...

I don't know what to do, feel more embarrassed about putting incorrect
information on PICLIST, or thanking John for finding a bug in a *old* program.

The information I put on before was based on an program that I had created a
*long* time ago.  The purpose was to understand how the read/modify/write
problem worked in the PIC.  Well, I screwed up and specified "f" when I
meant "w".  The results I had gotten were obviously in error.

Bit Argghhh.  I had been labouring under the misconception that this is the
way in which the PIC I/O Ports worked.  The net result is I've been storing
output values and writing them back into the PORT again rather than risking
their values after reading them.

Thanx for straightening me out Dennis,

Myke

>> As I understand it, this is a feature of all PICs - Not just the 16C5x
>> (Definitly on the 16C84).  And, you should be aware that if you read a pin
>> that is pulled high (or low) when you have programmed it into the
>> complementary state, you'll find that afterward, it will be set to this
value.
>
>This is NOT true.  What is true is that: <a> when you do a read, the value
>read back will be what's on the pin, rather than what's latched; the act of
>reading the pin will not change what's latched.  <b> Any read/modify/write
>instruction will compute the value to write to the port based upon what it
>read.
>
>Thus, except for the difference in execution time and the trashing of W, the
>instruction:
>
>        bsf     PORTA,1
>
>is equivalent to:
>
>        movf    PORTA,w
>        iorlw   2
>        movwf   PORTA
>
>Suppose when you do this, bits zero and one are set for output; bit zero is
>latched high but pulled low, and bit one is latched low (but free to go
>wherever).  For simplicity, assume all the other bits are inputs pulled low.
>
>When you read PORTA, you will read a value of zero; PORTA.0 is latched as
>one, but it reads as zero, so that's what will be read.  Then when you do
>the IORLW 2, bit zero of the W register is still clear (nothing will have
>changed it).  Consequently, when you write back the byte to PORTA, you will
>clear PORTA.0.
>
>To avoid this problem, one excellent approach is often to use a "shadow reg-
>ister": do all your "port manipulations" on a byte in memory called something
>like "SHADOW_A".  Then whenever needed, do a "MOVF SHADOW_A,W // MOVWF PORTA"
>to make the hardware match the shadow port.
>
>Pros: No risk of port-bits getting glitched by reading back a bit which is
>  either pulled the wrong direction or too slow to respond to a change.
>
>Cons: Extra instructions; not often effective when rapidly setting/clearing
>  port bits.
>
>As a variation on the above technique, it's sometimes useful to do something
>like the following: [assume bit 1 is clear in SHADOW_A"; 0 will be serial
>data, 1 serial clock]
>
>OutByte:
>        rrf     SHADOW_A        ; Shift bit 0 off the end [will fix later]
>        rrf     Data            ; Value to be output
>        bsf     Data,7
>        bcf     SHADOW_A,7
>OutLoop:
>        rlf     SHADOW_A,w
>        movwf   PORTA
>        iorlw   2
>        movwf   PORTA
>        andlw   $FD
>        movwf   PORTA
>        rrf     Data
>        btfss   Z
>         goto   OutLoop
>
>This will output the serial data byte on porta.0 and porta.1 without using
>any read/modify/write instructions (which frequently can wreak havok on
>porta.4).  Cute, huh?
>
>

Do you ever feel like an XT Clone caught in the Pentium Pro Zone?