U8g2: Multiple SSD1306 OLEDs with the same i2c address on different HW bus with Teensy3.x

[JorisKingma]

The u8g2 library gave me great functionality (low ram usage and awesome fonts), thank you for that! It must be quite the effort to create and maintain such a library.

The Teensy 3.2 has the ability to use 2 HW accelerated i2c busses. Is there a possibility of constructing 2 instances of your library on Teensy 3.2/LC? The OLEDs I'm using don't have a selectable i2c address and I'd like to avoid using an i2c duplexer.

This would be an awesome feature! I've tried to combine your library with the i2c_t3 library but I'm not sure if combining these libraries would make it possible.

Love to hear from you, keep up the good work!

[olikraus]

You might have ssen that the constructor ends in "_HW_I2C". There is also a "_2ND_HW_I2C" constructor for the second bus.
Whether the 2nd HW I2C exists or how the 2nd HW I2C is connected to the pins, is defined by the Wire.h implementation of your board.

I do not know much about Teensy 3.2, but if your board description only defines one bus, than also within u8g2 it will only have one bus.

Background: Your board definitions are done in "Arduino.h". This will sets the makro WIRE_INTERFACES_COUNT to the number of available hw interfaces. U8g2 takes information from there. If this information is wrong, then your board definitions need to be updated.

The Teensy 3.2 has the ability to use 2 HW accelerated i2c busses.

Where is this documented? From what I read here https://www.pjrc.com/teensy/td_libs_Wire.html there is only one bus.

[JorisKingma]

Thanks for the quick reply! Tried using the _2ND_HW_I2C but that doesn't work in my configuration. Board definitions must be off I guess. I'm just a hobbyist, altering those definitions is not my cookie.
The following link shows the number of i2c lines for every Teensy model. It shows that from the LC onwards there are 2 or more i2c busses available:
https://www.pjrc.com/teensy/techspecs.html

The i2c_t3 library (advanced wire capabilities) provides an advanced scanner that scans both busses (would that lib also be using the board definitions?). Using that scanner with both oled's connected (with the same i2c address) they both pop-up in the results.

[olikraus]

The i2c_t3 library (advanced wire capabilities) provides an advanced scanner that scans both busses (would that lib also be using the board definitions?).

This would mean to replace all calls to Wire.h to i2c_t3 library, which probably is a major rework of u8g2 and would be very specific to your board. At least this is not an option for u8g2 (unless i2c_t3 is backward compatible with the Arduino Wire.h)

I'm just a hobbyist, altering those definitions is not my cookie.

Agree, even for me it is more like a black hole. U8g2 relies on Wire.h. If your board has two I2C subsystems, but Wire.h for your board only supports one, then I can not do much here.

[JamesGKent]

@JorisKingma reading the docs for i2c_t3 library it is meant to be a drop in replacement, if you modify u8g2 to include i2c_t3 instead of wire then it may work, i'm not sure of the convention with the wire library but in the i2c_t3 library the additional bus is represented by wire1, and the origional bus by wire

[olikraus]

but in the i2c_t3 library the additional bus is represented by wire1, and the origional bus by wire

Yes, as per Arduino convention, the second I2C bus should be called wire1. Exactly this object is used for the 2ND_HW_I2C interface by u8g2: https://github.com/olikraus/u8g2/blob/master/cppsrc/U8x8lib.cpp#L614

[JorisKingma]

Okay, so would it work to change "#include " to "#include " in your library Olikraus? The 2ND_HW_I2C refers to original Arduino boards with 2 i2c busses (like the Due) i guess. Not sure how to optimize my chances for succes here. I could of course use an i2c duplexer if things take a lot of tweaking with a small chance of succes. Any advice anyone?

Edit: just tried it, code couldn't compile for Teensy :-/

[olikraus]

Okay, so would it work to change "#include " to "#include " in your library Olikraus?

Yes, if i2c_t3.h is 100% compatible.

The 2ND_HW_I2C refers to original Arduino boards with 2 i2c busses

Some Boards have 2 I2C busses, others have only one. As mentioned before this is also defined (WIRE_INTERFACES_COUNT). Depending on this, the second bus is activated in u8g2.

Maybe back to the original question. You want to run two identical OLEDs in parallel? Can you post a picture of the soldering side of the OLED? sometimes there are solderbridges for the I2C address.

[JorisKingma]

These are the displays I oredered: https://www.banggood.com/5Pcs-0_91-Inch-128x32-IIC-I2C-Blue-OLED-LCD-Display-DIY-Oled-Module-SSD1306-Driver-IC-DC-3_3V-5V-p-1191376.html?rmmds=search&cur_warehouse=CN
Looking at the images, there are no soldering pads. To prevent delays in my project I'm trying to figure out how to do this before I get them in.

[olikraus]

well.. then... it was just an idea...

[JamesGKent]

@JorisKingma you say it doesn't compile, but i've just tried it (i don't have a teensy to test, but i can compile)
using:

• arduino 1.6.9
• u8g2 2.19.8 (i suspect i'm a bit out of date here)
• teensyduino 1.29 (to match arduino version)

i opened the graphics test example sketch and changed the include from wire.h to i2c_t3.h
in the u8g2 library i changed line 45 of U8x8lib.cpp to include i2c_t3.h

and in the sketch defined two u8g2 constructors:
U8G2_SSD1306_128X64_NONAME_F_HW_I2C lcd1(U8G2_R0, /* reset=/ U8X8_PIN_NONE);
U8G2_SSD1306_128X64_NONAME_F_2ND_HW_I2C lcd2(U8G2_R0, / reset=*/ U8X8_PIN_NONE);

this does at least compile, so may be worth a go?

[JorisKingma]

@olikraus: must have missed something in the first attempt, when changing the lilke like you suggest it doe compile.
Using:

• Arduino 1.8.5
• u8g2 version 2.20.13
• Teensy loader 1.4

2ND i2c line doesn't work though :-/
Main line does!

Worth a try indeed. Thank you for your help!

[olikraus]

Still many questions are open. What pins are used by i2c_t3 for the second i2c bus? Are these pins correctly set?
What about WIRE_INTERFACES_COUNT? Is it set by the lib? Maybe you can set WIRE_INTERFACES_COUNT to two with

define WIRE_INTERFACES_COUNT 2

at the beginning of U8x8lib.h

[JamesGKent]

@JorisKingma you say the second line doesn't work, how do you know? i thought you didn't have the screens yet? or do you mean it doesn't compile? because it does compile on mine...

I'm assuming @olikraus if the WIRE_INTERFACES_COUNT was only 1 and i used a _2ND_HW_I2C constructor that it wouldn't compile? is that correct?

[olikraus]

I'm assuming @olikraus if the WIRE_INTERFACES_COUNT was only 1 and i used a _2ND_HW_I2C constructor that it wouldn't compile? is that correct?

It will compile. In fact it has to compile because many Arduino boards will set this value to 1.
If WIRE_INTERFACES_COUNT is set to 1, then the 2ND_HW_I2C is available but does nothing.

Ok, I could have removed the 2ND_HW_I2C constructors (so that you get an error when trying to use this constructor), but instead i decided to create a "null" device which just does nothing.

[JamesGKent]

@olikraus ah ok, i wasn't sure which way it would go especially as with the version i'm using I can only select the option "teensy 3.1/3.2" when the 3.1 only has 1 interface and the 3.2 has 2...
@JorisKingma as i don't have a teensy myself to be able to test and given that it will still compile i don't think i have anything more to add here... hope you get a solution.

James

[olikraus]

@JamesGKent thanks for your input. I am happy that there are some other people reading issues here and support by providing hints and answers. :+1:

[JamesGKent]

@olikraus with such a great and cared for project that has been useful for me (and recommended it to other people) i do keep an eye on the issue tracker and help out if i can. such a good project deserves support.

[JorisKingma]

@JamesGKent Thank you for stepping in! I fully agree with you; @olikraus is doing an awesome job!!
Regarding the OLED's: I'm testing with some OLEDs I already have, they have the same address.

[olikraus]

Not sure about the status of this issue.... but, can we close this?

[olikraus]

pressed close too early :-p