Hi - forgive if this topic was covered, I didn't see it..
I have tried the Adafruit library with my Arduino UNO and SSD1306 (128x64 OLED) and it is fast and easy to use. but is RAM hungry. Adding text soon takes me to >95%.
I tried the U8GLIB library (U8G2 refused to draw images properly..) and it was much better, 20% useage with 1 buffer. But, it was very slow in drawing.
My question is, can I trim back the buffer size of the Adafruit library, or speed up the drawing of the U8GLIB library to allow me to do other stuff?
Thanks
Kolynskij
For those displays, the back buffer is used for pixel operations since one pixel is one bit and data must be written one byte at a time (affecting 7 other pixels). The SSD1306 version of the display can't read the display RAM, only write it. If you're only drawing text and boxes, then you don't need the backing RAM. If you're drawing things one pixel at a time, then you probably do.
Yes, I understand the need for a buffer, and U8GLIB allows a 1 buffer page option. So I write the buffer and send it - so why us U8GLIB so much slower than Adafruit? The redraw is horribly slow.
Alternatively, can I tell Adafruit to use less resource?
Colin
Kolynskij:
Yes, I understand the need for a buffer, and U8GLIB allows a 1 buffer page option. So I write the buffer and send it - so why us U8GLIB so much slower than Adafruit? The redraw is horribly slow.
Alternatively, can I tell Adafruit to use less resource?
Colin
Maybe you have enabled software emulated communication.
An independent review of u8g2 and Adafruit Lib is here: SSD1306: Easily use this amazing display in any of your projects.
Oliver
Kolynskij:
Hi - forgive if this topic was covered, I didn't see it..
I have tried the Adafruit library with my Arduino UNO and SSD1306 (128x64 OLED) and it is fast and easy to use. but is RAM hungry. Adding text soon takes me to >95%.
I tried the U8GLIB library (U8G2 refused to draw images properly..) and it was much better, 20% useage with 1 buffer. But, it was very slow in drawing.
My question is, can I trim back the buffer size of the Adafruit library, or speed up the drawing of the U8GLIB library to allow me to do other stuff?
Thanks
Kolynskij
After re-reading your question, you haven't provided enough info to provide you an answer. Please answer the following:
- Are you connecting the display via SPI or I2C?
- If I2C, did you set the I2C clock to 400Khz? (it defaults to 100Khz)
- Are you drawing simple 6x8 or 8x8 text (fastest access possible)?
- Are you drawing dots/lines or text that doesn't fit on byte boundaries?
If you just want to draw 6x8 or 8x8 text and don't need a back buffer, the amount of ROM and RAM used by the OLED support code can be quite small and the display can be refreshed quite quickly (even with I2C). If you're drawing dots/lines/odd boundary text then you will need to sacrifice lots of RAM and drawing will be slower.
bitbank:
After re-reading your question, you haven't provided enough info to provide you an answer. Please answer the following:
- Are you connecting the display via SPI or I2C?
- If I2C, did you set the I2C clock to 400Khz? (it defaults to 100Khz)
- Are you drawing simple 6x8 or 8x8 text (fastest access possible)?
- Are you drawing dots/lines or text that doesn't fit on byte boundaries?
If you just want to draw 6x8 or 8x8 text and don't need a back buffer, the amount of ROM and RAM used by the OLED support code can be quite small and the display can be refreshed quite quickly (even with I2C). If you're drawing dots/lines/odd boundary text then you will need to sacrifice lots of RAM and drawing will be slower.
I am connecting with I2C for both the Adadfruit Library and the U8GLIB library
Interesting, no I didn't change the clock speed, though I will measure both versions bus rate.
I am placing a 64x64 bit graphics image. Using U8Glib I can see the 'wipe' of the re-draw after a clear
No boundary excess
It was the text support of the Adafruit library that forced me to look elsewhere. It seemed eack line of tect I didplayed (using const strings) gave me another 2-4% increase in RAM useage, and I eventually ran out.
Thanks for you support bitbank
Kolynskij
olikraus:
Maybe you have enabled software emulated communication.
An independent review of u8g2 and Adafruit Lib is here: SSD1306: Easily use this amazing display in any of your projects.
Oliver
Thanks Oliver - and wow, a celebrity answered me!
I don't believe I have enabled software communication, as I used the HW_I2C constructor, and it is working on the A4 and A5 pins.
I will check the link. I hate you to think I am criticising the library, I don't like to dis anybodies hard work; it is more a question of how I am using it.
My real point is that I am using a single page RAM buffer, filling it then sending it. On the adafruit library, this seems to be a fill, then use display.display() to write it. On the U8Glib, it seems to write it as I am filling it, resulting in a slow 'wipe' of graphics update. Am I doing it wrong? I can post my simple code if needed.
Kolynskij
Hi guys
ooh, I didn't use the HW_I2C constructor, that was in my attempt to get u8G2 working - it could be my comms that is causing the slow re-draw? I have attached my code...
Thanks for your attention
Kolynslkij
#include "U8glib.h"
#include "images_oled.h"
//**************************************************
// Change this constructor to match your display!!!
U8GLIB_SSD1306_128X64 u8g(U8G_I2C_OPT_NONE); // I2C / TWI
//**************************************************
#define x = 32;
#define y = 0;
#define width = 8; // width of the image in bytes
#define height = 64; // height of the image in lines/pixels
String bits_name = "";
String send_str = "";
void setup(void) {
}
void loop(void) {
cls();
//send_str="Nova1"; // try and write the image using a string to
//draw(send_str); // reference it. Fail!
draw();
// rebuild the picture after some delay
delay(1000);
}
void draw(String imagex)
{
u8g.firstPage();
do {
// u8g.drawBitmapP( 32, 0, 8, 64, imagex);
u8g.drawBitmapP( 32, 0, 8, 64, Nova1); // direct image draw
} while( u8g.nextPage() );
}
void cls(){
u8g.firstPage();
do {
} while( u8g.nextPage() );
}
Kolynskij:
I am connecting with I2C for both the Adadfruit Library and the U8GLIB library
Interesting, no I didn't change the clock speed, though I will measure both versions bus rate.
I am placing a 64x64 bit graphics image. Using U8Glib I can see the 'wipe' of the re-draw after a clear
No boundary excess
It was the text support of the Adafruit library that forced me to look elsewhere. It seemed eack line of tect I didplayed (using const strings) gave me another 2-4% increase in RAM useage, and I eventually ran out.
Thanks for you support bitbank
Kolynskij
I didn't mention that I wrote a library for the SSD1306 also. Mine is much simpler than the ones mentioned above, but it's fast and uses nearly 0 RAM for drawing text if you configure it. By commenting out "USE_BACKBUFFER", you won't be able draw pixels, but text drawing will work fine (on byte boundaries). I have 3 sizes of fixed font and you can remove the ones you're not using if you need to free up flash space:
Larry's OLED library
Kolynskij:
#include "U8glib.h"
void loop(void) {
cls();
//send_str="Nova1"; // try and write the image using a string to
//draw(send_str); // reference it. Fail!
draw();
// rebuild the picture after some delay
delay(1000);
}
The cls() call is not required. The draw loop will erase the picture for you.
Another problem is this: The old u8glib does not select fastest possible speed for the target display. So I guess u8g2 will be faster here.
Just for completion: U8g2 includes a text only sub-library called "u8x8". It also does not require any screen buffer, but restricts text output to 8x8, 8x16 and 16x16 pixel.
Oliver