Tons of compiler warnings with NewLiquidCrystal library

Hello,

I hope this is the place to post this.

I get tons of compiler warnings when I use the NewLiquidCrystal library. I am sure most of them is my fault (wrong declaration etc), everything works, but it is very annoying.

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

I would appreciate anyone pointing out my mistakes. The display is a very common 16x2 Chinese unit with equally common I2C adapter on it. I will attach the warnings as a txt file, but it is a bit of a read...

Thanks!

warnings.txt (17.7 KB)

My advice is to simply ignore them. None of these have anything to do with anything you did, unless you've been modifying the library code. None of these should actually cause any problems. It's very annoying when library authors are sloppy and write code that produces a ton of warnings because they make it difficult for those of us who strive to write warning-free code to find the warnings in our own code buried in the massive mess of warnings the libraries dump into the console. Well, it's free open source software so we can't complain too much.

It's a good idea to always pay attention to warnings and always fix the warnings produced by your own code, but you also need to be aware that not all warnings represent a real problem. They are just the compiler telling you "hey, this doesn't seem right, you might want to take a look at this".

What are all these parameters?

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

Since your code is working, I guess they're needed, but for I2C LCDs, I'm more used to seeing something like

LiquidCrystal_I2C lcd(0x3F, 16, 2);

Yep, thank you for your comment. I know that these warnings are coming from the library and they are not serious. Yet still, despite my poor knowledge, I can manage to write moderate level code that passes the compiler without any warnings and it is very annoying to see tons of warnings that are all generating from the library code. I thought at least some of these must be because of my LCD declaration having some missing/wrong parameters. I would still appreciate somebody taking time to read them and guide me to correct things I may be doing wrong. As far as I know, this is a very common library that is written to cover quite an extensive range of character LCD displays and their protocols. This just can't be happening to everyone who uses this library, very very annoying...

wildbill:
What are all these parameters?

Maybe you can figure them out. This code is from the library:

/*!
    @method     
    @abstract   Class constructor. 
    @discussion Initializes class variables and defines the I2C address of the
    LCD. The constructor does not initialize the LCD.

    @param      lcd_Addr[in] I2C address of the IO expansion module. For I2CLCDextraIO,
    the address can be configured using the on board jumpers.
    @param      En[in] LCD En (Enable) pin connected to the IO extender module
    @param      Rw[in] LCD Rw (Read/write) pin connected to the IO extender module
    @param      Rs[in] LCD Rs (Reset) pin connected to the IO extender module
    @param      d4[in] LCD data 0 pin map on IO extender module
    @param      d5[in] LCD data 1 pin map on IO extender module
    @param      d6[in] LCD data 2 pin map on IO extender module
    @param      d7[in] LCD data 3 pin map on IO extender module
    */
   LiquidCrystal_I2C(uint8_t lcd_Addr, uint8_t En, uint8_t Rw, uint8_t Rs, 
                     uint8_t d4, uint8_t d5, uint8_t d6, uint8_t d7 );
   // Constructor with backlight control
   LiquidCrystal_I2C(uint8_t lcd_Addr, uint8_t En, uint8_t Rw, uint8_t Rs, 
                     uint8_t d4, uint8_t d5, uint8_t d6, uint8_t d7,
                     uint8_t backlighPin, t_backlighPol pol);

BoraY:
Yet still, despite my poor knowledge, I can manage to write moderate level code that passes the compiler without any warnings and it is very annoying to see tons of warnings that are all generating from the library code.

I agree. It's a huge pet peeve of mine. I think it is often caused by the library author not having warnings turned on. The Arduino IDE actually promotes that because its default setting is to have them off. It's sad because warnings can be so incredibly useful to a developer. So many times I have had a warning tip me off to a problem in my code that would have taken a long time to find otherwise.

BoraY:
I thought at least some of these must be because of my LCD declaration having some missing/wrong parameters.

Nope.

BoraY:
I would still appreciate somebody taking time to read them and guide me to correct things I may be doing wrong.

They are all quite self-explanatory. As I said already, none of them are caused by anything you are doing wrong. This is the reason why the Arduino developers have warnings turned off by default. They tend to completely freak out beginners who can't understand the difference between a warning and an error.

BoraY:
As far as I know, this is a very common library that is written to cover quite an extensive range of character LCD displays and their protocols. This just can't be happening to everyone who uses this library, very very annoying...

Note that there are quite a few different libraries that contain a file named LiquidCrystal_I2C.h. Some of them have a different API than others, which could explain why you see some code for libraries of this name with a different style of constructor. You might find that the library you happened to grab is outdated or written by a developer who doesn't know what they are doing, whereas another version is very high quality and has no warnings. I know that many people recommend a completely different library for the I2C displays:

It does have a somewhat different API, and is a bit more complex, but you shouldn't have too much trouble adapting your code to it after studying the examples. Although I have used several, I can't give a good comparison between the various libraries for the I2C LCDs because I haven't spend any time checking which was best, since I've only used the LCDs in a couple of projects of friends where I was only giving them a little help.

If you really are bothered by these warnings, and are set on using this particular library, feel free to fix the code. The "unused parameter" warnings are fairly self explanatory. Perhaps the developer has a parameter in the function signature, but then never ended up using it in the code, or maybe they have an #ifdef sort of thing in the code that causes the parameter to only be used depending on whether a macro is defined. One solution would be to remove the unused parameter, but that will mean you have changed the signature of the function, which might cause problems if there is code that tries to pass an argument to the function. The other trick for fixing this warning, with no overhead is to cast the variable to void in the function. For example, you have this warning:

C:\Program Files (x86)\Arduino\libraries\NewLiquidCrystal/LCD.h: In function 'void waitUsec(uint16_t)':
C:\Program Files (x86)\Arduino\libraries\NewLiquidCrystal/LCD.h:101:40: warning: unused parameter 'uSec' [-Wunused-parameter] 
inline static void waitUsec ( uint16_t uSec )

So you would want to add this line to the waitUsec function:

(void)uSec;  // fix "unused parameter" warning

That will cause the compiler to think the parameter was used, but it is used in a way that does nothing and thus incurs no overhead. Since this is not obvious from reading the code, I recommend adding a comment to explain the purpose of this strange line.

Then you just need to go through and do the same for the many other "unused parameter" warnings.

After that, there is only one other warning left:

In file included from C:\Program Files (x86)\Arduino\libraries\NewLiquidCrystal\LiquidCrystal_SR1W.cpp:48:0:
C:\Program Files (x86)\Arduino\libraries\NewLiquidCrystal\LiquidCrystal_SR1W.h:168:1: warning: multi-line comment [-Wcomment]
 //             |    |      0.1uF            |     \
^

The escape character at the end of the single line comment causes the next line to also be a part of the comment. It is common for beginners to try to make their code pretty by "balancing" the single line comment like this:

// my comment is so pretty now that it breaks my code! \\
void brokenFunction() {

it ends up making a line of the code that was never intended to be a comment in to a comment.

In the case of the library, this escape character was used to intentionally create a multi-line comment using the single-line comment syntax. We have a different syntax for that though, the block comment syntax (/* */). So you could fix this warning by converting the comment to use the block comment syntax.

Thank you very much for taking the time for this very detailed answer! I believe I need to do a bit of reading on the various LiquidCrystal libraries out there and find out which one is actually written by somebody who takes care in his/her work. You gave me good pointers too and I will check the library you mention.

Best regards!

pert:
I know that many people recommend a completely different library for the I2C displays:
GitHub - duinoWitchery/hd44780: Extensible hd44780 LCD library

I tried this library in my project, and guess what? No compiler warnings at all! Works flawlessly. My compliments to duinoWitchery who wrote it!

For an I2C LCD display to work, the I2C address and the I2C backpack to LCD pin mapping must be correct. If the library default settings for either or both are not correct the LCD will not work. You can try to figure out the right pin mapping and use an I2C scanner to find the address, but if you install and use the hd44780 library that is done automatically by the library.

Install the hd44780 library. The hd44780 library is the best available for I2C LCDs. The library is available in the Library Manager. Go to Library Manager (in the IDE menus, Sketch, Include Libraries, Manage Libraries) and in the Topics dropdown choose Display and in the Filter your search box enter hd44780. Select and install the hd44780 library by Bill Perry.

The class that you want to use is the hd44780_I2Cexp class. There are examples to show how to use the library. The nice thing about the hd44780 library is that it will autodetect the I2C address and the I2C backpack to LCD pin mapping.

In the examples, there is a diagnostic sketch that will help us to help you if you still have trouble with the display. Run the diagnostic sketch and post the results.

pert:
I know that many people recommend a completely different library for the I2C displays:
GitHub - duinoWitchery/hd44780: Extensible hd44780 LCD library

Just to repeat and emphasise groundFungus' explanation.

You do not need to refer to that github page for Bill Perry's HD44780 library, not that there is anything whatsoever wrong with the github. :grinning:

It is available and installs correctly from the IDE Library Manager.

pert:
I know that many people recommend a completely different library for the I2C displays:
GitHub - duinoWitchery/hd44780: Extensible hd44780 LCD library
It does have a somewhat different API, and is a bit more complex, but you shouldn't have too much trouble adapting your code to it after studying the examples. Although I have used several, I can't give a good comparison between the various libraries for the I2C LCDs because I haven't spend any time checking which was best, since I've only used the LCDs in a couple of projects of friends where I was only giving them a little help.

I am very familiar with pretty much all the Arduino libraries that support i2c LCD backpacks.
Most of them support the same API functions as the IDE provided LIquidCrystal library.
And the LiquidCrystal API is similar to the LCD API 1.0 spec which was written quite some time ago before the LiquidCrystal API had gained popularity.

The hd44780 library supports both the LiquidCrystal API as well as the applicable LCD API 1.0 spec for text based LCD.

Having worked with several of the authors of these types of libraries, including fm's NewLiquidCrystal, Marco's LiquidCrystal_I2C, mathertel's LiquidCrystal_pcf8574, and several others,
I would recommend using the hd44780 library if you want an easy to install library that can offer an easy to install "plug and play" solution. The library auto locates the i2c address, and autconfigures the pin mappings and backlight control.
No other i2c LCD library offers this capability. The hd44780 library is also faster than the others and includes some enhancements that are not available in other libraries, like long line wrapping, and the ability to read data from the display screen.
It also comes with diagnostic sketch, I2CexpDiag, for i2c LCD backpacks, to test the i2c connections and LCD memory to verify that the library is working properly.
There is also extensive documentation - available in a Documentation sketch, along with lots of examples.

For some other background:

As mentioned there are many different libraries that all offer a LiquidCrystal_I2C class.
To make matters worse, one is available in the IDE library manager, and several of the others have been copied and archived off in various places so many of them are the same but simply different or even out dated versions.
And they all are often called "LiquidCrystal_I2C".

I worked with fm for a while when the NewLiquidCrytal library was being developed. I wrote some of the code and did a few of the i/o classes for that library.
I wrote the hd44780 library to essentially be a better, easier to install, easier to use version of NewLiquidCrystal.

Here is some additional information about some of the more popular ones.

  • LiquidCrystal_I2C library
    Not be confused with the newLiquidCrystal library which also includes a LIquidCrystal_I2C class.
    The LiquidCrytal_I2C library is a single class library that is available in the IDE library manager.
    It supports the LiquidCrystal API but depending on which version you have it does not support the begin() function.
    It doesn't have a dedicated author that is capable of maintaining the code. As such the github repo is not tagged correctly so the IDE is confused and will not install the most recent release of the code which does fix a few issues.
    The real concern for me with this library is that the pin mappings between the pcf8574 and the LCD are hard coded.
    This is great if you have the backpack with this pin mappings as you get smaller code, but if you don't have that backpack, it won't work until the code is modified, and if you have more than one backpack with different pin mappings you are out of luck.

  • newLiquidCrystal
    fm's newLiquidCrytal library has several i/o classes where each i/o class is for communicating with the h/w that drives the LCD.
    This allows a common API no matter what h/w is used to drive the actual LCD.
    The LiquidCrystal_I2C i/o class allows the sketch to define the pin mappings between the pcf8574 and the LCD.
    While this allows the library to talk to any i2c backpack, many users struggle getting the proper pin mapping parameters.
    If they are incorrect, it won't work.
    Because of the way the library was designed to work, as a replacement for the LiquidCrystal library, it can never be added to the IDE library manager, which means it must always be installed manually.
    Many users struggle getting it installed properly.
    It can often "work" when installed improperly, but can have issues in the future when updates to the IDE or other "LiquidCrystal" libraries are done.

note: LiquidCrystal_I2C and newLiquidCrystal should not be both installed.
It can confuse the IDE and cause weird compilation and/or linking issues depending on how & where they were installed.

  • LiquidCrystal_pcf8574
    This library is very similar to the LiquidCrystal_I2C but is missing a few of the LiquidCrytal API functions.
    I would not recommend this library as the author has attempted to change the licensing from LGPL to BSD, which really isn't allowed. Also even if a library is BSD licensed, the overall sketch must still be licensed as the most restrictive license which is typically either LGPL 2.1+ or GPL 3.0, so having an individual BSD library offers no benefit.

Paul__B:
You do not need to refer to that github page for Bill Perry's HD44780 library, not that there is anything whatsoever wrong with the github. :grinning:

There is some useful installation instructions on the github page that can be useful for those that are unfamiliar with how to install libraries along with other information such as the API summary and where to find the examples once the library is installed.

--- bill

BoraY:
I tried this library in my project, and guess what? No compiler warnings at all! Works flawlessly. My compliments to duinoWitchery who wrote it!

Yay! That is what I like to see.
That was my intent. To provide an easy to install, as close as possible to a "It just works" solution.

--- bill

bperrybap:
Yay! That is what I like to see.
That was my intent. To provide an easy to install, as close as possible to a "It just works" solution.

--- bill

Thank you very much for your very detailed info, much appreciated!

Now that I have the hd44780 library installed and working flawlessly, I would like to delete all other libraries regarding driving these character LCD's. I like to keep the IDE as clean as possible of the unused or trouble making libraries in order to avoid confusions for the compiler. Can I delete everything about the old LiquidCrystal libraries or is there any dependencies for them in the hd44780 code?

BoraY:
Can I delete everything about the old LiquidCrystal libraries or is there any dependencies for them in the hd44780 code?

The hd44780 does not use or depend on any other LCD library, so you can remove any of the other LCD libraries you want.
While the hd44780 library includes an i/o class, hd44780_pinIO, that can be used instead of the IDE bundled LiquidCrystal library,
there is no need to actually remove the LiquidCrystal library.

--- bill

bperrybap:
The hd44780 does not use or depend on any other LCD library, so you can remove any of the other LCD libraries you want.

Thanks again!