U8glib for I2C SSD1306 conflicts with Wire.h on Arduino Due

Using Arduino Displays
1

Hi,

Knowing the Oliver, the author of the great U8glib library is also active on this forum, I hope that this is the right place to ask my question...

I was really happy when I realized that U8glib supports the I2C version of SSD1306 :slight_smile: since that allowed me to build the tinyOLED RepRap display controller. It works like a charm on the standard Mega 2560 / RAMPS / Marlin combination.

Since the SSD1306 display works as well on 3.3V, it was also no problem to use the tinyOLED on an Arduino Due with a standard RAMPS modified with Andrews modifications runing Wurstnase's Marlin4Due.

The problem arose only when I added an I2C EEPROM on the tinyOLED's PCB (since the Arduino Due does not have its own EEPROM). While I could access the I2C EEPROM witout problem when not activating the I2C SSD1306 display, as soon as I activated the display, accessing the EEPROM would just give errors...

My first step was to go back to test the same combination on the Arduino Mega, but there the combination EEPROM / SSD1306 worked fine - so the problem seemed to be Due specific...

After analyzing and comparing the two I2C implementations Wire.h (used for the EEPROM) and U8glib (using its own I2C routines) and doing many unsuccessful tests, I finally found that the conflict would be resolved if I removed the '//' from the (3 each) commented out statements "//u8g->pin_list[U8G_PI_SET_A0] = 1;" and "// u8g_i2c_stop();" in file U8glib/utility/u8g_com_arduino_ssd_i2c.c :

$diff u8g_com_arduino_ssd_i2c.c.ori u8g_com_arduino_ssd_i2c.c
125c125
<       //u8g->pin_list[U8G_PI_SET_A0] = 1;
---
>       u8g->pin_list[U8G_PI_SET_A0] = 1;
130c130
<       // u8g_i2c_stop();
---
>       u8g_i2c_stop();
134c134
<       //u8g->pin_list[U8G_PI_SET_A0] = 1;
---
>       u8g->pin_list[U8G_PI_SET_A0] = 1;
146c146
<       // u8g_i2c_stop();
---
>       u8g_i2c_stop();
150c150
<       //u8g->pin_list[U8G_PI_SET_A0] = 1;
---
>       u8g->pin_list[U8G_PI_SET_A0] = 1;
163c163
<       // u8g_i2c_stop();
---
>       u8g_i2c_stop();

With this 6 lines uncommented, the problem seems to have disappeared.

Now to my question: Did anyone else already stumble over this kind of I2C conflict on the Arduino Due? And if yes, is there any simpler way (rather than modifying the source) for using an I2C based U8glib display in conjunction with other I2C devices (such as EEPROM, RTC etc) on the Arduino Due?

Thanks,

Heinz

2

Hi

Nice finding.

I have not tested this, but maybe this works. Call

u8g_SetChipSelect(u8g.GetU8g(), u8g.GetU8g()->dev, 0);

after the picture loop (or before any access to the EEPROM).

Oliver

3

Thanks a lot, Oliver, for taking your time to look at this.

I tried your suggestion (using u8g.getU8g() instead of u8g.GetU8g()), but unfortunately the conflict with the EEPROM remained.

In any case, I would prefer a solution in which the code of the different I2C devices remain independent and each one releases the I2C signal correctly after having finished its operation.

Do you see any inconvenient in my proposed solution? Does it harm the operation or slow it down? Could one maybe add some new U8G_I2C_OPT_... option for enabling/disabling the releasing of the I2C signals?

Thanks!

Heinz

4

Hi again,

After some further fiddling with the Marlin4Due code, I was finally able to find a solution which does not require modifying the U8glib code. Essentially I had just to add some Wire.begin() statements to reinitialize the I2C lines in ConfigurationStore.cpp where the EEPROM is read and written. I thought that I had tried this before - but things can get confusing when trying to resolve a conflict between two programs, where both of which were not written by oneself... :slight_smile:

So please ignore my last message - and thanks again for your help!

Heinz

5

Thanks for this feedback,

Oliver