Why i2c_isr_state() testing SSPBUF.0 instead of SSPCON.RW

[epalite]

Hi,

The disassembly of i2c_isr_state() reveals that it reads SSPBUF.0 to determine if the ADDR is for read or write, instead of probing SSPCON RW flag. Why is that so?

The Microchip AN734 shown the use of SSPCON RW to determine ADDR+R or ADDR+W.

[FvM]

If you request i2c_isr_state() after receiving the address byte, both methods are equivalent. However, I didn't think yet about the intended use of this function. The compiler manual isn't very clear in this respect. Acquiring the necessary information from SFR directly is probably the clearer method.

[PCM programmer]

[epalite]

Hi PCM Programmer,

I read your explanation.

My question is why doesn't the i2c_isr_state() function extract the R/W flag from SSPCON.RW (0x94 bit 2)?

Doesn't the SSPCON.RW carry the ADDR R/W flag?

Hi FvM,

The i2c_isr_state() is used in the INT_SSP ISR.

Thanks.

[PCM programmer]

That is a good question. I'll look at it tomorrow, if nobody else does it first.

[epalite]

Hi,

I rewrote and emulated i2c_isr_state(), except to retrieve RW from SSPCON.RW instead of SSPBUF.0. It didn't work on 16F690, 16F916, 16F887 M/SSP slave.

It seems RW flag has not been set on SSPCON.RW.

[Ttelmah]

In the first ISR, SSPBUF, _must_ be read. If it is not, the BF flag won't clear, and WCOL/OERR can become set on the next byte. So, to use the R/W bit in SSPCON, you actually have to read the SSPBUF, anyway, so it is simpler just to use the bottom bit from SSPBUF, and 'kill two birds with one stone'. Where the R/W bit is useful, is on the second pass in the ISR, where it keeps the status recorded with the start of the transaction. However the I2C_ISR_STATE function, itself saves the bit, so it makes no point to use this bit. for the function as written.....
It is just a case of a chip feature, not really gaining anything, and not being used.

Best Wishes