ESP8266 Community Forum

Hi

I'm looking for the most mature I2C driver - is https://github.com/zarya/esp8266_i2c_driver it? Or are there better ones out there now?

With Zarya's implementation, shouldn't interrupts be disabled during reads/writes? Wouldn't it be asking for trouble if it doesn't?

Thanks!

Zarya's implementation uses os_delay_us to fulfill the clock rate. It is ok. I2C is relatively a slow bus. Disable interrupts is not a good idea.
I have a similar implementation using RTOS SDK. https://github.com/baoshi/ESP-I2C-OLED

Baoshi wrote:Zarya's implementation uses os_delay_us to fulfill the clock rate. It is ok. I2C is relatively a slow bus. Disable interrupts is not a good idea.
I have a similar implementation using RTOS SDK. https://github.com/baoshi/ESP-I2C-OLED

Indeed. How would you critically compare your implementation with his? Yours seems to use clock stretching and his disables interrupts during init.

Clock stretching is someting a slave does. Is your implementation creating a slave or a master? A master would sound much more logical. A master does not do clock stretching by definition, because the master supplies the clock. The only requirement for the clock is that it runs at < 100 KHz at any single time. Besides that, it can be as monotonic or non-monotonic as you like, comparable to SPI. Clock is a bit confusing in this context, it's not a wall clock, it's more like a "data is valid NOW" strobe (+ out-of-band conditions like start and stop, but that's a different story altogether).

That means that the timing is really not quite critical, on a master. On a slave it's much more critical, especially if the master doesn't honour clock stretching by the client.

Having said that, I doubt it won't be harmful if you disable interrupts every now and time, as long as you treat the piece of code that runs with interrupts disable just like and interrupt service handler itself; do only what's really necessary and move all other code out of the critical section.