LCD not displaying anything

Hey,I have been working on a school project over the past few days but the code wasn't working for some reason. Therefore, I connected the LCD to the Arduino Board directly and put in the Hello World Program. The code compiles perfectly and uploads as well onto the board but for some reason there is no output on the screen even though the back light of the LCD is ON. Can anyone tell me the reason? Thank you!

The LCD model is 1602 16x2 Character LCD Display Module HD44780 Controller Blue/Green screen blacklight LCD1602 LCD monitor 1602 5V.

The Arduino Board I am using is Arduino UNO R3 Compatible Atmega328P Board.

The code I was using was as follows:

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

LiquidCrystal_I2C lcd(0x3F,2,1,0,4,5,6,7,3,POSITIVE);

void setup() {
// put your setup code here, to run once:
lcd.begin(16, 2);
lcd.clear();
lcd.print("hello, world!");

}

void loop() {
// put your main code here, to run repeatedly:

}

Using the i2c Scanner class I found out the address of the lcd and it was 0x3F. That is why I used that!

Try the contrast knob on the I2C backpack

1 Like
LiquidCrystal_I2C lcd(0x3F,2,1,0,4,5,6,7,3,POSITIVE);

Are you sure that that is the right I2C address and I2C backpack to LCD wiring?

Have a look at the hd44780 library. It will auto detect the address and pin mapping.

Good point GF it just needs the address, # character and # lines if it’s i2c

With the hd44780 library you don't need to supply an address unless there are other I2C devices on the bus and the other device's address is lower, numerically, than the LCD address. For instance I have a MCP23008 I2C expander at address 0x20 and an LCD at 0x27, I would need to specify the LCD address in the hd44780 constructor.

There are a lot of i2c lcd libraries out there.

Instead of lcd.begin(16, 2);
try lcd.begin(1, 1);
you are displaying on last character of lcd by command lcd.begin(16, 2);

dalavila:
you are displaying on last character of lcd by command lcd.begin(16, 2);

lcd.begin(16, 2) means that the lcd is 16c x 2r. It doesn't position the cursor or print anything.

dalavila:
Instead of lcd.begin(16, 2);
try lcd.begin(1, 1);
you are displaying on last character of lcd by command lcd.begin(16, 2);

It's crackers to slip a rozzer the dropsy in snide.

Don

floresta:
It's crackers to slip a rozzer the dropsy in snide.

What?

Sounds like something Stanley Unwin would have said.

It makes about as much sense as the reply I quoted.

Don

wolframore:
Good point GF it just needs the address, # character and # lines if it’s i2c

That is isn't all that is needed. The library must know how the PCF8574 chip 8 i/o pins are wired up to the LCD and the backlight circuit.
This is because not all backpacks are made the same way. Different manufactures choose to wire the PCF8574 to the LCD and backlight control circuit in different ways.

Many of the "LiquidCrystal_I2C" libraries hard code how the pins are wired.
fm's NewLiquidCrystal LiquidCrystal_I2C i/o class allows the pin mappings to configured using the constructor.
If the configuration of the pins does not match the way the backpack is wired up, the LCD device will not work.

The hd44780 hd44780_I2Cexp i/o class will not only auto discover the i2c address, but will also auto detect the pin mappings and backlight control active level.

It offers a much simpler to use solution as the vast majority of the i2c LCD backpack based devices will "just work" out of the box.
The only issues it can stumble on are a few than have a poor backlight design or use an FET instead of normal transistor.
Either of which will not allow proper auto detection of the backlight active level.

--- bill

bperrybap:
The only issues it can stumble on are a few than have a poor backlight design or use an FET instead of normal transistor.
Either of which will not allow proper auto detection of the backlight active level.

Using a FET is of course, not in any way "poor backlight design"; it is actually excellent design. It just happens to be inconvenient for the auto-discovery. :sunglasses:


Where possible, cut the connection between the potentiometer and "Vcc". I say "where possible" as the track may use the potentiometer pin as a way-point - I have not checked this out.

Paul__B:
Using a FET is of course, not in any way "poor backlight design"; it is actually excellent design. It just happens to be inconvenient for the auto-discovery. :sunglasses:

But I never said using an FET was a poor design.

I said:

...have a poor backlight design or use an FET instead of normal transistor.
Either of which will not allow proper auto detection of the backlight active level.

i.e.
the auto detection can fail to work correctly if the backpack employs either of those design implementations not that using an FET was a poor design.

Luckily from what I've seen over the past few years, very few have a poor backlight design (used the transistor improperly), and devices that use an FET are pretty rare.

--- bill

Ans I said "It just happens to be inconvenient for the auto-discovery. :sunglasses: "

what's autodiscovery? wow you guys have fancy libraries. :grin:

And Bill has built a very fancy library.

It (though I have not actually used it yet nor examined its documentation) in its "lcd.begin(16, 2);" code interrogates the I2C bus for a port expander at one of the known addresses used by LCD backpacks and then uses the read-write capabilities of that port expander to characterise what is connected to that backpack.

Now this is tricky. :astonished:

The only two ways to determine what is connected are to attempt a read from the LCD, guessing which line is actually the R/~W, and to determine that the connection to the base of that transistor will not pull up to a logic HIGH. By trying known (and "probable"?) combinations of such pins and examining what data is returned from attempted reads from the LCD using predictable commands, a working configuration can usually be found - as long as the backpack does not have a "poor backlight design". :grinning:

wolframore:
what's autodiscovery? wow you guys have fancy libraries. :grin:

I don't use that term, at least not in the way Paul__B has used it, in reference to the pin mappings.
The hd44780 library uses the term "auto discovery" in reference to the i2c address not the pin mappings.
for the pin mappings it will use terms like "auto detection", "auto configuration", or "self configuration".
(i2c address of the device and the pin mapping configuration are distinctly separate things)

more below

If you look at my post #11, it explains that a library must know 3 things when controlling an LCD using a PCF8574 based backpack.

  • I2C address
  • how the eight PCF8574 i/o pins are wired up to the LCD and the backlight control circuit
  • the active level of the PCF8574 output pin connected to the backlight circuit needed to turn the backlight on.

If that information is incorrect, the LCD device will not work properly.
This is touched on in the hd44780 included documenation and the wiki:

The library you are using requires that all the information be configured manually through the constructor:

LiquidCrystal_I2C lcd(0x3F,2,1,0,4,5,6,7,3,POSITIVE);

While not particularly difficult to determine, get any of those wrong and it won't work.

The popular LiquidCrystal_I2C library which is available through the IDE library manager is simpler:

LiquidCrystal_I2C lcd(0x3F,16, 2);

But the reason it is simpler is the other 9 configuration parameters are hard coded.
That may or may not work with your particular backpack.

The hd44780_I2Cexp i/o class has the ability to determine the i2c address and figure the pin mappings for you.
Discovering the i2c address is easy. (auto i2c address discovery)
The library simply looks through the i2c addresses of the 16 known PCF8574 address until it finds one. It is a little more complicated than that as more than one lcd can be used.

The real magic and tough part is figuring out the other 9 parameters. (auto configuration or self configuration)

The probing is actually more involved and even more tricky than what Paul__B has outlined.
There are actually 2 parts to the auto configuration

  • determining the pin mappings between the PCF8574 and the LCD and the backlight circuit
  • determining the backlight circuit pin active level needed to turn on the backlight

While the actual final code itself to do this is pretty small and not very complicated,
determining the pin mappings is actually pretty complicated, it involves knowing intimate details of how the PCF8574 i/o pins work along with the LCD pins (data and control pins) and how they work & behave when driven and/or read.
It is more than just playing with the r/w pin.

Determining the active level is actually strait forward once you take into consideration how the PCF8574 i/o pin works and how it interacts with the waste leakage current through the transistor.
But depending on the backlight circuit design is not possible to detect the backlight active level 100% of the time because there are a few different designs that all look / behave the same way but use different active levels.
There are two cases (they are separate and different) where the active level will be incorrectly determined:

  • A poor/bad backlight circuit design
    There are some bakpacks that have improperly wired up the transistor. It "works" but not really..... as it isn't properly using the transistor.
  • an FET is used.
    There are few backpack that use an FET. While this is actually a better design than using a transistor, it is not possible to detect and/or differentiate this from the transistor design that requires a different active level.

In either of these cases of backpack design, the auto detection logic will get the active level backwards.
The library is still able to talk to the LCD, as pin mapping are still likely to have been determined correctly.
It is just that the backlight is in the wrong state so the backlight will off by default and will turn on only when commanded to turn off.
This can make the LCD appear to be dead if it is an LCD that has white text on a dark background.


The auto configuration code is the result of me believing for a couple of years that it could be done, then finally sitting down and carefully analyzing things for a few weeks and testing on many different backpack designs to get it all working reliably.

--- bill

People seem to get into the weeds here...

I have a simple (easy to buy) 2x16 I2C LCD display (I actually have 2 because I thought the first one might have been defective). I want to display some text on it. I have tried multiple examples from multiple sources and none of them display anything (some don't even compile) - though the backlight does come on/off. Can someone point me to an Arduino example for a 2x16 I2C LCD display that will display something?

esilky:
People seem to get into the weeds here...

I have a simple (easy to buy) 2x16 I2C LCD display (I actually have 2 because I thought the first one might have been defective). I want to display some text on it. I have tried multiple examples from multiple sources and none of them display anything (some don't even compile) - though the backlight does come on/off. Can someone point me to an Arduino example for a 2x16 I2C LCD display that will display something?

Go back and read the thread. Multiple people have already done that.
See responses #2, #4, and #11.
And for details behind why they are all recommending the same thing, see response #17 which goes into more details than response #16.

--- bill