So I bought one of those cheap i2c 128x64 OLED displays from a well known Chinese site. I spent ages trying to get this to work using u8g2 with no success (Took the standard hello world demo supplied with it and tried every i2c constructor).
I managed to get it to work very well with the Adafruit SH1106 library, but I think this library uses an in memory frame buffer which uses so much memory that I am now getting stability problems on my Uno (I want to display graphics on the display so don't want to use a text only library) and don't want to go to a Mega just yet as I intend to use a Nano in the final project.
Has anyone any advice on how to use the u8g3 library with this display? I believe the u8g2 uses some sort of paging scheme which reduces memory requirements.
Thanks
S.
Do you really have SH1106 ?
It is different to SSD1306.
There is no official Adafruit_SH1106. It is a third-party hacked version of Adafruit_SSD1306
Has anyone any advice on how to use the u8g3 library with this display?
I have never heard of u8g3.
u8g2 can work with a small page buffer. It makes programming "different" to the Adafruit_xxxx style.
I suggest that you use all the usual "tricks" to reduce SRAM. e.g. text messages in PROGMEM, appropriate type(s) for variables. Appropriate size of arrays.
David.
Yes the official Adafruit SSD1306 also didn't work. It was only a comment in the feedback for the product on the sellers site which suggested using this library.
I have tried every memory reducing trick I can find and still have only 380 bytes left. The project works but I struggle adding any more functionality and the results are unpredictable (local variables changing and sometimes the whole thing resets).
I might have to hack the hacked library but wanted to avoid that.
From the product page "SSG1106 compatible with SSD1306 basic, difference is that SSH1106 control chip RAM space is 13264, while SSD1306 space is 12864. The 1.3-inch OLED 128*64 dot matrix, so in the middle of the screen production took 128 row. When using SSD1306 program point SSH1106 screen, only need to change address to 0x02 row to start."
really not sure what it means by "only need to change address to 0x02 row to start." - this can't mean the i2c address.
From memory, SH1106 is 132x64. SSD1306 is 128x64.
SSD1306 has scroll commands that the SH1106 does not.
The obvious strategy is to try U8g2 examples with both constructors.
The current Adafruit_SSD1306 is naughty. It allocates memory for its buffer at runtime.
The build report shows plenty of SRAM. You lose 1024 bytes when it goes for a 128x64 buffer at runtime.
If the build said 1404 bytes available, you get left with 380 bytes as soon as the program runs.
If the build said 380 bytes available, the buffer allocation would fail.
380 "usable" bytes should be fine for most graphics programs.
Paste or attach your sketch. Readers might suggest some memory tips.
Icons, graphic images, text, data tables, ... all need to go in PROGMEM
David.
Took a while, but I eventually took the 3rd party library based on the adafruit one and stripped out everything I didn't need.
Also this library defined the screen buffer as a static array of bytes. With this I get the memory warning. When I changed it to be a pointer and dynamically allocated the screen buffer the warning went away (assuming its only because the compiler can't estimate variable usage?). Also my random stability problems also went away.
It's been 15 years since I touched c++ 