LCD 16x2 (HD44780) with I2C has very slow refresh rate

Other Hardware Displays
1

Hi,

I just bought a 16x2 and I2C interface to it. Everything seems to be working fine (not sure if 4 or 8 bit?) but the only problem is refresh rate. When scrolling or fast changing text it is not visible because the "shadow" of the previous char. The only way to make it better is to set contrast with potentiometer to very low that text is actually black not white (it is negative display BLUE with White text).

Do you know what is the problem? I am seeing all of those youtube videos where they are even doing some nice animations with very good FPS but I am not able to display single text faster than ~800ms.

2

Do you know what is the problem?

We can't tell without seeing your code but the problem may be due to the fact that you should not be refreshing the display. Once you send a character to the display that character will stay there until it is overwritten, there's no refreshing for you to be concerned with.

Don

3 
#include <Wire.h>
#include <LCD.h>
#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);
void setup() 
{
  lcd.begin (16,2);
}

void loop()  
{
  lcd.home();
  lcd.clear();
  lcd.setCursor(0,0); 
  lcd.print("Hello, world!");
  delay(500);
  lcd.setCursor(0,0); 
  lcd.print("Hfsdfsfertertr");
  delay(500);
}

and

#include <Wire.h>
#include <LCD.h>
#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);
void setup() 
{
  lcd.begin (16,2);
}

void loop()  
{
  lcd.clear(); 
  lcd.setCursor(0,0); 
  lcd.print("Hello, world!");
  delay(500);
  lcd.clear(); 
  lcd.print("Hfsdfsfertertr");
  delay(500);
}

both are giving the same results. When I try scroll example it is even worse as I cannot read anything. There is this kind of shadow where the pixels were lit. As I wrote the only way to get rid of it is to set minimum contrast where text is black, but that should be the point of negative diplay right that text is white (on blue in this case)
Another question, is there a way to control brightness? I know I can ON/OFF it but can I regulate it?

4

Here I tried to record it.

It's actually quite hard to record such a display but hopefully you can see the point

5

I don't see what you do on my display with your code, but try this loop and see if it performs better. Printing blank spaces is the fastest way to clear the screen.

void loop()
{
  //lcd.home();
  // lcd.clear();
  lcd.setCursor(0, 0);
  lcd.print("                ");
  lcd.setCursor(0, 0);
  lcd.print("Hello, world!");
  delay(500);
  lcd.setCursor(0, 0);
  lcd.print("                ");
  lcd.setCursor(0, 0);
  lcd.print("Hfsdfsfertertr");
  delay(500);
}
6

The I2C interface is 4-bit. The eight bits of the interface chip are used for 4 data bits, Enable, Read/~write (not actually used), Register select and backlight. There is essentially no advantage in speed or otherwise, in attempting to use an 8-bit mode.

lcd.setCursor(0, 0); is implicit in lcd.clear(); so use one or the other, but not both together.

Since you know what you are going to write and what you have written, then it is simply not useful to either clear the display or write all blanks to it, simply (set the cursor,) write the new text and any further blanks required to cover the previous. This also applies to the common problem of leading zero suppression and fixed positioning of numbers.

Finally, the behaviour you observe with the brief "after-shadow" is in fact perfectly normal behaviour for this sort of LCDs (unlike video displays with few-millisecond response times). It is also temperature-dependent.

Rapid scrolling is in any case entirely meaningless because it is performed character-by-character rather than pixel-by pixel as you can with a matrix display so it cannot be visually followed in any case.

7

@terragady

The following is essentially the second version of the code from your reply #2 revised to eliminate the use of 'clear' statements.

#include <Wire.h>
#include <LCD.h>
#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);
void setup()
{
  lcd.begin (16,2);
}

void loop() 
{
  lcd.setCursor(0,0);
  lcd.print("Hello, world!   ");
  delay(500);
  lcd.setCursor(0,0);
  lcd.print("Hfsdfsfertertr  ");
  delay(500);
}

Does this improve things?

Don

8

Nope I tried both and the result is the same. Maybe it is just crappy LCD or I2C interface, in the end it is from china. Although it is fine for temp readings with 1s refresh. I read something bad resistor in some of the diplays causing a lag where solution is to use busy flag.

9

Paul__B:
...
Finally, the behaviour you observe with the brief "after-shadow" is in fact perfectly normal behaviour for this sort of LCDs (unlike video displays with few-millisecond response times). It is also temperature-dependent.
...

The problem you see (<-- read it isn't, but you experience it as such) has nothing to do with the interface or some resistor on the board.
It is part of this kind of displays.
There might be differences between displays themselves, but the behaviour is in all of these displays.

If you really need to do this, with a display similar to the one you have right now, perhaps you can consider using an OLED display.
Some of those come in very similar size.
But before you go and order any of those, see whether or not they are Hitachi compatible.
And if not, if you can overcome that by using another library to control the display.

10

I read something bad resistor in some of the diplays causing a lag where solution is to use busy flag.

Hogwash.

Don

11

MAS3:
The problem you see (<-- read it isn't, but you experience it as such) has nothing to do with the interface or some resistor on the board.
It is part of this kind of displays.
There might be differences between displays themselves, but the behaviour is in all of these displays.

Hey, yes, I write explanations for things, but as in many other disciplines, it's not the answer people want to hear, so they just ignore the explanation. :roll_eyes:

MAS3:
If you really need to do this, with a display similar to the one you have right now, perhaps you can consider using an OLED display.
Some of those come in very similar size.

Perfectly effective, but ridiculously expensive.

floresta:
Hogwash.

+1 for that!

12

Yeah, thinking in solutions might end up in me loosing the eye for cost effectiveness.
But to my defence, i did start the sentence with "If you really need to do this" :wink:

13

ok guys ok, i do really understand. It is my beginning with arduino and programming although in this I have some "home" experience (even from medieval ages with C64 & Basic).
So as I understand I also cannot regulate brightness right? Is it only impossible because of I2C interface or because of the display itself? As I see it is normal LED so I should be able to dim it like normal LED through PWM pin.

14

You are controlling that display through the I2C bus and a chip which sends bits to the display.
As explained, that's most likely a 4 bit bus, plus some control bits, of which one might be an on/off switch for the backlight.
You could try to do PWM like switching of that bit, but that would probably end up in a poor working control (to say it in a nice way).
If you want to dim the backlight with a clean PWM signal, you would need to remove the connection of the backlight LED to the control chip, and replace it with a PWM signal from one of the Arduinos' pins.
You might need to use a transistor if the backlight needs a higher current and a resistor if the current needs to be limited (meaning if there is no resistor on the board of your display).

15

MAS3:
As explained, that's most likely a 4 bit bus, plus some control bits, of which one might be an on/off switch for the backlight.

One of which is the backlight control, via a tiny transistor on the "backpack".

A basic misunderstanding is that proportional dimming of the backlight is necessary or appropriate. There are three modes in which you might want the backlight to operate; day at full brightness, night at reduced brightness, and off.

In any application, only two of these modes will generally be necessary. The backlight may be dimmed by substituting the jumper on the backpack with a resistor. A default minimum brightness may be set by a resistor connecting either pins 1 and 16, or 2 and 15, depending on the design of the backpack. These two controls may be used together if you never want the original maximum brightness.

16

For the records: The drive voltage has huge impact on the speed of an LCD.

Dropping the supply voltage from 5V to 3.9V for instance makes an LCD almost unbearable slow.

Measure your supply on the LCD and make sure that it's 5V.

17

And for the record, the drive voltage has nothing at all to do with the speed at which the HD44780 (equivalent) LCD driver is updated with new display data. It actually operates just fine - and equally fast - at 3.3 V as there are variants of the 1602 modules which operate at this voltage.

Certainly at a lower voltage, the LCD panel itself might be slow but in fact, if you lower the drive voltage (which is actually the contrast voltage) below about 4.2 V, you simply have no display at all. The variants of the 1602 modules which operate at 3.3 V incorporate a charge pump to bring the contrast voltage back up toward 4.8 V.

It might be the case that LCD panels in general which are designed to operate at lower voltages, are slower, but the working contrast voltage for any given panel, particularly those multiplexed such as the 1602 and similar displays, is within a strictly limited range.