clocki2c
I'm very new and I'm trying to do an I2C trace of ADXL345 with Ch1 to SCL and Ch2 to SDA, but the traces look like these:
Is the clock not supposed to oscillate continuously? Is it normal for it to stay high when data is being written (although the decoder fails to decode).
I wonder if I'm doing something wrong and missing something basic.
I've seen exactly the behavior you're afraid of on an ADXL345, which uses the same I2C/SPI selection scheme. I had another SPI device that used different clock polarity and it happened to emulate an I2C start code, the ADXL345 tried to talk out of turn as I2C. Bad news.
I carefully rewrote the SPI as bit bang instead of using the peripheral, making sure to not change the MOSI line while the clock was high. (This is the I2C start condition.) That seemed to solve things.
If I was starting from scratch, I would try to use I2C bus instead or a dedicated SPI port for the ADXL345.
Apparently I wan't the only one to encounter this. This paragraph appeared in a later revision of the ADXL345 datasheet:
Your problem is that you have sprinkled i2c_wait() commands through your code.
This is a microcontroller, it is simple, it does exactly what you want. The state doesn't need to be constantly checked. You should only need to call i2c_wait() after interacting with SSPBUF. Have a look at http://www.8051projects.net/wiki/I2C_Implementation_on_PIC
By holding SCL high and toggling SDA (removing and replacing the resistor) you are sending a start bit followed by a stop bit. It isn't clear why this fixes the registers you are checking, as Chris Stratton suggested you could dump out the registers if you really cared.
Best Answer
Also, given that you're bit-banging I2C on a microcontroller that's undoubtedly got "other things to do" (wifi on the 8266, right?), it's possible your bit-banged I2C program flow is being interrupted to handle wifi (or who knows what else), and possibly screwing things up. Perhaps you (the Zarya I2C library you're using) needs to be disabling interrupts for the duration of each I2C byte, or even each entire transaction to/from your I2C peripheral. You don't want to be interrupted part way through a byte: the I2C peripheral might time-out, but your bit-banged code is still 'in state' in the middle of a byte & has no idea xx mS just passed between a couple of its bits transmissions/receivings.