LCD rightmost character not refreshed properly

Other Hardware Displays
1

Hi all

We have here a very simple program. First read pot, map value then display to LCD.

Check out this YouTube clip.

Program is running, we turn the pot and value is changing on display. Problem is somehow the rightmost character is not being refreshed properly. On the clip you will see when 1000 mA drops to 900 mA, there is a double "A" displayed. Something wrong with the code or our LCD?

BTFDev.

#include <LiquidCrystal.h>
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

unsigned int minAmpSet = 0;
unsigned int maxAmpSet = 3000;
unsigned int sensorValue;

void setup() {
  lcd.begin(16, 2);
}

void loop() {
  // read the input on analog pin 0:
  sensorValue = analogRead(A0);
  
  sensorValue = constrain(sensorValue, 0, 1023);
  sensorValue = map(sensorValue, 0, 1023, minAmpSet, maxAmpSet);
  
  lcd.setCursor(0, 0);
  lcd.print("Current");
  
  lcd.setCursor(0, 1);
  lcd.print(sensorValue);
  lcd.print("mA");
  delay(500);
}
2

I had exactly this lastr week... the screen doesn't "refresh" as such, it simply writes what you send it each time, leaving previous characters in play. You're sending fewer characters to an area where there was a longer string in the previous write, so the last character is "still there" from the previous time.

So first when you send 6 characters it says:
1000mA

then you send 5 characters and so it says:
900mAA

since the "A" of "1000mA" is still on the screen.

I added a line to my code to write a " " to clear out the appropriate part of the display between each write. Not sure if there's a more elegant way, but that worked for me...

HTH?

3

small remark about the code...

sensorValue = constrain(sensorValue, 0, 1023);

Not needed as analogRead() will allways within this range

Some LCD's have a clear function or clear line function which is faster than writing spaces.

4

Thanks for the input.

The more I read about this subject, I found more reason to believe something wrong with the LCD.

Hacktronics posted their project, their usage of LCD and code, I don't see anything specific or additional white space needed. This is very strange.

BTFdev.

5

btfdev:
The more I read about this subject, I found more reason to believe something wrong with the LCD.

Go back and read response #1.
It explains what is happening.
You are not printing the same amount of characters all the time.
Some times you print 6 and sometimes you print 5.
When you print 5 characters "900mA" after printing 6 "1000mA" there will be an
extra left character on the display from the previous printing of the 6 characters.
If you don't want "trash" to be left over when you update the display you must ensure
that you either clear the display (which will cause flicker) or completely overwrite all the previous
characters with the new characters.
You are not doing either of those, so you see "trash" left over on the display.
In your case you are seeing a left over "A" from when you write 6 characters and then
you start to only write 5 characters.

To avoid flicker you will need to add code to check for the value and print a when it starts
to fall below certain points.
i.e

* * *

if(sensorValue < 1000)
  lcd.print(' ');
if(sensorValue < 100)
 lcd.print(' ');
if(sensorValue < 10)
 lcd.print(' ');
lcd.print(sensorValue);

* * *

Then print the sensor value.
This will ensure that you always print 4 characters for the sensor value.
The leading digits will be earase. If you want you can change the to '0'
to get leading zeros.

--- bill

6

Oh boy. Thank you for clearing things up.

We always thinking about screen refresh and never thought this is actually by design.

Thanks, BTFDev

7

Read about sprintf if you want an elegant solution. I have a tutorial on this subject.

8

Rather than using sprintf() and having to worry about how large of a buffer to allocate,
and formatting strings eating up your SRAM,
here is a little set of macros and functions I wrote that will give you printf() support for your lcd.
It also automagically pushes the formatting strings into flash so they don't eat up precious SRAM.
It is contained in the header file lcdPrintf.h in the zip image attached.
(note: rather than printf() the name is lcdPrintf() )

See the instructions in the header file for how to use it.

Also, keep in mind that using the xxprintf() routines will eat up around 1.8k of code space.
So while the xxprintf() routines make output formating really easy, if the formatting is very simple and limited,
then using the Arduino supplied Print class functions can be substantially less code
even though using the Print class functions may require a bit of ugly code to handle some of the formatting.

--- bill

lcdPrintf.h.zip (825 Bytes)

9

Darn, iPad won't open zip files. I'll have to use my main computer to read your code. Right, formatting strings take up SRAM. I wonder if you have an SRAM buffer for formatting strings.