Clearing characters in lcd.print

I am trying to display four integers in a single row which vary between 2 to 3 digits. But when any individual digit changes from a 3 digit number to a 2 digit number, the 3rd digit remains.

  lcd.setCursor(1, 1);
  lcd.print(fl);
  lcd.setCursor(5, 1); 
  lcd.print(fr);
  lcd.setCursor(9, 1);
  lcd.print(rl);
  lcd.setCursor(13, 1);
  lcd.print(rr);

If I use clear(), then the screen blinks. I have tried sprintf(), but have not been successful with it.

Any suggestions? Is it possible to always display the numbers with 3 digits? For example display the number 32 as 032.

This hasn't come up in a while.

The problem stems from the fact that once you write a character to the LCD it stays there until it is overwritten. To 'erase' a character you have to overwrite it with a 'space'.

A straightforward way to deal with displaying changing data is to:
(1) position the cursor
(2) display enough spaces to cover up all of the earlier data
(3) reposition the cursor
(4) display your new data

Don

Hi Don,

I had tried that as well, and it also makes the characters blink...

Then you didn't do it correctly!

You do these four steps four times.

In other words you replace each lcd.setCursor(...); lcd.print(...); pair with two pairs.

Don

Got it... Thanks Don!

Nope... the numbers still flicker when they are not changing.

lcd.setCursor(1, 1);
  lcd.print ("   ");
  lcd.setCursor(1, 1);
  lcd.print(fl);
  lcd.setCursor(5, 1); 
  lcd.print ("   ");
  lcd.setCursor(5, 1);  
  lcd.print(fr);
  lcd.setCursor(9, 1);
  lcd.print ("   ");
  lcd.setCursor(9, 1);
  lcd.print(rl);
  lcd.setCursor(13, 1);
  lcd.print ("   ");
  lcd.setCursor(13, 1);
  lcd.print(rr);

da40flyer, the way to avoid most (but not all) of the flicker is to print the 16 spaces all at once to clear the full line.
i..e

// clear the line
lcd.setCursor(1,1);
lcd.print("                ");
// now print the numbers just like it was done originally.

Even better is use sprintf() to create a full line buffer, then print the line.
That way not only will there be no flicker, but you can control the digit alignment so that the digits won't shift around as the variables values change - which can make this hard to read and create what appears to be flickering as well.

Something like this:

char buf[20]

sprintf(buf, "%3d %3d %3d %3d ", fl, fr, rl, rr);

lcd.setCursor(1,1);
lcd.print(buf);

If you want the numbers 0 filled then you use %03d instead for the format string.

--- bill

There is no need to continually update your display. Of course it will flicker.
You only need to write to the LCD when a value changes.

Your display would look nicer if you are right justified. e.g.

    If (val < 100) lcd.print(" ");
    if (val < 10) lcd.print(" ");
    lcd.print(val);

Pad with 0 instead of a space if you prefer.

I still reckon that you only need to write to the display when the values change but with the right justified approach, you will not notice any flicker.

You might find it handy to make a helper function that positions the cursor, prints a justified value.
You can re-use it in other sketches.

David.

Bill, that worked!

David, I will try your suggestion as well.

Thank you all!

david_prentice:
There is no need to continually update your display. Of course it will flicker.
You only need to write to the LCD when a value changes.

None of the hd44780 displays I have ever used flicker no matter how fast or slow the display is updated as long as long as no character positions are unnecessarily cleared before being re-written.
It is the clearing of character positions that are to be overwritten that causes flicker.
i.e. if you are updating a number, do not clear the digits first and then write the new digits, just overwrite the new numbers on top of the old making sure to output any needed digit padding at the same time.

You might find it handy to make a helper function that positions the cursor, prints a justified value.
You can re-use it in other sketches.

I prefer using the xxprintf() functions which provides easy to control output formatting as well as the ability to blast out full lines to the LCD which is a bit faster than updating individual fields.
Yes it eats up 1.8k of code on the AVR, but if the space is there, it is well worth it to me.

— bill