Hello,
If I split the SDA and SCL wires that come out of the Arduino in 4 and connect them to 4 OLED displays I2C that are powered up, it will show the same information simultaneously on all 4 displays? And if yes, how many displays you can connect like this?
I2C is a bidirectional communications bus. If the displays are all at the same address, which one responds when asked for register information? All of them, at the same time. Not desirable. But, if they're at different addresses, then your software must speak to each individually.
Some OLED displays have an option to select the I2C address, this gives you a limited number of non-conflicting addresses to use. If you want more displays than this, then an I2C multiplexer can be used to select amount multiple I2C busses, with multiple OLED displays on each bus.
But it still requires that you manage the multiple addresses/instances. No "write once, display on multiple screens", which I think the OP is looking for. That requires a display that doesn't talk back to the writer, which I'm not sure exists.
There are many that don't talk back, or can be prevented from doing so. But not i2c displays. Displays with SPI or 4/8 parallel data lines interfaces could be used.
With I2C displays, I agree that an I2C multiplexer is probably the best solution. The Arduino code can be written as though only 1 display is connected, but then when the display is to be updated, repeat the .update() or whatever function is used, multiple times, changing the multiplexer channel in-between.
But not i2c displays.
Clarification, agreed - I was talking specifically about I2C displays, but didn't state that.
Yes, when the addresses are the same.
Interesting. So, what LCD library was used, please?
Adafruit GFX and 1306.
https://dronebotworkshop.com/oled-arduino/
Okay. So the OLEDs don't talk back, or it 'just works, so don't ask'? I'm curious. Guess it's time to go and dissect the OLED library in question.
This is true. DCE RX only.
Wait ... Then how come they show up when we run i2c scanner?
Don't they have to ACKnowledge receipt of data sent to them, so isn't that talking back?
And if 2 or more displays talk back at once, that could corrupt the i2c signals, if the two displays don't send exactly synchronous, identical data.
I guess there's no reason why they wouldn't send the same data, synchronised to within tolerances, if the displays are the same model and the wires between them and the Arduino are short.
So maybe multiplexer is not required in that case.
If you can run multiple displays in parallel, then you need to handle the pull-up resistors properly, and pay attention to loading and capacitance.
I2C is ALWAYS a two way bus even when data writes to a slave is being done.
The slaves must always acknowledge data being written.
It does seem possible or even likely that there could be i2c signal corruption when attempting to write to multiple slaves on the same i2c address.
In other words, IMO, while it may "work", I would never count on it working.
If the ack signals drifted too far from each other, or one decided to do clock stretching on the bus due to some internal timing/resource thing, it might confuse the master that there were multiple masters on the bus.
Various Arduino Wire/I2C libraries have issues with recovering from signal noise on the bus or fail to operate correctly with mutiple masters.
One such library is the AVR Wire library.
The AVR Wire library can lock up under some conditions that are created by noise on the bus or multiple masters.
--- bill
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.