Updating OLED display without blocking other code

Hello! I am attempting to use this SPI OLED display with my project: https://www.amazon.com/gp/product/B01MZ8AOIF

I am using the Adafruit GFX library and the SSD1331 library for the display. I need to be able to update the display without interrupting my program. It's critical that the display does not affect the performance. Is it possible to update the display in a non-blocking way? If I do something such as clear the display and write text, my code freezes and waits until the display is finished updating to continue. Is there any way around that?

This is my first time dealing with a display, so any advice in this area is appreciated!

Any ideas on this? From what I've gathered, the more pixels written, the longer it takes... Is there a way to procedurally update the display? Say, draw 4 pixels every time on each loop instead of the entire screen? Is there any way to do this with the Adafruit GFX library or would that involve re-writing a bunch of things?

Any other ideas?

The usual solution is to implement time critical jobs as an interrupt procedure. I have not done this on an Arduino, but it looks like, that there are some libraries for this (Timing - Arduino Libraries). The idea is, to refresh the display in the Arduino main loop and to do any time critical calculation in the interrupt procedure. The interrupt procedure will have priority and whatever time is left, can be used for the display refresh.

Oliver

Explain which library example and which part is too slow.

If it is your own code, paste it to your message, attach a ZIP or post a link to repository e.g. GitHub.

I have never used a colour OLED. It will take 16 SPI bytes to draw 8 pixels on a colour OLED. It only takes 1 byte to draw 8 pixels on a Monochrome OLED.
I would expect a similar performance as a 128x128 TFT e.g. ST7735 or ILI9163.
The TFT libraries are very quick.

Your SSD1331 is only 96x64. So will be a lot quicker than the bigger SSD1351 128x128 OLED.

With a monochrome 128x64 it is common to manipulate a buffer in SRAM. Then blit the whole 128x64 to the OLED in one go.
Since a colour OLED requires 16x the traffic, you only draw the area that has changed. The performance of your app comes down to your "intelligence" when choosing the minimal area(s) to update.

David.

Thanks for the replies guys! Sorry I didn't post any code, but I can't do that for this project and I don't think it's really necessary to describe what I'm trying to do.

If I went the interrupt route, would I basically move the entire contents of my main loop into an interrupt routine and update the display in my main loop? Is it really as easy as that?

If I don't go the interrupt route, then maybe I should look into using a monochrome OLED which might be faster. But I do really like the color display!

Another option would be a workaround - only update the OLED display when I am in "settings" mode and it would suspend all other operations until settings are adjusted and saved, but that doesn't seem like an ideal workaround.

If I went the interrupt route, would I basically move the entire contents of my main loop into an interrupt routine and update the display in my main loop? Is it really as easy as that?

Yes, exactly.
Problem is, you need to look for a suitable Arduino Library.

Oliver

olikraus:
Yes, exactly.
Problem is, you need to look for a suitable Arduino Library.

Oliver

I will definitely look into it! Could you elaborate on why a library is needed?

I will definitely look into it! Could you elaborate on why a library is needed?

If I remember correctly, the Arduino IDE does not provide timer based interrupts. So for the creation of repeated/perodic tasks you need a library.

Oliver

olikraus:
If I remember correctly, the Arduino IDE does not provide timer based interrupts. So for the creation of repeated/perodic tasks you need a library.

Oliver

Ah, I see! I will look into that. Thank you!