Reported Arduino Revision: 1.6.7
CPU ARCH: AVR - F_CPU: 16000000
SDA digital pin: 18 A4
SCL digital pin: 19 A5
Checking for required external I2C pull-up on SDA - YES
Checking for required external I2C pull-up on SCL - YES
Checking for I2C pins shorted together - Not Shorted
Scanning i2c bus for devices..
i2c device found at address 0x27
Total I2C devices found: 1
Scanning i2c bus for all lcd displays (4 max)
LCD at address: 0x27 | config: P01245673H | R/W control: Yes
Total LCD devices found: 1
LCD Display Memory Test
Display: 0
Walking 1s data test: PASSED
Address line test: PASSED
Each working display should have its backlight on
and be displaying its #, address, and config information
If all pixels are on, or no pixels are showing, but backlight is on, try adjusting contrast pot
If backlight is off, wait for next test
Blinking backlight test: to verify BL level autodetection
If backlight is mostly off but
you briefly see "BL Off" on display with backlight on,
then the library autodetected incorrect BL level
and the library cannot autoconfigure the device
Displaying 'uptime' on all displays
LCDlibTest blinks the UNO LED about 1Hz and leaves the OLED display all black so I tried with a fully working LCD display using it's own backpack that works properly but nothing appeared on the LCD except the top row showed 5 x 8 block characters
Ok.
That seems like a good repeatable test.
I remember getting frustrated with a similar/same issue and using a similar reset test on an IST0010 based OLED.
If i remember correctly I even altered my library do the exact instruction sequence including timing in their datasheet and even some variations and I could not resolve it.
I think you are seeing the same issue I was seeing on the IST0010 in that the initialization was not reliable, but once it succeeded, the chip seemed to work ok other than CLEAR-DISPLAY doesn't home the cursor - but that is a separate issue.
Since it appears that display uses the same or similar controller to the IST0010,
I'll dig up one of my IST0010 OLED displays and have a look again.
It may be a few days before I come back with any results.
LCDlibTest starts off by hammering the interface and display with instructions/writes to measure the byte transfer rate.
That part of the test can trigger any marginal timing issues.
You do NOT want capacitors on the SDA and SCL lines. That will totally defeat the purpose of I2C which is an open-ground connection. When the MC pull the line low, it will be fighting your capacitors. If your display doesn't have them, you would need 10K pull-up resistors on SDA and SCL but definitely not capacitors.
For some background, here is a thread that is somewhat related.
It was for an OLED display that used the IST0012 chipset vs the 0010
I found one of the OLED displays I was using.
Depending on which datasheet I look at for it it uses a 0010 or an 0012.
So I'll have to do some testing on it to verify which one (and then label it!)
Crazy....
--- bill
I think the Aliexpress link is for an LCD module, not an OLED, despite the fact that OLED is mentioned in the product title - but many Aliexpress descriptions are incorrect. The part number is SLC1602N Blue LCD, Surenoo LCDs start SLC and their OLED displays start SOC.
There are definitely compatibility issues in the 0010 & 0012 chipsets as they are not fully and transparently compatible with the hd44780 chipset instructions.
For the 0010, I still need to do some testing to see if I can figure out something that is reliable.
I'm planning on hooking up a logic analyzer to look at the signals for when it works vs when it doesn't to see if there is anything different happening on the display control and data pins.
--- bill
For the 0012 chips it is hopeless in 4 bit mode.
Those chips defined an alternate command set that uses 0x3 to enter it and 0x00 to exit it. BIG mistake.
This can causes problems when using the hd44780 initialization sequence. Essentially there is no reliable way to recover nibble sync on that chip if it ever gets lost as the hd44780 initialization sequence won't work on that chip due to their command set extensions.
Even 8 bit mode could have issues. The 0012 may "work" in 8 bit mode, but if it ever happened to get into 4 bit mode and lose nibble sync,which could easily happen since all it would take is to send an odd number instructions to the display after it entered 4 bit mode.
If that were to happen, there is no way to reliably re-initalize the display.
i.e. it takes a power cycle to recover.
So my advice is to avoid displays that use the 0012 chipset especially if wanting/needing to run in 4 bit mode.
Bill - in view of the possibly insurmountable issues with incompatible display controller chips, what is your opinion about using a digital IO pin (or two paralleled) to power the display, so it can be power cycled under software control, providing the MCU electrical parametric limits are not violated?
I beg to differ. I mean, all you had to do was search for the word "capacitor" and you would have found it. Did you think I just said that to make myself sound smart or something? it was in direct response to something the OP said he tried.