i2c slave killing packets from the master

[Ken Macfarlane]

My i2c master sends out address/data packets quite happily when there's no slave on the line. When the slave is an I/O expander (Phillips pcf8754), everything goes ok.

When I use a pic-based slave, as soon as the slave comes out of reset, the packets stop - seems to resolve around inclusion of the #use i.e.
#use i2c(SLAVE, SDA=PIN_C4, SCL=PIN_C3, address=0x41, SLOW, FORCE_HW)

I'm running both ends on pics with hardware mssp's, I've got the usual output_float calls on C3 & C4, and I've checked that I haven't misconnected C3/4 at the slave end, or plugged them into the wrong port.

Anybody know what the use i2c line actually adds to my code?

Thanks,

Ken

[rnielsen]

The Master is the one that generates the SCL pulses but if the Slave wants to it can hold the SCL line low which will cause the Master to pause until the SCL line is released by the slave. This is to ensure that the Master doesn't attempt to clock data out to the slave (or from it) before the Slave is ready to send (or receive) the data. You #use statement simply tells the PIC that it will be in Slave mode, which pins to use, the address of the Slave, that you want to talk in slow mode and to force the use of the hardware that built into the PIC. Make sure that the pins that you have selected are, in fact, the hardware pins for I2C communication. I found that not having the FORCE_HW in my use statement made it run, in one application, whereas if I included it the PIC would not function.

Ronald

[Guest]

Also, the slave address specified needs to be an even number.

[Ken Macfarlane]

Thanks - my slave address was "A". Rather unfortunately for me , it's an odd byte. As soon as I changed it to "B", everything just went - circular buffer and all!

[treitmey]

I have never seen that even address thing before. What spec sheet did that come from.

[rnielsen]

You can check out the entire I2C specification at http://www.semiconductors.philips.com/acrobat/literature/9398/39340011.pdf. The addresses need to be even because the LSB is used as a R/W bit.

Ronald

[Mark]

When the last bit is a 1 (odd) the device is addressed in read mode which caused the device to hold the clock line low until you set it back high for the master to clock out the data. Thus the reason for only even addresses.

[Ken Macfarlane]

CCS' ex_slave.c shows i2c_poll being used to determine whether the incoming slave address is accompanied with a read or a write i.e. i2c_poll returns 0 when the slave is to be read, the inverse of the read/write# bit. Am I understanding this correctly? Is it the inverse of r/w#, i.e. bit 2 in SSPSTAT<2>?

I'm finding that I only occasionally get anything other than the slave address in the incoming packet at the slave end, and although the slave sees both true & false returns by i2c_poll, it always replies with all zero packets. I'm considering porting the hitech C code in an736 to CCS C, as it handles all the error conditions - anybody had any success with this?