Faulty 1602 display?

Hi there,

I got a kit as a Christmas gift and playing with it since. Really enjoying it!

Anyway, the kit contained the 1602 display plus the driver for i2C bus. I soldered them together and when I run the i2C_scanner, it finds a device on address 0x3F.

I2C Scanner
Scanning...
I2C device found at address 0x3F  !
done

I modified the hello world example for 0x3F, but when running, I do not get anything on the display, only the top row is showing squares. Playing with the brightness trimmer changes the light intensity, but no text appears.

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

LiquidCrystal_I2C lcd(0x3F,16,2);

void setup()
{
  lcd.init();
  lcd.backlight();
  lcd.print("Hello, world!");
}

void loop()
{
}

Can it be a faulty display module? Or maybe a bad soldering? Please advise.

Thanks, Honza

More likely you are using a library that is not compatible with your particular I2C adapter. There are literally dozens of threads about this problem.

Look for the 'HD44780' library which is relatively new and it should solve all your problems. Bill, the library author, will likely chime in here shortly.

Don

Edit: Using the library manager is the best approach, otherwise get it here: https://github.com/duinoWitchery/hd44780

Thanks for the reply. I tried the HD44780 library — it does different thing now, but still not good. When I tried the HelloWorld example from the HD44780 library (examples → ioClass → hd44780_I2Clcd → HelloWorld), I get this:

https://youtu.be/r5SqTx727w4 (the display flashes for full light for approx 0.5sec, then goes dark, several short flashes and then it loops).

I tried the auto i2c address as well as fixing the address to 0x3f, the result is the same with both.

btw. this is the i2c driver that I soldered on the other side of the display:

|500x223

Any more advise welcome.

/Honza

Thanks for the reply. I tried the HD44780 library – it does different thing now, but still not good. When I tried the HelloWorld example from the HD44780 library (examples → ioClass → hd44780_I2Clcd → HelloWorld), I get this:

You are using the wrong class. You need
examples → ioClass → hd44780_I2Cexp → HelloWorld

From the github read me

The library currenly comes with the following i/o subclasses:

hd44780_pinIO control LCD using direct Arduino Pin connections

hd44780_I2Cexp control LCD using i2c i/o exapander backpack (PCF8574 or MCP23008)

hd44780_I2Clcd control LCD with native i2c interface

hd44780_NTCU165ECPB control Noritake CU165ECBP-T2J LCD display over SPI

Hi,

I did the exact same thing with my display XD

It turned out that I had not tuned the contrast properly, making it turn white like that.

I'm not too sure about the I2C module, but when you wire an LCD directly to the atmega you have to declare it like this, specifying the size of the display.

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

This could possibly explain things because not "beginning" a display causes things like that to happen. Also, don't forget to declare the size of the screen, like I showed in the first example. I don't know much about the I2C module, but that might explain things.

Hope that helps!

EDIT

If it really isn't working, consider hooking the screen directly to the atmega. It is simpler, and I should think it would work a bit faster.

It turned out that I had not tuned the contrast properly, making it turn white like that.

Improper contrast will cause both lines of two line displays to appear 'like that', not just the top line.

... and I should think it would work a bit faster.

The speed (or lack thereof) is essentially determined by the requirements of the LCD controller.

With the LCD connected directly to the Arduino the library must insert a lot of delays to keep the LCD controller happy.

Most I2C libraries leave those delays in place so the added overhead of the I2C communication does indeed slow things down, but that added delay is imperceptible to most humans.

It is my understanding that in the HD44780 library Bill adjusted the required delays to account for the I2C overhead.

Aren't you glad that you didn't have to do all that?

Don

cattledog: You are using the wrong class. You need examples → ioClass → hd44780_I2Cexp → HelloWorld

Oh yes, fantastic, working now!

Thank you very much!

honza-skypala, You could run the I2CexpDiag sketch to test out everything if you really want to be sure everything is ok. That will test the i2c pins and test the internal RAM of the LCD.

floresta: It is my understanding that in the HD44780 library Bill adjusted the required delays to account for the I2C overhead.

While the library does account for I2C overhead, it is actually even smarter. It also allows the LCD to execute its instruction while the AVR is freed up to do other things. So if the AVR does some things between telling the LCD to do something like writing a character that takes longer than the amount of time the LCD needs , there will be no added delays. I have not seen any other library that does this. The value of this is that it self adjust the delay based on the dynamic situation which by default takes into consideration the speed of the processor.

In terms of using the wrong, hd44780 i/o class, yeah, reading seems to be a lost art these days. A lot of the issue is that the library is incomplete, still in alpha state and not truly ready, and normally I would not release stuff like this. However I felt for so many of the users struggling with getting their i2c backpack based LCDs up and running and often getting unhelpful and/or incorrect information or advice like what we just saw in post #4 that I went ahead and made it available.

On the positive side, I'm going to go back into all the HelloWorld examples and include what LCD h/w they are for. I had plans to do this anyway but this makes it clearer that the added information will be helpful. I'm not sure why I originally didn't do this. It was a total oversight on my part.

As a bit of history, the first iteration of this library package had a separate installable library for each class. I changed it to make things simpler and easier to install and maintain. A few things like this got overlooked when I smooshed them all together. But the intent is to make things as easy as possible. The main thing missing right now is some proper documentation. It is coming......

--- bill