Hello!
So I have 1.3" I2C oled display (Vcc, Gnd, SCK, SDA) and standalone ATmega328p with 16MHz ceramic resonator.
With U8X8_SH1106_128X64_NONAME_SW_I2C u8x8(SCL, SDA); software constructor I managed to draw some text. But to do so I have to redraw it completely every cycle and there is visible flickering like the screen is being cleaned every time (I don't clean display in draw cycle tho). So if I draw text only once it appears for a moment and then disappears forever.
With U8X8_SH1106_128X64_NONAME_HW_I2C u8x8(U8X8_PIN_NONE); hardware constructor I don't get even any blink of light on display.
Yes I have those 4.7kOhm pullup resistors.
I have RESET pin of atmega pulled up to Vcc through 7.5kOhm resistor.
The wires from atmega to display are very short like 3cm.
What can be the problem?
Please post your full sketch, using code tags when you do
Ok. It's good idea. Now I will make minimalistic test scetch. Then I will try it and post it with results.
You might want to look at this How to get the best out of this forum before you proceed any further.
It tells you how to post code here, and how to ask a question.
So I wrote minimal sketch and now I do see symbols appearing in hardware mode but there is still an issue:
#include <U8g2lib.h>
U8X8_SH1106_128X64_NONAME_HW_I2C u8x8(U8X8_PIN_NONE);
void setup() {
u8x8.begin();
u8x8.setFlipMode(1);
u8x8.setFont(u8x8_font_amstrad_cpc_extended_f);
}
void loop() {
u8x8.drawString(0, 0, "test string 0");
u8x8.drawString(0, 1, "test string 1");
u8x8.drawString(0, 3, "test string 3");
u8x8.drawString(0, 4, "test string 4");
u8x8.drawString(0, 5, "test string 5");
u8x8.drawString(0, 7, "test string 7");
}
For sketch above I got no visible flickering result but rather dimmed picture (I guess due to nonvisible flickering) with in strange way cropped content:
Then I tried to add some delay. For delay(1) it doesn't seem to change a lot. I skip initialization section as it is the same as previous. And the code for delay(10):
void loop() {
u8x8.drawString(0, 0, "test string 0");
u8x8.drawString(0, 1, "test string 1");
u8x8.drawString(0, 3, "test string 3");
u8x8.drawString(0, 4, "test string 4");
u8x8.drawString(0, 5, "test string 5");
u8x8.drawString(0, 7, "test string 7");
delay(10);
}
And result is flickering:
If I increase delay a little further to 15 ms then the result is flickering harder to eventually shut down the display after few seconds:
And for all cases like more that 20 ms I see the only frame I guess and immediately shut down.
For SetFlipMode(0) those results are the same.
The program is still executing after display shut down as I found out in my non-test sketch.
A delay of 10mS is not long enough by any stretch. The trick is to only update the information when you need to change it. Even that will cause the whole display to be erased and then redrawn. This causes the flash or blink you see when you update it.
The best way to do it is to just change the line you want to update when you need to change the information. You do this by drawing a black rectangular box over the part of the screen that needs updating and then move the cursor to the start of that line and write the new line. You will find, like I do, that the update is so fast you don't see it blink.
A bad move. When a tantalum capacitor fails it almost always fails short circuit. If it is across an unlimited supply then it will catch fire. If you would submit such a design to UL, it would fail to be approved. Use an aluminum capacitor instead.
Yes that's my goal to redraw only what changed.
The issue is that display is being erased for some reason. No you haven't to redraw 8x8 tile while its information is still relevant.
Normally the following code should draw text only once and keep it being displayed forever:
bool draw = true;
void loop() {
if (draw)
u8x8.drawString(0, 0, "test");
draw = false;
}
But it doesn't as I show with help of Test sketch. The purpose of delay is only for testing.
From Texas Instrument LM2596 datasheet:
Also from datasheet:
Self-protection features include a two stage frequency reducing current limit for the output switch and an overtemperature shutdown for complete protection under fault conditions.
At the same time there is precaution in that datasheet about input capacitor nevertheless not prohibiting of using tantalum capacitor as input as well:
Because of their small size and excellent performance, surface-mount solid tantalum capacitors are often used for input bypassing, but several precautions must be observed. A small percentage of solid tantalum capacitors can short if the inrush current rating is exceeded. This can happen at turnon when the input voltage is suddenly applied, and of course, higher input voltages produce higher inrush currents. Several capacitor manufacturers do a 100% surge current testing on their products to minimize this potential problem. If high turnon currents are expected, it may be necessary to limit this current by adding either some resistance or inductance before the tantalum capacitor, or select a higher voltage capacitor.
And the reason is that is what is done by the string write command.
Also photographing a display screen will often be showing the fact that the screen is refreshing slower than the shutter speed. This is worst with videos because the frame rate is not synchronised with the shutter speed.
A date sheet is designed to sell you stuff. UL regulations are designed to keep you safe by design. I know which I would trust. But is is your funeral.
Why ask for advice and then ignore it?
Your choice.
No. Please read the very first message of this topic where I've described the issue. I mentioned that if I don't call draw function again the text is gone.
So I tried different vendor constructors different clock speeds etc.
I managed to draw the entire screen only with SW (software) constructor although much slower and if I don't redraw display again and again then display immediately clears itself after last draw command. And even while it's being redrawn it is flickering like if it wanted to go to some kind of sleep mode but new command awakes it:
#include <U8g2lib.h>
//U8X8_SH1106_128X64_WINSTAR_HW_I2C u8x8(U8X8_PIN_NONE);
U8X8_SH1106_128X64_NONAME_SW_I2C u8x8(SCL, SDA);
bool draw = true;
void setup() {
u8x8.begin();
u8x8.setFont(u8x8_font_amstrad_cpc_extended_f);
}
void loop() {
if (draw){
u8x8.drawString(0, 0, "test string #0");
u8x8.drawString(0, 1, "test string #1");
u8x8.drawString(0, 2, "test string #2");
u8x8.drawString(0, 3, "test string #3");
u8x8.drawString(0, 4, "test string #4");
u8x8.drawString(0, 5, "test string #5");
u8x8.drawString(0, 6, "test string #6");
u8x8.drawString(0, 7, "test string #7");
}
draw = false;
}
In case I use HW constructor it draws very fast but only part of a single string like:"test stri".
With both SW and HW I need to redraw screen in cycle in order to keep the picture visible for longer then a single frame.
So I fixed it. Yay!
The problem is related to hardware.
Those 0 resistors on the other side allowing to switch the order of supply pins are fail to be resoldered in no time.
I got 2 of those displays and on both as I found out I resoldered those resisors only partially.
So I've soldered pieces of wire instead and both display are working as expected now.
On the image resistor 1(GND) only partially soldered I guess its left metal part is gone because I had no success to solder it anyway after I found the problem.
You need to be very careful when powering those screens to get the polarity right
I have one where pin 1 is GND and pin 2 is VDD and another where pin 1 is`` VDD and pin 2 is GND
One has zero ohm resistors like yours and this may provide the facility to reverse the polarity of the power pins, but it is not clear whether that really is the case and, of course, the pin labels on the front of the board would then be wrong
My test system has the ability to accept a screen of either polarity with jumpers being used to reverse the power polarity but you still need to be careful that you get it right
Yeah I had actually another one display besides this two - the first one I bought. That's how figured out that I need to change polarity as I made a mistake on my PCB prototype. 
Those 0.96" and 1.3" are almost all the same but few of those models have pin order starting from GND instead of Vcc. And somehow I took exactly that one as example.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.