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