0.91" OLED Display, SSD1306, Issue with clearing

Using Arduino Displays
1

Hello all,

I am trying to design a digital speedometer for use on a motorbike. I've got the code working, speed is calculated correctly, but I am having a small issue displaying it.

The display part of the code has to be put in the loop, since it's dynamic (value changes in time). This is where I encounter the issue - the first iteration of the code didn't clear the existing value and simply wrote over it - after a few minutes the digits all fused together into almost entirely filled rectangles - no good.

I then play about with drawing a black filled rectangle over the area - this indeed worked, but the flicker was unbearable - no good either.

I now am looking at a better option, following the advice from HERE - this seems to work great, however, only if the speed is a single digit. Once I venture into double digits, the first digit clears well, but the second one stays - so let's say I started at 0km/h, then sped up to 15 km/h, then immediately stopped - the display will show 0, then 15, then 05 - this is clearly an issue, as I'd like it to show just the 0.

Here is my section of the code that pertains to this specific issue:

  display.setTextSize(2);
  display.setTextColor(WHITE);
  display.setCursor(0, 10);
  display.println("Spd");
  display.setTextColor(WHITE, BLACK);
  display.setCursor(40, 10);
  display.println(speed_kmph);
  display.setTextColor(WHITE);
  display.setCursor(80, 10);
  display.println("km/h");
  display.display();

Anyone came across a similar issue and is able to offer assistance?

2

You could use snprintf to print to a specific number of digits e.g. "%3d", and then print the buffer.

3

You could overwrite only digits that changed when they changed. To do this you need to store last value and compare to the new value. You definitely don’t need to reprint the units of measure and other stuff that never changes

4

It really does not matter if you re-write the whole screen. This all takes place in the SRAM buffer. Nothing goes to the physical display until you call display.display();

So you will never notice any flicker. The changed pixels will just appear silently.

Follow the advice in #2. i.e. format the output nicely.
Use display.setTextColor(WHITE, BLACK); to ensure a fresh background is drawn when you write text.

Oh. #3 is the correct approach for drawing to an un-buffered display like a TFT. i.e. only re-draw areas that have changed. Use setTextColor(fg, bg) instead of separate fillRect(x, y, w, h, bg)

David.

5

I have SSD1306 OLED and used it in a project which has high update rate of display value and no flicker because it updates only what needs to be updated. But thank you for sharing display method that I don’t even have.

6

Thanks everyone for your help - it sure as did work! And it's beautiful - onto the next problem now :slight_smile:

For sake of future generations struggling with the same issues, below is the code that I have that works:

  display.setCursor(0, 10);
  display.setTextColor(WHITE, BLACK);
  char buffer[10];
  sprintf(buffer, "Spd %d km/h", speed_kmph);
  display.print(buffer);
  display.display();
7

"%3d" might be a better choice.

8

It will keep the position of the text after the value constant, so probably easier to read - agreed.

Thanks

9

I'd probably print "Speed" and "km/h" just once once

10

Sorry, I don't follow your last post.

I plan to have multiple screens that I flick between with a button, hence why I have to have some info as to what is being currently displayed.

11

So, print the fixed text once when the screen is initially selected, and then just do the numeric updates.

Drawing to these screens is slooooow.

12

I am sorry, you're going to have to be a bit slower with me! What's the advantage of that, other than its more elegant? I thought these screens don't print the areas if there's no change?

13

That writes the whole "Speed 999 km/h' string every time it is called.

Let's say each character is 8x8 pixels, so that's 14x64 individual pixel writes
Over I2C, that's a long time.

14

I struggle with that and the advice given in #4 above - I tested the code and there's no flicker, what's the downside of the code as I have it now?

15

You're right - the whole screen has to go over I2C, but the 64x14 pixel writes still have to be written to memory, and that's not fast.

16

Ok, I think I follow now.

What's the solution to this problem - some sort of an if statement to avoid rewriting the text that does not change?

17

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.