Closed kjkoster closed 7 months ago
I tested the wiring with the I2C tester and that returns a device at the expected address. Unplugging the display shows the address no longer responds, so there is no alternative device claiming that address either.
What happens if you run any u8g2 example? Will you see some changes on the display? Another question: Is this really a SSD1306 OLED? It might be also a LD7032 OLED.
Interesting, your suggestion to try the LD7032 really helped. Thank you!
That said: the behaviour is still not optimal. Please see the attached images, where I show the constructor that I used and the result on the screen. This is from the GraphicsTest
example sketch.
To my untrained eye this looks like a memory dimension mismatch somewhere, but I don't know how to fix that. Any suggestions?
I also note that each line that I used had the comment // NOT TESTED!
. :-) How do I test it? Is there any way to show traces or query the device for memory layout?
Like before the patterns on the screen do change as the sketches run. Hard to show on a photo.
How do I test it? Is there any way to show traces or query the device for memory layout?
Well, yes,... thats I guess why this lib is needed. The display controller needs to be known and also the datasheet needs to be available. I once had an example, where it took me almost a year to get the display working. Analysing the memory layout sometimes takes hours of setting and identifing pixels ;-)
Like before the patterns on the screen do change as the sketches run. Hard to show on a photo.
Better try some static example like the "HelloWorld.ino"
I tried a bit more last night, but I cannot seem to get reproducible results. Now the LD7032 driver won't show any patterns anymore. The only reproducible thing is that the SSD1306 driver gives me the faint bars, as shown in the first image on this thread.
Is there any I2C level detection mechanism that I can use to ping the driver chips via I2C to get a definitive chip identification? The I2C scanner only confirm there is something on the address, not what.
All-right, I solved it! But not how you might think. The solution is to run this display on 3.3V and not on 5V.
The supplier (Tinytronics) gave me sample code that they tested to work locally.
#include <Arduino.h>
#include <U8g2lib.h>
#ifdef U8X8_HAVE_HW_SPI
#include <SPI.h>
#endif
#ifdef U8X8_HAVE_HW_I2C
#include <Wire.h>
#endif
U8G2_SSD1306_64X32_1F_F_HW_I2C u8g2(U8G2_R0, /* reset=*/ U8X8_PIN_NONE);
void setup(void) {
u8g2.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
delay(1000);
u8g2.clearBuffer();
u8g2.drawBox(0,0,64,32);
u8g2.sendBuffer();
delay (3000);
}
Running that code did not show any improvement. On a whim I decided to wire the display to the 3.3V output of my Arduino, instead of its 5V output. Lo and behold, it worked!
Huge shout-out to Diego from Tinytronics for his help, and of course @olikraus for his.
Here shown working and with the correct wiring.
I am happy you found the issue. Looks great :-)
For completeness: Diego from Tinytronics gave me the full explanation: the signal voltage on the device needs to match its Vcc. I was mixing them (3.3V signals, 5V Vcc) and that does not work. So in the end it was bad wiring on my part.
Thanks everyone.
Hi,
I have trouble getting the sample code for this OLED display to work. No matter which driver I choose, I get vertical bars on the display, as can be seen in the attached image.
The faint brighter line near the bottom of the display actually moves around when the sketch is running, so I think the I2C address is correct etc.
Display is this one https://www.tinytronics.nl/en/displays/oled/0.49-inch-oled-display-64*32-pixels-white-i2c which is said to have the SSD1306 driver. I am running it off of an Arduino Nano 33 IOT, if that matters.
Questions: