I2C implementation

[Roberthh]

Just for confirmation: Is I2C implemented on ESP8266 as soft I2C only, by bit banging? reading the docs, it seems so.
If yes, then why are ports e.g. on Huzzah Feather labeled as SDA and SCL, if that not really matters?

What is the highest speed that was found to be reliable in a set-up with short wires, 4k7 pull-up and clean signals on the bus?
The reason I ask: I have a test set-up, which seems to fail after a while at clock rate of 100 kHz.

Code: Select all

  File "sh1106.py", line 96, in write_cmd
OSError: [Errno 19] ENODEV

[mattyt]

Hi Robert,

Yes, I2C is implemented with bit banging on the ESP8266 and I2C can be bound to any GPIO.

The reason the Huzzah Feather labels particular pins as SDA and SCL is alluded to in the Feather Huzzah Pinout [1] - "In theory you can use any pins for I2C and SPI but to make it easier for people using existing Arduino code, libraries, sketches..."

I believe the Arduino Uno uses analog pins 4 & 5 by default for I2C so I guess they chose to use the same numbered GPIO's for the ESP8266(?).

More importantly, they've standardised the *location* of the I2C pins across their Feather range [2]; the ESP8266 Feather is one such board but there are many others [2]. This means that when one of their FeatherWing expansion boards [2] are stacked it will operate regardless of which Feather board is used.

I haven't yet tried to push the I2C clock rate on the ESP8266 so I'm hoping another forum member can chime in on that topic!

Regards,
Matt

[1] https://learn.adafruit.com/adafruit-fea ... d-spi-pins
[2] https://www.adafruit.com/feather

[Roberthh]

Problem solved. The device in test was a Waveshare SH1106 OLED, and the driver a mix of @deshipu's driver, which is SPI only and the MP SSD1306 driver, which supports both I2C and SPI.
The reason was a floating D/C input, which is not needed for I2C communication. The SH1106 data sheet recommends to tie CS low, but tells nothing about D/C. The phenomenon was kind of spooky. It worked for a while, and then failed. When I was apart from the device, it worked for hours, but coming close to it made it fail. Now I use an 1MOhm pull down, that's fine.
Now it can work at the maximum speed of the ESP8266, which is about 150kHz @ 80MHz clock and 240kHz @ 160MHz clock
Additional note: I added a hard reset for the display, so the benefit is 3 GPIO ports, at least.

[deshipu]

Do you think you could share the code? I would love to add I2C mode to my driver, but I have no device to test on.

[Roberthh]

Do you think you could share the code?

Hello @deshipu. I planned that, and just had to add a few lines of sample code into the comment lines. Compared to your code, I changed the name of display.sleep(value) into a pair of poweroff()/poweron() functions. You might also like to add a speed setting into each of the I2C I/O methods, like you have in the SPI section. I can do that to, just need a second device with a different speed for testing. I also have set the baud rate for SPI to 1 MHz. Looking at the actual data transfer rate, there is no real advantage getting higher.

sh1106.zip

(1.43 KiB) Downloaded 367 times

[deshipu]

Thank you! I have some things on my plate right now, but I will definitely try to incorporate this.

[Roberthh]

Hello all,
I made some additions to that driver:
a) added the fill_rect() and line() method
b) allowed None as value for CS for SPI devices. You then have to pull CS low permanently. That might be useful if the display is the only SPI device in your set-up and you dare for available GPIO pins.

sh1106.zip

(1.53 KiB) Downloaded 334 times

[deshipu]

Just a loose suggestion, but it might make your development much more comfortable. Have you considered using a version control system for keeping your code? They are great tools, and they really change the way you work -- for the better. You don't necessarily have to use github or other code-hosting websites, if you don't like them, but being able to easily go back to any previous versions, compare them, see what was fixed when, etc. makes the development much easier to me in the long term. And the need to describe the commits makes me make smaller and more focused changes too, making the whole process less chaotic.

[Roberthh]

[quote] Have you considered using a version control system for keeping your code[/quote
Actually I'm using git for that purpose, at least locally, for all it's benefits. It's just that I did not open a git repository yet for that driver. It's on my to-do-list, once I'm finished with my current project, for which I adapted the SH1106 driver with the I2C interface. For that project, I moved back to SPI. I2C was too slow in the full screen redraw. I just had a time window of 40ms for that, I2C needs about 80 ms, compared to about 30ms with SPI and interfered with timer interrupts, making them served in a less timely fashion (all that at 80 MHz clock frequency at an ESP8266).

[nilo]

Robert,
i used your i2c sh1106 driver from git for my 1.3" oled. i got it to worked but it skipping every
other line. i'm using esp32 and the oled spec: 1.3", res 128*64, chip = ssh1106 ? ...
any thoughts, software? hardware? thanks.