There are few LCD I2C libraries around.
For whatever reason, they all have same name LiquidCrystal_I2C so it is hard to judge which one to use.
They all follow Hitachi protocol for multi-line character display.
Looking at Github I see one build in 2009 with some minor issues.
Please advise which to use, preferably include your experience with it.
Thank you for your help
Found this, looks current and will work for me.
https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home
LiquidCrystal_I2C is a library. Not sure what you mean 'they' all have the same name. There's only one LiquidCrystal_I2C.
The link you linked at the end is for an LCD that doesn't have I2C. So it's completely different than what you start off talking about.
So you should start at the very beginning, and tell us what LCD you are trying to use. If you are clueless, then a picture of the back would help.
Found this, looks current and will work for me.
https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home
Good choice. It can be used for parallel connected lcd's as well as i2c.
Make sure that all other liquid crystal libraries are deleted or sequestered in a folder not in any library path used by the ide.
There's only one LiquidCrystal_I2C.
But the PO has found my favorite lcd library. Scroll down to the download section and there you will find the following link to the most current library: https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads
Before installing this new lcd i2c lib make sure you deletd the old one in your library section.
rpt007:
- which is not correct.
Can you elaborate? Or are you and the OP talking about compound libraries that use THE LiquidCrystal_I2C among others?
Can you elaborate?
The OP mentioned that there are many libraries available for the I2C adapters that mount on LCDs. That is true.
He also said that many of them are called LiquidCrystal_I2C which I don't believe is correct.
I do believe that many of them are called LCD_I2C and I think that this is where the confusion is coming from.
Currently, but only for a little while longer, the fmalpartida library appears to be the best choice. Keep your eyes out for a new improved library coming from another contributor to this forum.
Don
floresta:
He also said that many of them are called LiquidCrystal_I2C which I don't believe is correct.Don
2 libraries of same name here by Mario_H in different versions (linked to by arduino.cc)
1 here by fdebrabander based on another one by DFRobot, which the IDE Library manager links to
1 here which is by DFROBOT
1 here by Marco Schwartz which is not identical to the DFRobot one...
1 here by Francisco Malpartida which was renamed but still contains LiquidCrystal_I2C.h
I would say many is a fair assessment. All found with a simple Google search 
I had the same problem some time back... too many to choose. Plumped for Francisco's in the end.
Thank you for your clarification; had no time until now to elaborate my statement in #3, so you were quicker. You deserve a karma point
"Before installing this new lcd i2c lib make sure you deletd the old one in your library section. "
This is strictly not necessary, the compiler will use only the first #include header it finds and will also identify the unused one(s).
Of course it helps to make sure it is the one you really want to use.
Thai is what using verbose during compilation comes into play.
I usually add pragma message to the header of interest, just to make sure.
julyjim:
"Before installing this new lcd i2c lib make sure you deletd the old one in your library section. "This is strictly not necessary, the compiler will use only the first #include header it finds and will also identify the unused one(s).
Of course it helps to make sure it is the one you really want to use.
Thai is what using verbose during compilation comes into play.
I usually add pragma message to the header of interest, just to make sure.
I don't believe you have a full understanding of how the IDE selects which libraries to use and the issues involved with the way it does its builds, particularly with the way the IDE uses the compiler include path to locate the header files for Arduino libraries the IDE believes are being used.
There can be be major issues where there are header file name collisions between multiple libraries.
The newer IDEs have some additional internal rules to try to help solve this, but there are still issues due to the way the IDE does its builds that can never be solved.
Most of this is because Arduino does not use real libraries but what Arduino calls "libraries" is really a collection of directories containing source code that it calls "libraries".
Depending on where/how newLiquidCrystal is installed, the name of the directory it is installed in, and what other libraries are installed and their names and locations, there can be header file conflicts with other libraries that creates a situation where you can no longer build sketches for that library.
This is not unique to newLiquidCrystal but it is a definite issued for newLiquidCrystal.
For example, say a header file named "A.h" exists in both Arduino library X and library Y.
You can end up with a situation where part of the code (the sketch) uses header A.h from library X and part of the code (the library) uses header A.y from library Y.
This can create compilation errors, or link errors.
Either of which results in not being able to build a sketch image.
--- bill
And that's why it is always a good idea to organize yourself and not expect others (in this case the IDE) decide for the right things. You will never be sure if you don't clean the house ...
It was not my intent to discuss IDE ways to use headers.
Here is an compiler output which suggest that these "libraries" were not useful perhaps not used would be better message.
But since it was mentioned - the "library" is indeed identified by its directory name.
what is directly being said - you cannot have same named file in DIFFERENT directory.
Since when? Would that defeat the purpose of files hierarchy in directories?
Sorry for getting OT.
Sketch uses 22,076 bytes (4%) of program storage space. Maximum is 524,288 bytes.
Atmel SMART device 0x285e0a60 found
Erase flash
done in 0.041 seconds
Write 24344 bytes to flash (96 pages)
[ ] 0% (0/96 pages)
[== ] 9% (9/96 pages)
[===== ] 18% (18/96 pages)
[======== ] 28% (27/96 pages)
[=========== ] 37% (36/96 pages)
[============== ] 46% (45/96 pages)
[================ ] 56% (54/96 pages)
[=================== ] 65% (63/96 pages)
[====================== ] 75% (72/96 pages)
[========================= ] 84% (81/96 pages)
[============================ ] 93% (90/96 pages)
[==============================] 100% (96/96 pages)
done in 4.715 seconds
Verify 24344 bytes of flash
[ ] 0% (0/96 pages)
[== ] 9% (9/96 pages)
[===== ] 18% (18/96 pages)
[======== ] 28% (27/96 pages)
[=========== ] 37% (36/96 pages)
[============== ] 46% (45/96 pages)
[================ ] 56% (54/96 pages)
[=================== ] 65% (63/96 pages)
[====================== ] 75% (72/96 pages)
[========================= ] 84% (81/96 pages)
[============================ ] 93% (90/96 pages)
[==============================] 100% (96/96 pages)
Verify successful
done in 4.723 seconds
Set boot flash true
CPU reset.
Invalid library found in /home/jim/Downloads/Arduino/build/linux/work/libraries/NewliquidCrystal_1.3.4: /home/jim/Downloads/Arduino/build/linux/work/libraries/NewliquidCrystal_1.3.4
Invalid library found in /home/jim/Downloads/Arduino/build/linux/work/libraries/NewLCD_Repository: /home/jim/Downloads/Arduino/build/linux/work/libraries/NewLCD_Repository
Invalid library found in /home/jim/Downloads/Arduino/build/linux/work/libraries/NewliquidCrystal_1.3.4: /home/jim/Downloads/Arduino/build/linux/work/libraries/NewliquidCrystal_1.3.4
Invalid library found in /home/jim/Downloads/Arduino/build/linux/work/libraries/NewLCD_Repository: /home/jim/Downloads/Arduino/build/linux/work/libraries/NewLCD_Repository
julyjim:
It was not my intent to discuss IDE ways to use headers.
But how the IDE works, users header file names, and locates the Arduino library directories, directly relates to getting newLiquidCrystal library package up and working correctly.
Here is an compiler output which suggest that these "libraries" were not useful perhaps not used would be better message.
But since it was mentioned - the "library" is indeed identified by its directory name.
I don't see any compiler output in that post.
There is a tiny bit of IDE output near the bottom complaining about invalid libraries.
The message about an invalid library is not a message about an unused libary.
That would look more like this:
Multiple libraries were found for "LiquidCrystal.h"
Used: /home/bill/Documents/devel/arduino/arduino-1.6.11/libraries/LiquidCrystal
The IDE does not like something in those directories or their names.
Not sure what OS you are on or what IDE you are using but there are many issues related to naming due to needless naming restrictions enforced by the IDE and it varies by IDE version.
The IDE identifies a "library" being used or directory where the source code for the library "lives" by the name of the header file being included. It searches for the header file name in all the "libraries" directories in all the library locations (there are multiple) to see if it can locate the header file being included.
There is no requirement that <foo.h> live in a directory named foo
what is directly being said - you cannot have same named file in DIFFERENT directory.
Since when? Would that defeat the purpose of files hierarchy in directories?
You are not understanding what was said or the issue.
It isn't that you can't have a header file with the same name in different Arduino "library" directories, it just that if you do, there will likely be issues because of the way IDE does its builds.
The IDE uses the header file name being included to locate the directory where the Arduino "library" lives.
If there is more than one directory with the same header file name, there is no guarantee that the IDE will pick the one you want. (The older IDEs simply use the first one they see) There are rules that the IDE uses to try to help minimize the issue (which also have changed through time in various IDE releases), but depending on the location of where the library is installed, the directory named used, and how many header file name conflicts there are (there can be multiple) or the IDE version you are using, you can have a situation where the sketch cannot be built and linked.
In the case of multiple collisions you can have a situation where the IDE correctly identified the correct libraries and their directories but because of the way it uses the include path to tell the compiler where to look for header files, the compiler can end up picking the header file from the wrong Arduino library.
This is a side effect of using the include path to locate the header files. There is no way to resolve this.
(In nearly 40 years of s/w development, I've never seen any other build system that does things this way)
The newLiquidCrystal library definitely has conflicts with other libraries, including the IDE bundled LiquidCrystal library and that is why it has a very explicit way of being installed.
If you don't follow its recommendations for installation, there is likely to be issues.
--- bill
[/code][/code]
Thanks for all this, it really helps to identify right source code for LCD I2C..
Basically it goes back to the beginning when I questioned why the headers from different authors / source use SAME names.
Since the source code does not identify the "library , and standard C/C++ cannot , the first match , using the IDE "libraries" lookup sequence, is used.
Problem solved.
Thanks
BTW using Due on Ubuntu 16.04 and IDE 1,6.11 build from Github source. Works as expected, so far.
I think you may have to change the subject field in your original post if you want the 'SOLVED' to show up in the list of forum threads.
Don
julyjim:
Thanks for all this, it really helps to identify right source code for LCD I2C..
Basically it goes back to the beginning when I questioned why the headers from different authors / source use SAME names.
Since the source code does not identify the "library , and standard C/C++ cannot , the first match , using the IDE "libraries" lookup sequence, is used.
But it isn't that simple. It isn't necessarily the "first match", it is much more complex/subtle than that, particularly on the newer IDEs.
This is because the newer IDE keeps looking after it finds a match. It then has a built in priority mechanism to determine which one to use, should it discover multiple.
However, if there are certain types of collisions, there is no guarantee that code will be compiled using the header from the directory that the IDE selected for that header.
For example. If sketch uses foo.h and bar.h and foo.h exists in directories foo and bar and bar.h only exists in bar
And also assuming a newer IDE with the additional selection rules.
Here is how this may or may not allow a sketch to build:
The IDE will see foo.h in both bar and foo (it will see the one in bar first as it is alphabetically first) but will choose to use the "foo" library as its name matches the basename of the foo.h header file.
So the IDE will add foo to the include path.
It then looks for bar.h and finds it in bar to it adds bar to the include path.
The IDE will tell the compiler look in foo then bar for headers.
The compiler will grab foo.h from foo and bar.h from bar and everything is ok.
No consider what happens if
The IDE will see bar.h in bar and add bar to the include path.
The IDE will see foo in bar and foo but will choose foo and add foo to the include path.
The IDE will tell the compiler look in bar then foo for headers.
The compiler will grab bar.h from bar but will grab foo.h from bar (the compile fails since it is the wrong foo.h)
And this is the problem with the way the IDE works. There is no way for the IDE to always pick the correct library and have the compiler use the correct header file when there are header file name collisions.
The IDE uses a poor "library" and build mechanism.
--- bill
There really should be a generic library in the Arduino Libraries for this for the garden varieties (please).
The issue is catering for the variants.
The current optimum library is the HD44780 library accessed by installing via the Library Manager in the IDE itself, which has no name conflicts and when installed provides ample examples.
You may consider all the older libraries superseded.
At one time the Roach Motel brand of cockroach bait boasted that "Roaches check in, but they don't check out". Similarly a movie about Las Vegas spawned the catch phrase "What happens in Vegas, stays in Vegas".
The Arduino site operates pretty much in the same way. In the nearly three years since this thread was active there have been significant improvements in the LCD libraries and in many others as well I assume. Unfortunately the old libraries that were improved upon still remain around.
Although it may not be easy to get a new library 'approved' by the keepers of the Arduino it is even harder, nearly impossible it seems, to get rid of the older and frequently obsolete material. Material that appears on the Arduino website stays on the Arduino website.
So, even though the older libraries should indeed be considered superseded, you can be assured that they will be around for a while causing confusion and giving us old geezers something to write about.
Don
As far as I am concerned, there is only one library for character LCDs with the hd44780 controller. That is the hd4780 library mentioned above. it makes using I2C enabled (with I2C expander) LCDs as close to plug and pay as possible with auto detect of I2C address and backpack to LCD pin mapping. The library also works with 4 and 8 bit parallel LCDs and some other interfaces.