John Payson wrote:
>
> The PIC 16C5x was designed to be as simple and cheap as possible.  Adding
> hardware to allow port reads to read the latch (rather than the physical
> pin) would have increased the price.
> The cost of one 8-bit buffer and a bit of thought is insignificant
compared with the cost of the entire chip.
I know about the shadow register kludge technique.
I just object to having to need it.
Someone just asked me how you can modify one bit from a group of eight
without reading the others. It's perfectly possible to do this in hardware:
look at the 74LS259 chip: you can set/clear any one of eight 1-bit latches.

On the positive side, I think I have the PIC's SSP working.
I had to spend most of a week pursuing the matter through distributors etc,
and eventually right to a chap at Microchip's Arizona Fab.

I was right, there is no way I'd have got it working with the data sheets.
Essentially, the problems is caused by the R/W bit.
It isn't valid all the time!
Only when the address byte arrives.
After that, it contains a record of the ACK bit from a data byte transfer.

So if you service SSP interrupts by testing SSPSTAT R/W bit first, you're
 stuffed.

The way to kludge round it is to test the Address/Data flag.

        If (an incoming address)
        {
                if( R/W bit says Read )
                {
                        // received the read-address
                        set a COPY of the R/W bit
                        load the SSPBUF with first data byte for master
                }
                else
                {
                        // received the write-address
                        clear a COPY of the R/W bit
                        empty the SSPBUF to clear the BF flag
                }
        }
        else
                if( the COPY of R/W bit says Read )
                {
                        // received the read-data
                        load the SSPBUF to send a byte to the master
                }
                else
                {
                        // received the write-data
                        empty the SSPBUF to accept a byte from the master
                        // this will clear the BF flag
                        handling this incoming data as necessary
                }
        }

Another warning: when the master is reading bytes from the PIC, the PIC will
 always interrupt the PIC CPU.
If you have no more data to return, then you can't set the CKP bit without
 loading the SSPBUF first!
You have to load a dummy byte.
What is more, the first (msb) of this byte will later appear on the SDA line.
So if your dummy byte is 0xxxxxxx, the SDA will be left stuck low, jamming the
 bus!
So you must ensure your dummy byte begins with logic one.

I suspect this problem arises because my master is a bit naughty and
 acknowledges all bytes from the PIC.
Perhaps if it NACKed the last byte, the SSP would not interrupt to ask for any
 more bytes.
This is not a problem for many I2C slaves - the STOP condition resets all their
 internal logic.
However there are some circumstances where the master might not know when to
 acknowledge or not.
For example, if the PIC asked the master to read a variable length of message
 data.
Either way, it seems a good precaution to send a dummy byte >= 128 if the master
 reads too many bytes.

Hope this hard-won knowledge helps others implement readable I2C slaves using
 PICs.
I may unsubscribe from PICLIST if I have no further problems, so if anyone
 wishes to contact me use my work
e-mail, or if in the far future I no longer work there then try
 106576.1560@compuserve.com

Cheers, Keith H.