How to fix all LCD problems - read this!

Other Hardware Displays
21

It is very unfortunate the the LiquidCrystal library use the term "scroll" instead of "shift" in the api.

What they did when they implemented the begin() function is even more unfortunate. If you forget to include that function, or if you use a sketch written for an older version of LiquidCrystal that didn't have such a function, the implementation is for a 'one line' display.

The problem is that there are almost no true one line displays around. Even most displays that have one row of sixteen characters and look like a 16x1 are internally set up as 8x2. This means that the default configuration will work correctly with only some very rare displays while the commonly used ones will have poor contrast on the first row and no display on the other(s).

So, in my opinion, the default should be 16x2 since that setup will work correctly for almost all displays. With 16x2 as default only the true 16x1s will be messed up and the 16x4s will look ok but they will have their third and fourth rows offset by 4 spaces - but the 16x4s do that anyway with the current library even if you invoke them as 16x4 in begin().

Don

22

floresta:
Anyone who cannot inherently figure out where the funny characters come from when using lcd.println() probably doesn't know or care about classes and the fact that the print class is how things actually get displayed on the LCD.

It may be true that println() can be made to work as expected with other LCD libraries but the fact remains that at the present time it is not implemented in the LiquidCrystal library. Therefore it's use in a sketch that incorporates the LiquidCrystal library is incorrect.

Don

I totally agree with the first part of this and about avoiding using println() when using
the LiquidCrystal library shipped with the IDE.

All I've been saying is that neither print() nor println() is implemented in the LiquidCrystal library
(print() and println() both exist and are both implemented in Print not LiquidCrystal)
and any issues in their support with respect to newline handling is in LiquidCrystal and not elsewhere.
This isn't just a println() issue. It goes beyond that. The LiquidCrystal library that
ships with the IDE does not have newline support.
This means that newlines in strings also won't work
even if print() is used which IS part of the documented API for LiquidCrystal.

While println() is not in the list of documented LiquidCrystal API functions
saying there is no println() or that println() is not implemented is factually incorrect.
It would more appropriate to say it isn't supported.

So I believe that with respect to this thread, the SW note to users should say something like
The current LiquidCrystal library that ships with the IDE
does not have newline support so println() should not be used and newlines should not
be used in strings sent to print().

This covers both attempting to use println() and newlines in strings to print().

---bill

23

saying there is no println() or that println() is not implemented is factually incorrect.

I don't think I ever said that or at least I never meant to say that. I keep on emphasizing that it is **lcd.**println() that is not supported. Take another look at reply #17.

I think we finally agree.

Don

24

floresta:

saying there is no println() or that println() is not implemented is factually incorrect.

I don't think I ever said that or at least I never meant to say that. I keep on emphasizing that it is **lcd.**println() that is not supported. Take another look at reply #17.

I think we finally agree.

Don

I think we may have mostly always agreed.

I believe that you probably always meant "not supported" but you kept typing
"there is no" or "not implemented" even in responses #17 and #19.
The words "not supported" is never mentioned in any of your posts (other than #22)
but I kept using those words over and over again.
So it kept jumping out at me.

It is the specific language that was (and still a little bit) bothering me.
There were some factual inaccuracies in references to "implemented", "supported", "exist",
that were bothering me.

In post #1:

S-2) Tried to use lcd.println. There is no such function so you will see two strange characters with your text

To which my original response in # 14 was:

S-2 is already there, but I'd change the language from:
"There is no such function" which is incorrect to
"It is not supported by most of the lcd libraries including the LiquidCrystal library that ships with the IDE".

but then in #17

floresta:
I still maintain that there is no **lcd.**println() function.

But there is a lcd.println() function. While there is no println() in the current LiquidCrystal API documentation
on the Arduino web site, which implies that it isnt' supported, it still does exist.
Currently if a person does call it, it does not work as would be expected.

And then in #19:

floresta:
It may be true that println() can be made to work as expected with other LCD libraries but the fact remains that at the present time it is not implemented in the LiquidCrystal library. Therefore it's use in a sketch that incorporates the LiquidCrystal library is incorrect.[/color]

This is where things get a bit tricky since technically neither print() nor println() are implemented
in LiquidCrystal since they are both implemented in Print.
But it is "implemented" since Print is inherited by LiquidCrystal.
I assume you really meant "not supported" rather than "implemented".

Things seemed to have gone south after my response in #14, not sure why.
It seemed quite simple to modify the language of "There is no such function" to "It is not supported".
Maybe it was latter part of that #14 post that referenced scrolling. I mentioned that because it
came up in another thread, where the user was using println() and was expecting that
the output would wrap and would scroll up and ended up getting 2 funky characters instead.

In #21 What I was trying to say was the print() and println() always do exist and are implemented
but they are both implemented in Print which LiquidCrystal uses so both will exist in LiquidCrystal
and that since the current LiquidCrystal code shipping with the IDE does not handle newlines,
not only is println() not supported but any use of newlines embedded in strings sent to print() will
not work either.

So it is beyond println() not working with LiquidCrystal, it is any use of newlines
that won't work with the LiquidCrystal that currently ships with the IDE.
This includes both println() and newlines embedded in strings sent to print().

--- bill

25

@liudr: Please add more whitespace...

  1. Instead of having numbered lists
  2. Close together like this which
  3. Can be difficult to read

...

  1. Add a blank line after each item

  2. To make it easier to read and

  3. Easier to find your place as your

  4. Focus moves from the screen to

  5. Your Arduino

26

We need another entry between 3 and 4. I'm not sure how to phrase this but here is a start:

When your LCD does not display the information that you think it should be displaying then tell us (a) what you were trying to display, (b) what actually was displayed, and (c) if the same incorrect information shows up in the same place every time or if the incorrect information is different each time.

Don

27

I have another addition:

If you take the time to put your location information into your profile you may have a better chance of getting appropriate replies.

Don

28

liuzengqiang:
H-8) Didn't deal with R/W (LCD pin 5) correctly. You should tie this pin to GND.

Hello, could you please explain this more. I'm pretty sure this is my problem, but I don't quite understand, "tie this pin to GND" how actually do you do that?

Thanks

29

Back in the Arduino stone age (when this thread originated) the Liquid Crystal library documentation, and specifically the 'Hello World' example, did not emphasize that LCD pin 5 must be connected to the GND pin. This connection was shown in the schematic diagram but was not called out in the list of pin connections.

So, to answer your question, when you make the various connections between the LCD module and the Arduino you have to be sure to include this particular wire.

If you are using an I2C interface (which were essentially unknown back then) this connection along with all of the others is already made for you.

Don

30

Thanks for your classification. However, I was able to figure it out using a 2x16 LCD Shield diagram, referring it back to my project's schematics.