search

ThingPulse / esp8266-oled-ssd1306

Driver for the SSD1306 and SH1106 based 128x64, 128x32, 64x48 pixel OLED display running on ESP8266/ESP32
https://thingpulse.com
Other
2k stars 638 forks source link

SSD1306 I2C: .96 displays okay, 1.25 garbled #233

Closed RanTalbott closed 5 years ago

RanTalbott commented 5 years ago

This appears to be the same as #93, which was closed without resolution.

It's also happening with the Adafruit libraries.

I have a few .96" displays, and a couple of 1.25" ones, bought from different vendors.

All work fine on AVR-based Arduinos, but only the .96 ones do on ESP8266 Wemos D1 Minis.

The symptom is that only a narrow horizontal band of pixels (it appears to be 8 high) is being written to, and the rest are filled with garbage(mostly on pixels, with a scattering of off ones). With some applications, it's always in the same screen location. With your clock demo, it moves, and sometimes gets scrolled down. It looks like the garbage-filled areas of the screen are getting scrolled intact, but I can't be sure, since there are almost 8000 pixels in them ;-)

This happens with both hardware (D2, D1) and software (D3, D5) I2C.

Symptoms are the same with Arduino IDE 1.8.4 + ESP8266 2.3.0 and Arduino IDE 1.8.5 + ESP8266 2.4.0 (only tested your clock demo on 1.8.5)

It looks like there's a difference in the row (and maybe column??) address mapping between the two models of display, but I'm at a loss as to why the AVR code might handle it correctly when the ESP8266 code doesn't. Some compiler optimization quirk in the address mapping calculation???

RanTalbott commented 5 years ago

Oops: I neglected to mention that all the displays are 128x64.

And I should clarify that all writing is done to that horizontal band: it gets the pixels for each group of rows, not just the ones at its location on the screen. In the digital portion of the clock demo, I can see that the vertical slices of the digits are being written at different horizontal offsets, so all the address translation is wrong.

mpetike commented 5 years ago

The 1.3 inch displays actually use the SH1106 controller, not the SSD1306. Vendors make it confusing by labeling all 128x64 oled displays as SSD1306.

RanTalbott commented 5 years ago

The 1.3 inch displays actually use the SH1106 controller, not the SSD1306. Well, at least it looks like mine do. I don't know why they worked when I tried them on the Arduino: I must have been mistaken about which sketch I had loaded in it. When I loaded one for SSD1306, it started screwing up, too.

I've tried about 5 different libraries that claim to be adaptations of Adafruit's SSD1306 to the SH1106. Most are junk, and didn't work at all. The one from wonho-maker here on github seems to be working on AVRs (does all the operations in the sample correctly). I got clean ESP8266 compiles by fixing a few things like the #includes for pgmspace and delay, and the typdefs for hardware registers. But it doesn't do anything to the display (not even clearing it). It's frustrating, because I have a mix of OLEDs and LCDs, and would like to use a consistent API across as many of them as possible.

Thanks for the info: it didn't save me any frustration, but it saved me a bunch of time trying to do the wrong thing to resolve it ;-)

stale[bot] commented 5 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

toastedcode commented 8 months ago

Just want to second: the Hosyond 1.3 Inch I2C OLED Display Module (128x64) I am using does indeed use the SH1106 controller. Switching from the Adafruit SSD1306 to the Adafruit SH110X library finally got me working. Thanks mpetike!