Should I limit the OLED display update cycles?

Hey there!

I am working on a small project which involves an OLED display (SSD1306, 128x64, SPI). I am controlling this display via the u8glib and for now, everything works fine.

I have done something like this:

#include "U8glib.h"

U8GLIB_SSD1306_128X64 u8g(13,11,10,9,7);

void setup()
{

}

void loop()
{

  //some stuff here

  // picture loop start
  u8g.firstPage();  
  do
  {
    u8g.setFont(u8g_font_5x7);
    u8g.drawStr(20, 20, "Hello World");
  }
  while( u8g.nextPage());
  //picture loop end
}

(Of course, this is stripped down to the bare minimum, so you can see what I am doing.)

The picture loop is executed at every cycle of the main loop, but does that make sense? I want to display some temperatures but updating the screen would only be necessary once per second.

So would limiting the update cycle (by using the micros()-function in conjunction with an if-statement for instance) be a thing to go for? For this project it might not be crucial, but it might be for other, bigger projects since I assume (correct me if I am wrong!) that it frees some processing time.

It's a thing to do. It can free up time for other processes or you can put the processor to sleep to save power if that's important. The other thing is that a rapidly changing display can sometimes be hard to read. That said, in some cases it works just fine to let it fly at full speed.

Reorder like this:

#include "U8glib.h"

U8GLIB_SSD1306_128X64 u8g(13,11,10,9,7);

char TX[50];  

void setup()
{

}

void loop()
{

  //some stuff here

    u8g.setFont(u8g_font_5x7);
    u8g.drawStr(20, 20, "Hello World");



  // picture loop start
  u8g.firstPage();  
  do
  {
           int T = random(15,150); //random temperatures 
           sprintf(TX,"%03d C", T);
           u8g.drawStr(20, 50, TX);    
  }
  while( u8g.nextPage());
  //picture loop end
}

Vulpecula:
The picture loop is executed at every cycle of the main loop, but does that make sense?

Nope. None whatsoever. :grinning:

In particular, if there is too frequent updating, then the update itself takes a substantial part of the processing time, and as this update is progressive, the part that is written first will be more visible than that written last, causing visible distortion. Possibly flickering.

It is not a problem with an OLED, but rapidly and continuously updating an LCD display interferes with the multiplexing timing and could cause a damaging DC component to the liquid crystal.

Vulpecula:
I want to display some temperatures but updating the screen would only be necessary once per second.

The rule is - you update the screen only ever if the data to be displayed, changes. You may set a flag when this happens so that as the loop passes the section which performs the data update, it decides whether to perform the update or pass over.

Vulpecula:
So would limiting the update cycle (by using the micros()-function in conjunction with an if-statement for instance) be a thing to go for?

No. See above.

There should almost never be a "while" loop within the loop() (and therefore, none in your program overall). You see, the loop() is itself an infinite while loop in which all steps are examined in turn, immediate and instant actions are taken if and only if that action is required, but immediately passing on to the next putative action.

Paul__B:
The rule is - you update the screen only ever if the data to be displayed, changes.

That's a silly rule.

Paul__B:
The rule is - you update the screen only ever if the data to be displayed, changes.

If I am supposed avoid WHILE-loops in the main loop, how would I do this then? Is it possible to put the u8glib picture loop into an external function - e.g. "draw()" - and then call "draw()" whenever something has changed? Registering changes is easy going when using flags, I assume.

(I would just try that but I'm not home for the next week. :frowning: )

Vulpecula:
If I am supposed avoid WHILE-loops in the main loop, how would I do this then? Is it possible to put the u8glib picture loop into an external function - e.g. "draw()" - and then call "draw()" whenever something has changed?

That would certainly be one (good) approach.

Putting it in its own function is merely a way of doing it more neatly than enclosing it in the main code within the "if - then" section.

The thing about "while" loops is that they should never be used anywhere in the code where there is any likelihood that the criterion will not be fulfilled promptly in order for them to exit. There should be no "busy waiting" other than the main loop() itself.