Replies: 2 comments 1 reply
-
The buffer is shared if the size of the display is the same. You could render your data in one u8g2 object and send the buffer again with the second object. If speed isn't a problem, then also the idea with the same I2C address should work with SW emulated I2C and with an additional rectifier which isolates the ACK answer from the display. |
Beta Was this translation helpful? Give feedback.
1 reply
-
Not tested, but I could assume it could work like this: U8G2_SSD1309_128X64_NONAME0_F_HW_I2C u8g2(U8G2_R0, U8X8_PIN_NONE);
U8G2_SSD1309_128X64_NONAME0_F_HW_I2C u8g2m(U8G2_R0, U8X8_PIN_NONE);
void setup(void) {
u8g2.begin();
u8g2m.begin();
}
void loop(void) {
u8g2.clearBuffer(); // clear the internal memory
u8g2.setFont(u8g2_font_ncenB08_tr); // choose a suitable font
u8g2.drawStr(0,10,"Hello World!"); // write something to the internal memory
u8g2.sendBuffer(); // transfer internal memory to the display
u8g2m.sendBuffer(); // transfer internal memory to the display
delay(1000);
} |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hello! I'd like to drive two identical I2C OLED displays (SSD1309 controller) on the same bus, and I'd like to have them show the exact same content.
I presume the simplest option is to give them different addresses and treat them as completely separate - but this means that each will be allocated a separate frame buffer in memory, all of the text/graphics layout code has to be run twice, etc, etc, so this is not the most efficient approach. Is there any way to share the framebuffer, and/or create and update a single framebuffer on the microcontroller, then sendBuffer() it multiple times to different targets?
Or maybe a workaround is to create just one u8g2 object, but manually uses setI2CAddress() and duplicates the initDisplay() and sendBuffer() calls?
Solving it in hardware (giving the displays the same I2C address) would be the most efficient from the software side, as well as minimizing the bus traffic, but doesn't seem to be a viable option since the SSD1309 properly ACKs on the bus and the two displays would clobber each other. I had thought about defeating this in hardware (using some kind of isolator to make them unidirectional like the cheaper I2C display controllers) - but there are downsides to this as well, namely the inability to poll if a display is connected.
Any advice would be appreciated!
Beta Was this translation helpful? Give feedback.
All reactions