Software I2C in slave mode

I think you have forgotten an important thing
in the IIC protocol, slaves can be very slow and in fact they can keep the incoming clock signal low for a time to slow the master. But all software master implementations i've seen are not checking the clock state .
for the slave, it is quite simple in the very first instant detecting the clock ( using interrupt ) to fix the clock state for a while until bit treatment is done.
I hope this can help.

I think you have forgotten an important thing
in the IIC protocol, slaves can be very slow and in fact they can keep the incoming clock signal low for a time to slow the master. But all software master implementations i've seen are not checking the clock state .
for the slave, it is quite simple in the very first instant detecting the clock ( using interrupt ) to fix the clock state for a while until bit treatment is done.
I hope this can help.

in the IIC protocol, slaves can be very slow and in fact they can keep the incoming clock signal low for a time to slow the master

How wonderful, now we slow the slave and slow the master. Of course if we really do not need to do anything else such as gathering information to transmit?

Of course, if the master has gasp interrupt driven hardware IIC only the slave will come to a crawl.

So many .....s see "slowing down" as a solution to a problem, this is ridiculous.

When we were using the 10MHz PCs many things ran faster than they do today when the so called "programmers" have no concept of time.


Erik

Hi Cal,

Just clarify what you ment by "however the data received is DEFINITELY not being sent.
I think the problem may be timing between the transmitting and receiving or the my method of receiving the data."

If your slave is triggering on the START condition then from the I2C protocol "Data on the SDA pin may change only during SCL low time periods". So if you look at the following it should hopefully help:-

jb SCL,$ ;get past "START" condition

REPT 8   ;repeat block get all 8 bits of data
jnb SCL,$ ;wait for clock to go high
mov c,SDA ;read data transmitted MSB first
rrc a     ;and save it
ENDM

This was only a suggestion to keep in sync with quite slow software peripherals ( with a few dedicated IIC hardware " bit level " or even no dedicated hardware at all ) and with work to do before replying.
Hardware for master take this extended clock as mandatory, but keep in mind that software masters have to test it. This protocol has not been developped for nothing.