mmm, i'm stuck in this i2c.. maybe someone can halpme on this:

I have my PIC (16F874) as slave i2c, and a particular PCI board with an FPGA that's the master.

Miy PIC have to accept Write commands in i2c in SDA and SCL pins from master, and this works great now. PIC receive, decode and execute, all by software.
Then, the PIC, after a READ command have to respond 3 bytes. That's my trouble: after receiving the first byte from master (ADDRESS+READ bit), PIC should be able to hold down the clock line (SCL pin) until the byte to respond is ready to be written out. Seems that this don't happen becouse the master, that have to receive 4 bytes, show first byte as 0, second byte with first 2bits at 1 and then it apppears the right bits i've sent as first byte...
My impression is that the master always clock the line also if i've not the data ready...

Every suggestion is very appreciated
Posted on 2003-12-12 01:38:28 by Bit7
The best thing to do is look at the SCL and SDA lines with a storage oscilloscope or a logic analyzer.
It will tell you how many bytes were transferred.
If the master says it received three bytes but only one was sent, the master is at fault.
If three bytes were sent, the controller querying the master is at fault. The controller is everything that handles the bytes received by the I2C master logic.
Posted on 2003-12-12 19:42:51 by tenkey
thanks tenkey,

i've done it.

The problem is the following: after mi slave PIC have received the first READ command from the master (addres+R), the pic automatically keep the SCL held low, to advise the MASTER that he's going processing the command before responding. Releasing the clock by software the PIC automatically shift out the byte to respond with.
The issue is that the MASTER don't respect this protocol: with the oscilloscope we see that it process the data even if the clock is low. We have a delay of about 4 clock cycles before responding, and the MASTER show a reception of our byte with 4 bit less. This becouse the master don't implement the clock checking, and go on processing data imeediately after his READ command. It use this way of acting to read from eeprom that are on the same board. EEPROM responds immediately, without delay. So this kind of I2C that the master supply also for external slaves is not good if PIC can't respond immediately.

But the strange thing is: why the PIC can't respond immediately if it's clock is at 4mhz and the i2C bus is now at 67khz ? PIC should be able to do about 30 instructions before introducing a delay. I can't understand, probably there's some loss of time due to TIMER0 use, and IRQ automatic routine enabled at 0x004 vector table for I2C wake-up. But is only a tought...

Was thinking to switch to 16mhz clock, and receive i2c in polling fashon to respond in time.
Any idea or help is very appreciated..

Posted on 2003-12-13 14:43:04 by Bit7
mmm and about PS2 ? i have two connectors free, could i try with it as MASTER ?
Posted on 2003-12-13 14:59:33 by Bit7
ok, i've solved switching to 16Mhz clock and doing a polling loop. In polling i can respond to the READ command in a faster fashon, without losing any clock cycle generated from the master. I've also disabled the timer0 interrupt/routine that was causing loss of i2c commands.

Posted on 2003-12-17 14:04:41 by Bit7