Closed alandsidel closed 2 years ago
The OLED status detect logic is not perfect. It would be better if you explicitly specify the display type. The first image in your set shows that you're sending the 128x32 init sequence to a 128x64 display. Not sure about the rest. I'm not actively working on this code for a long time. Feel free to make changes needed for your use.
Background: I recently purchased a bag of 5 128x64 displays on Amazon and out of the box they were only semi-function. Upon startup the display was not detected by ss_oled (init returned -1) but nontheless, writing strings to them at 0x3c "sort of" worked -- strings were being written, but in the wrong location and with missing lines. Looked like an addressing/paging issue.
I dug into the ss_oled source and started debugging, and discovered that the I2C register check (ss_oled.cpp, line ~812)
I2CReadRegister(&pOLED->bbi2c, pOLED->oled_addr, 0x00, &u, 1); // read the status register
was resulting in a value of0x4
after masking off the high nibble, which doesn't match any existing screens.By adding a check for
u == 4
in addition to the existing3
and6
for the 128x64 SSD1306_3C, the screens began functioning beautifully. I did a quick test of all pixels off, all pixels on, and some strings, and all looks good. Here is a before and some after photos: https://imgur.com/a/AuQXTQYOf the five I bought, I've only tested two, but both are returning 0x4 rather than 0x3 or 0x6.
The datasheet says all the bits but the power bit are reserved so I can't say with any authority if this is a new revision of the driver chip, a bad clone, or what.
The amazon link to the screens I purchased: https://smile.amazon.com/dp/B09JWN8K99