@ vernmid:
The reason that I use a 16kHz clock for the I2C communication is so I can change the data on the falling edge and prevent race conditions. When I look at the communication with a scope, I see that it is well functioning during the "write" sequence. My problem is that during the "read" sequence, it acts differently though for my understanding I implemented it in the same way that I did with the "write" procedure. For example, after reading the second 8 bit register, I "miss" 1 clock (during that clock the data line goes high due to the pull-up resistor). I can't find the reason for that miss in the code.
@ FvM:
Could you explain more please? As I said earlier, I can see with the scope that the data changes on SCL falling edge, so that when the rising edge occurs, the data is already stable.
You say that :"Generating a correct I2C timing requires more than two clock phases per bit". What exactly do you mean?
Thanks