ESP8266 Community Forum

- Tue Nov 03, 2015 3:02 am #32905 Hello,

I am relatively fresh to NodeMcu and the Lua syntax and have a question rearding use of the builtin U8G library in firmware v0.95.

I am currently struggling getting an i2c oled display to work with nodemcu. The display I am trying to use is a cheap 0.96" oled module bought on eBay, the model with adresses 0x78 or 0x7A (with "www.heltec.cn" on the back).

Unfortunately all the efforts has failed so far. I have been using the exact same display with an Arduino, and there it had a quirk that I wonder if it is possible to cope with on the NodeMcu as well. The display is apparently not sending any acknowledges when it is configured, so in Arduino I had to use a special parameter in the constructor
U8G_I2C_OPT_NO_ACK which I can also find in the source code u8G for the NodeMcu firmware. This seems to ba possible to set in a method called u8g_i2c_init() referenced in u8g.h, but how can I call this method in a lua script?

I have tried to use the following code derived from others that have made other oleds work:

function init_i2c_display()
-- SDA and SCL can be assigned freely to available GPIOs
sda = 5 -- GPIO14
scl = 6 -- GPIO12
sla = 0x78 --default address
i2c.setup(0, sda, scl, i2c.SLOW)
disp = u8g.ssd1306_128x64_i2c(sla)
end

but this does not seem to get initialize my display correctly.. Any help appriciated

thanks, Henrik

- Thu Nov 05, 2015 5:13 pm #33189 Hello,

after some attempts, including bilding custom firmware, I found out that the address on the back of the oled module was not correct. The correct address is 0x3c as used in most examples, although it is actually printed 0x78 on the module.

So, my cheap modules worked with the the builtin u8g library after all.

-Henrik

- Thu Nov 05, 2015 5:49 pm #33194 Sorry to follow up a bit late on your issue.

The confusion with the address is caused by different interpretations of the bit string being sent when addressing the device. Datasheet specifies the slave address as

Code: Select allb7 b6 b5 b4 b3 b2 b1  b0
0  1  1  1  1  0  SA0 R/W#


This is the byte 0x78 for SA0 = 0 and neglecting R/W#. But it's 0x3C when looking at the actual address information.

Regarding I2C ACK handling - the driver always ignores the ACK from the display. You could consider this a bit quirky for displays which provide the ACK, but relieves the user from selecting the appropriate option for his specific variant.

Hope this helps.