A useless discussion about how a working sketch can't possibly work

adwsystems: Please feel free to explain how it works.

Challenge Accepted....

Ok, while I'm not fm, I did collaborate and write several sections of that library and a few of the i/o classes. And helped support it for a few years. I'm the closest thing you will get to fm. Here is the deal. fm has a company called ElectroFun that made a product called LCDXIO. Here is a post about it: https://forum.arduino.cc/index.php?topic=467057.msg3201666#msg3201666 I have one - that fm sent me, but it isn't made anymore. Here is a page from the wayback machine so you can see it: https://web.archive.org/web/20120119082309/http://www.electrofunltd.com:80/p/i2c-lcd-extra-io.html It was kind of a funky product in that it was kind of a backpack and could be used that way, but the PCB didn't work that well when used as a backpack do to the offset of the holes. I'm the one that added backlight control to the LiquidCrystal_I2C class as the early code didn't have it since LCDXIO didn't support it.

When a full constructor is not specified, as in only specifying the i2c address, the library uses a default set of parameters, for the pin mappings. The default pin mapping used by the newLiquidCrystal LiquidCrystal_I2C class uses a pin mapping for that LCDXIO device.

I have tried to find and test as many different types of i2c lcd backapacks as I can find over the years and I have never seen any other PCF8574 based lcd backpack use this pin mapping in the several years (6+) that I've been playing with and writing code for i2c lcd backpacks.

I also spent some time going through the git history of fm's bitbucket repository to see if the default pin mapping has ever been changed. I didn't see any version of code that used a different default pin mapping than what is being used in the latest version of the LiquidCrystal_I2C code. The latest LiquidCrystal_I2C code was updated 2016-11-25 The earliest LiquidCrystal_I2C code was from 2011-10-25 While the location of the default pin mappings has changed around a bit over the years from the .h to the .cpp and the original code didn't even allow changing the pin mappings of the data lines from D4=0, D5=1, D6=2, D7=3, I did not see any case of the default pin mappings being anything other than EN=6, RW=5, RS=4, D4=0, D5=1, D6=2, D7=3

So I don't see how you could have ever used a newLiquidCrystal library obtained from fm's bitbucket repo and used the default pin mappings and had it work, since you said you needed this constructor to make it work: LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);

If you actually have the older library code that you were using, you should be able to instantly tell what changed between what used to work and what you have now. Just run a diff or use meld so you can see the differences it will be obvious. If you cloned the git repository of the working "older" library to your system you could also use git to show you if there were any local modifications to the files.

My guess is that if the library code you were previously using worked with a constructor that was only provided an i2c address, it either didn't come from fm's newLiquidCrystal repo or was modified to use a different default pin mapping as I cannot find any evidence that the default pin mappings in the library code from fm's repository ever used the pin mappings that you have said are required for your device.


Given you seem to be using this code on a commercial product there are some things that you need to be aware of. When using newLiquidCrystal, you need to be aware that it has licensing issues and copyright violations and legally cannot be used in any type of commercial product.

fm is aware of this (and now you are too). fm has promised to address it for quite some time, but so far has not. I can send you full details on this but here are the highlights: - The overall license fm picked is CC-BY-SA 3.0 That license is not compatible with anything but itself. It cannot legally be linked with any GPL or LGPL code. It is not an appropriate license for s/w and was really intended for things like documents or other components that are not integrated into something larger. - The overall license for newLiquidCrystal cannot be CC-BY-SA 3.0 The original code that the newLiqiudCrystal library started with was licensed as LGPL 2.0+ as such, it cannot ever be relicensed with anything but a LGPL or GPL license. To do so, as was done in this case, is a copyright violation. - The library ships with some GPL 3 components. GPL v3 is not compatible with CC-BY-SA and as such it violates both CC-BY-SA and GPL.

  • Some of the modules have had their licensing agreements changed from their original GPL licenses to other licenses which is a violation of the licensing terms.

The only resolution is to relicense the newLiquidCrystal library code as either LGPL 2.0+ or as GPL v3. If the code is relicensed as LGPL 2.0+ then some of the modules must be removed as they are LGPL 3.0 and you can't relicense them LGPL. Regardless of the licensing correction, the various authors have to agree. fm decided to move to GPL v3 and I agreed, but so far fm has not contacted the others and has made no effort to correct the licensing and copyright issues. He did say if it becomes a big issue, he would simply remove/delete the library.

So for now that library is hopeless broken in terms of licensing/copyrights and should not be used, especially in a commercial product.

This kind of stuff is particularly important in your case as you are shipping a commercial product. I would avoid using it.

Seems like a lot of your issues could be resolved if you switched to using hd44780. Just keep in mind that hd44780 is LGPL v3 so your product code must be fully open source licensed as GPL 3.0 But even if using some other LCD library to avoid any GPL 3.0 licensing issues, if you use Arduino, you will still be bound by the LGPL 2.0 licensing requirements and with current Arduino development tools, it isn't possible to have closed source and satisfy all the LGPL 2.0 licensing requirements.

Given the way the Arduino IDE works, it is not possible to use Arduino for closed products since even LGPL 2.0 requires that a user be able to replace/update the LGPL open source components and currently there is no way to use the Arduino provided tools to build a project and upload a device and keep part of the code closed source to the customer. i.e. there is no way to keep certain parts of the product closed source and grant the customer all the rights he is entitled to when using LGPL or GPL code in an Arduino based s/w product.

--- bill

I am intrigued by Malpartida choice of default wiring.

There are two convenient ways of mounting the PCD574 on a pcb.

Most Ebay backpacks have the PCF8574 mounted vertically. Data bus is on P4..P7

The only one I can find with a horizontally mounted PCF8574 is this one The databus is probably on P0..P3 like Malpartida default.

I can't find a sale item. But backpacks marked "Arduino-IIC-LCD GY-LCD-V1" have a horizontal PCF8574 with data bus on P0..P3.

So yes, horizontal PCF exist but are not very common.

David.

David, if you look at fm's ElectroFun board (in the wayback link), it uses a SSOP20 not a SO16. The SSOP20 chip version of the PCF8574 has a very different pin layout. I have no clue why.

The two boards I've seen that use P4-P7 for DB4-DB7 are the mjkdz like you showed and the one labeled GY-I2CLCD. Both use the same pin mappings and same active level backlight control.

But even all boards that use P0-P3 for DB4 to DB7 are not all the same. While most use active high level backlight control, the one called "Robot Arduino LCM1602 backpack" uses active low backlight control. That particular backpack will also force the backlight to be always on when the jumper is installed whereas on most backpacks, removing the jumper disables the backlight control and turns off the backlight.

You can look in the hd44780 library hd44780_I2Cexp.h header file to see all the backpacks that I've encountered (and actually have tested with) and the ones the hd44780 self configure code will identify.

The one odd ball is the SYDZ board which has an incorrect backlight design. They hooked up their transistor incorrectly, so it breaks the auto detection s/w used to detect the active backlight level. It also has really nice switches for setting the I2C address but the switches are on the side of the backpack PCB that faces the LCD. So if you solder it to the LCD, you can't access the switches to alter the i2c address. For those reasons I do not recommend it,

Essential, there are 3 pin mappings and two active levels for backlight control that are being used in commercial products. I can't really speak as to the actual popularity of any of them other than the pin mapping used on the LCDXIO board is not used on any other backpack that I have so far seen.

--- bill

Given from what I can see in fm's bitbucket repository commit history for newLiquidCrystal, the default pin mapping used in the LiquidCrystal_I2C class has never changed.

Also, no changes or updates to the IDE would alter this.

The only way a newLiquidCrystal library from fm's bitbucket site could work with the stated backpack, is if it had been modified.

So my conclusion is that the code that previously worked with the stated h/w had been modified. It either cam from a different source that fm's bitbucket site (where it had been modified), or it was modified locally. And then when the library was updated, these modifications to the default pin mappings were lost.

--- bill

My final thoughts are though I had fmalpartida's library installed, it was only being used in part (or possibly not at all but then I'm not sure how the LCDs were working). The library updates "corrected" this and forced the fmalpartida's library to be used in whole thus breaking my sketches.

To use fmalpartida's NewLiquidCrystal library, there is a manual manipulation that must be performed to the Arduino IDE install libraries. (Arduino installed liquid crystal must be removed)

I present:

bperrybap: This thread is a duplicate of the discussion in this thread: http://arduino.cc/forum/index.php/topic,76041.0.html My comment is in the other thread.

My general comment over there (summarized here) was that, IMHO, this library either needs to be able to coexist with the existing LiquidCrystal library (by having different names) or it should be a drop in replacement so existing code does not have to be modified to use it.

--- bill

In short I think my sketches got broke because because something in the libraries got fixed during the update process. (here I was thinking I was smart because I updated my libraries before I started on a new project. well foo on me)

It isn't possible to use just part of fm's newLiquidCrystal library. It has many dependencies on classes that only exist in that library. If you had a messed up installation and were only grabbing part of it, you would get compilation errors.

While there are many libraries that have a LiquidCrystal_I2C class, I've only seen one that had a constructor that would take a single parameter of an i2c addresses and that is fm's LiquidCrystal, but that library has always used a default pin mapping that would not work with your h/w.

I suspect that at some point you modified the default parameters in your local version of newLiquidCrystal LiquidCrystal_I2C to match your hardware. The re-installation, or an update of the library would clobber those local modifications.

But since you have said you have the earlier working library and know where you got if from, then just look at it and tell us which library the old one that worked is and how it differs from the library you just installed. Just run a diff or a meld between the two libraries and show us all the differences. Or post a zip of it, so we can see it. That would settle it.

I'm still betting that you modified the newLiquidCrystal library files to match your hardware and must have forgotten about doing it. That would explain everything you have told us.

BTW, That post of mine from 6.5 years ago about fm's newLiquidCrystal library , was when fm was getting started on newLiquidCrystal. It doesn't have anything to do with this. It was a comment on design/architecture of that library. Things back then were very different on Arduino than they are now as there was no library manager, no way to have the IDE install a library from a zip and no automated IDE library manager that automatically pulls libraries from the cloud. Everything was manual back then. My comment was that that there are two ways to go, either as a separate/different name or as a replacement that includes a LiquidCrystal class that can be used with no changes to existing code that uses LiquidCrystal. fm chose the latter, which was nice at the time, but it now means that it can never use the automated IDE library manager since the library manager does not allow multiple libraries with the same name and for sure will never allow a 3rd party library to override their IDE bundled library.

--- bill

bperrybap:
It isn’t possible to use just part of fm’s newLiquidCrystal library. It has many dependencies on classes that only exist in that library.
If you had a messed up installation and were only grabbing part of it, you would get compilation errors.

While there are many libraries that have a LiquidCrystal_I2C class, I’ve only seen one that had a constructor that would take a single parameter of an i2c addresses and that is fm’s LiquidCrystal, but that library has always used a default pin mapping that would not work with your h/w.

I suspect that at some point you modified the default parameters in your local version of newLiquidCrystal LiquidCrystal_I2C to match your hardware.
The re-installation, or an update of the library would clobber those local modifications.

But since you have said you have the earlier working library and know where you got if from, then just look at it and tell us which library the old one that worked is and how it differs from the library you just installed.
Just run a diff or a meld between the two libraries and show us all the differences.
Or post a zip of it, so we can see it.
That would settle it.

I’m still betting that you modified the newLiquidCrystal library files to match your hardware and must have forgotten about doing it. That would explain everything you have told us.

BTW,
That post of mine from 6.5 years ago about fm’s newLiquidCrystal library , was when fm was getting started on newLiquidCrystal. It doesn’t have anything to do with this.
It was a comment on design/architecture of that library. Things back then were very different on Arduino than they are now as there was no library manager, no way to have the IDE install a library from a zip and no automated IDE library manager that automatically pulls libraries from the cloud. Everything was manual back then. My comment was that that there are two ways to go, either as a separate/different name or as a replacement that includes a LiquidCrystal class that can be used with no changes to existing code that uses LiquidCrystal.
fm chose the latter, which was nice at the time, but it now means that it can never use the automated IDE library manager since the library manager does not allow multiple libraries with the same name and for sure will never allow a 3rd party library to override their IDE bundled library.

— bill

The NewLiquidCrystal library includes files name liquidcrystal. and liquidcrystal.h. As I recall, I had to delete the ones from the Arduino IDE. The comment may be referring to something else (perhaps out of context) but still true. The fmalpartida library cannot coexist in the environment without manually editing the Arduino IDE libraries to remove the conflict. I avoid making changes to libraries as that means I have to remember to make the same changes in the new revision of the authors library, and hope they have not improved on the library in such a way that I need to develop a new modification. Net_Devil was kind enough to accept a suggest and include my “modification”/feature as an integrated part of his program.

Attached is the library (or as much of it as I could post) as it was backed up prior to uninstalling 1.8.4 (I’m paranoid that way), and the sketch to which I have been referring.

NewliquidCrystal_1.3.4 - fmalpartida.zip (94 KB)

furnace_alarm_with_DAC_2_1.ino (10.4 KB)

adwsystems: Net_Devil was kind enough to accept a suggest and include my "modification"/feature as an integrated part of his program.

What does that mean?

Attached is the library (or as much of it as I could post) as it was backed up prior to uninstalling 1.8.4 (I'm paranoid that way), and the sketch to which I have been referring.

So you are saying that library in the zip was installed on your system and works with your hardware?

Not possible! At this point, it seems you don't know or understand which library you were actually using.

The library in that zip file is a partial copy of the real 1.3.4 release but the main library source and the i2c lcd backpack code is identical to the real 1.3.4 code. (it is missing some things but they are not needed to run the LCD)

That library uses a default mapping that is the pin mapping for fm's LCDXIO board when only an address is passed in:

#define EN 6  // Enable bit

/*!
 @defined 
 @abstract   Read/Write bit of the LCD
 @discussion Defines the IO of the expander connected to the LCD Rw pin
 */
#define RW 5  // Read/Write bit

/*!
 @defined 
 @abstract   Register bit of the LCD
 @discussion Defines the IO of the expander connected to the LCD Register select pin
 */
#define RS 4  // Register select bit

/*!
 @defined 
 @abstract   LCD dataline allocation this library only supports 4 bit LCD control
 mode.
 @discussion D4, D5, D6, D7 LCD data lines pin mapping of the extender module
 */
#define D4 0
#define D5 1
#define D6 2
#define D7 3

It does not match what you said was needed:

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

So it will not work with your backpack. And you could have easily looked yourself to check that as we asked but you didn't.

Through all of this, I have not seen anything that shows that a newLiquidCrystal library from fm's bitbucket repository can or could ever work with your backpack when only an i2c address is provided. And this library you as saying worked, is no exception.

The LiquidCrystal_I2C library in the IDE library manager (not the LiquidCrystal_I2C i/o class in newLiquidCrystal) does use the mapping you need, but does not contain a constructor that accepts only an i2c address.

If things were working with a constructor that only was given an i2c address the way you say, you must have had another library installed that you were using that has default mappings to work with your backpack h/w when only given an i2c address. Or you had another copy of fm's library on your machine that was modified and was being used vs the one you zipped up. An Arduino library can be installed in multiple locations and still work, and depending on the location and name of the directory used and the names of the header files used, it can override another copy of the same library or even another library installed somewhere else.

There are MANY LiquidCrystal_I2C libraries out there, I'm guessing you installed more than one of them, and that other library was being used rather than the library you just posted as the library you posted doesn't use your pin mapping by default.

The mess of "LiquidCrystal_I2C" libraries and i/o classes, is why I created the hd44780 library. When you install hd44780 from the library manager, it will be installed properly and you know what you are getting.

One thing is for certain, updating a newLiquidCrystal library isn't what broke things for you as every single released version of fm's code (including the code you posted in the zip image) used the same default pin mapping.

If things were working with that 1.3.4 library you posted installed and then broke when you updated your newLiquidCrystal library, you must have had multiple libraries installed and some of them were likely installed incorrectly and the system was working more by accident rather than by proper library installation/configuration. And when you did your recent newLiquidCrystal library update, you didn't install the update in the same location, by doing an improper/incorrect update of the library, and it happened to break the fragile system of incorrectly installed libraries you had that was "working" by overriding the actual library you were using in some other location.

At this point, I'm dropping out of this discussion as it seems clear to me that what happened here is really user error from incorrect and/or inconsistent installation of multiple LCD backpack libraries.

--- bill

bperrybap:
What does that mean?
So you are saying that library in the zip was installed on your system and works with your hardware?

It did until the library updates.

bperrybap:
The library in that zip file is a partial copy of the real 1.3.4 release but the main library source and the i2c lcd backpack code is identical to the real 1.3.4 code. (it is missing some things but they are not needed to run the LCD)

I know, I told you that.

adwsystems:
Attached is the library (or as much of it as I could post) as it was backed up prior to uninstalling 1.8.4 (I’m paranoid that way), and the sketch to which I have been referring.

bperrybap:
That library uses a default mapping that is the pin mapping for fm’s LCDXIO board when only an address is passed in:

#define EN 6  // Enable bit

/*!
@defined
@abstract  Read/Write bit of the LCD
@discussion Defines the IO of the expander connected to the LCD Rw pin
*/
#define RW 5  // Read/Write bit

/*!
@defined
@abstract  Register bit of the LCD
@discussion Defines the IO of the expander connected to the LCD Register select pin
*/
#define RS 4  // Register select bit

/*!
@defined
@abstract  LCD dataline allocation this library only supports 4 bit LCD control
mode.
@discussion D4, D5, D6, D7 LCD data lines pin mapping of the extender module
*/
#define D4 0
#define D5 1
#define D6 2
#define D7 3




It does not match what you said was needed:


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



So it will not work with your backpack.
And you could have easily looked yourself to check that as we asked but you didn't.

I’m not sure to what you are referring or what you think I needed to check. I didn’t modify the library, so I know there where no changes there (I suppose the file could have been corrupted instead of edited), I know the constructor in the original sketch, and the one that was then required to work.

bperrybap:
One thing is for certain, updating a newLiquidCrystal library isn’t what broke things for you as every single released version of fm’s code (including the code you posted in the zip image) used the same default pin mapping.

I never said it was the new version of fm’s library. I said said that many libraries were updated and one of the updates broke my sketches which used the LCD library developed in part by fmalpartida.

bperrybap:
If things were working with that 1.3.4 library you posted installed and then broke when you updated your newLiquidCrystal library, you must have had multiple libraries installed and some of them were likely installed incorrectly and the system was working more by accident rather than by proper library installation/configuration.
And when you did your recent newLiquidCrystal library update, you didn’t install the update in the same location, by doing an improper/incorrect update of the library, and it happened to break the fragile system of incorrectly installed libraries you had that was “working” by overriding the actual library you were using in some other location.

That is a possiblity, if one of the libraries installed code outside of the documents->arduino->libraries folder. Though the folders in post #6 are a complete list of directories existing at the time, my archive of downloaded libraries also includes IIC1602.zip and LiquidCrystal_I2C - fdebrabander .zip. But you will notice there are not folders in the libraries directory related to them, eg., to me that means they are not and were not installed.

bperrybap:
At this point, I’m dropping out of this discussion as it seems clear to me that what happened here is really user error from incorrect and/or inconsistent installation of multiple LCD backpack libraries.

I gave up back at post #23. I’m only here because I am sucker to know what went (was) wrong and what the answer is.

adwsystems: I gave up back at post #23. I'm only here because I am sucker to know what went (was) wrong and what the answer is.

And the answer is.....: User error

I'm not sure to what you are referring or what you think I needed to check.

Seriously? Seriously? That code fragment I posted is the default pin mapping used in in fm's newLiquidCrystal library. We have been talking about it this entire thread. david even pointed it out and called you on it way back in post #4 This code fragment shows the default pin mapping used when only an i2c address is passed in. That pin mapping does not match your h/w. This default pin mapping has never changed in fm's library. And THAT is why people questioned what you were saying. What you are saying simply does not match the library code you say you are using.

Further, there is no way to update an existing newLiquidCrystal library in its already existing directory in your sketchbook area and break things. It is simply not possible. Every single version of fm's newLiquidCrystal library uses the same default pin mapping. If you update the library by overwriting an existing newLiquidCrystal library that was being used (which is what would happen when correctly updating the library), the default pin mappings would not be changed.

It also isn't possible to update other libraries and more specifically the ones you specified in post #6 and cause the behaviors you are claiming.

Regardless of what actually happened, there is more to it than what you have described and you had to be using a i2c LCD library other than what you have shown us, as the library you have shown us and you say you were using simply would not work with your LCD device. And I cannot find any library that uses a LiquidCrystal_I2C class that has a constructor that takes a single i2c address parameter and uses a default pin mapping that works with your hardware and I searched through many different "LiquidCrystal_I2C" libraries and still can't find one. Even the one you have now showed us would not work with your h/w with default pin mappings. (which brings us back full circle to inconsistencies and things that don't make sense or are impossible)

My guess is that it looks to me that you installed multiple LCD libraries trying to get things working. Perhaps you installed some down in the IDE library area or even the core area (both of which are separate from your sketchbook libraries area) when trying to get things working and either installed a modified newLiquidCrystal library or modified it down there. You ended up getting something that worked, and then forgot about what you did, and where all the library modifications and installations were. And this newLiquidCrystal "update" you did was not updating newLiquidCrystal library files in an existing library directory so it broke the actual library that was being used vs the one you thought you were using. i.e. when you really starting using fm's newLiquidCrystal unmodified library it didn't work since that library never worked with your h/w in its original form.

Whatever you did had to involve manual library installations and/or updates that were done incorrectly. So it all comes back to user error.

-- bill

bperrybap: And the answer is.....: User error

That's fine. Most of the threads on this forum are diagnosing user error. What was the error? In this case we will never know as the original Arduino directory is gone.

bperrybap: Seriously? Seriously? That code fragment I posted is the default pin mapping used in in fm's newLiquidCrystal library. We have been talking about it this entire thread. david even pointed it out and called you on it way back in post #4 This code fragment shows the default pin mapping used when only an i2c address is passed in. That pin mapping does not match your h/w. This default pin mapping has never changed in fm's library. And THAT is why people questioned what you were saying. What you are saying simply does not match the library code you say you are using.

Yes, seriously. Since I didn't change the library there was no fruitful reason to check it, but for post #21 I not only checked it but compared new told. Low and behold I was right, there were no changes to fm's library.

bperrybap: It also isn't possible to update other libraries and more specifically the ones you specified in post #6 and cause the behaviors you are claiming.

Question: Are all of the libraries load via the library manager held in the documents->arduino->libraries folder?

bperrybap: Regardless of what actually happened, there is more to it than what you have described and you had to be using a i2c LCD library other than what you have shown us, as the library you have shown us and you say you were using simply would not work with your LCD device.

If it is, it isn't in the libraries folder. The sketch is posted, so you can see the include statement does not include a path (like hd44780 requires).

bperrybap: installed a modified newLiquidCrystal library

I said I hadn't and showed what I had. Insert colloquialism for insanity here.

bperrybap: Even the one you have now showed us would not work with your h/w with default pin mappings....

i.e. when you really starting using fm's newLiquidCrystal unmodified library it didn't work since that library never worked with your h/w in its original form.

No kidding. We proved that.

bperrybap: My guess is that it looks to me that you installed multiple LCD libraries trying to get things working. Perhaps you installed some down in the IDE library area or even the core area (both of which are separate from your sketchbook libraries area) when trying to get things working and either installed a modified newLiquidCrystal library or modified it down there. You ended up getting something that worked, and then forgot about what you did, and where all the library modifications and installations were. And this newLiquidCrystal "update" you did was not updating newLiquidCrystal library files in an existing library directory so it broke the actual library that was being used vs the one you thought you were using. i.e. when you really starting using fm's newLiquidCrystal unmodified library it didn't work since that library never worked with your h/w in its original form.

The only thing I can recall I had to do was to remove Arduino's LiquidCrystal library to not conflict with fmalpartida's. I must wonder if pert had it back in post #2. A library was installed and deleted. Then I installed fmpartida's library, but the old library was not completely gone and the sketches picked up on parts of both allowing the sketches to work. It appeared (appears) that I only had fm's library installed, but in fact had 1 1/2 libraries. The updates to one (or more) of the libraries removed the half thus breaking my sketches.

adwsystems: That's fine. What was the error? I hate making the same mistake twice.

I already posted my best guess as to what you did - which is the only thing that makes sense and accounts for all things you described as happening.

Yes, seriously. Since I didn't change the library there was no fruitful reason to check it, but for post #21 I not only checked it but compared new told. Low and behold I was right, there were no changes to that library.

We asked you to compare the library you said worked to the one you said didn't but you never did. If you had looked you would have seen that they were the same and at least I would not have wasted so much time as I would have chosen to move on sooner since you don't know what library code you were really using.

You changed something, an it likely involved a manual installation issue. Any time you use fm's library you must make manual changes to the system since you can't use it until you get the IDE bundled LiquidCrystal library out of the way. There are several ways to do that and many of not most users do not bother to read the actual instructions on fm's page for how to do it and do it wrong. While it usually still works, it can get them in to trouble later. This is compounded by the fact that depending on which version of the IDE you are using and which version of the newLiquidCrystal code you have, you may also have to make changes to fm's library code to get things to compile.

But none of that explains how you had a working library with the constructor you say was working. The code you say you were using and even provided would not work with your LCD device. You have yet to show us any i2c LCD library code that would work with the constructor you say you were using.

So at some point in time, you installed something or edited something in some version of an i2c LCD library installed in one of the several possible libraries directories on your system to make it work and forgot about.

Question: Are all of the libraries load via the library manager held in the documents->arduino->libraries folder?

Yes, but there are multiple libraries directories besides that one. The IDE will scan all of them and look into each library directory for an included header file. The IDE has a priority mechanism to determine how to select which directory to use when there are header file name collisions, as the case of having multiple libraries installed with a "LiquidCrystal_I2C.h" or "LiquidCrystal.h" header file. (Note that the priority rules inside the IDE has changed slightly over the years as well) The way Arduino does its libraries is very screwy and is a lot of work inside the IDE. No other development system works this way. It also can cause lots of strange and unexpected issues like using a different library than expected when there are multiple libraries installed that have header files with the same name - which I believe is what was happening to you. Somewhere at some point you installed a newLiquidCrystal library somewhere else and modified it to work with your h/w.

If it is, it isn't in the libraries folder. The sketch is posted, so you can see the include statement does not include a path (like hd44780 requires).

What do you mean by "does not include a path (like hd44780 requires)" ? The hd44780 library works just like any other library with respect header files in the sketch. i.e.

#include                        // main hd44780 header
#include  // i2c expander i/o class header

are not specifying a path or where the header files live. The IDE still must scan multiple Arduino library locations to locate the directory where the hd44780 library lives just like any other Arduino library.

The only thing I can recall I had to do was to remove Arduino's LiquidCrystal library to not conflict with fmalpartida's. I must wonder if pert had it back in post #2. A library was installed and deleted. Then I installed fmpartida's library, but the old library was not completely gone and the sketches picked up on parts of both allowing the sketches to work. It appeared (appears) that I only had fm's library installed, but in fact had 1 1/2 libraries. The updates to one (or more) of the libraries removed the half thus breaking my sketches.

Sounds very unlikely that a library was only partially deleted but still existed enough to still work. I don't even believe that is possible. If it is there enough for the IDE to see it, it is still there and you could see it. To do any of that would require doing some manual installation/configuration/modification - and recall that incorrect manual library installation and/or configuration was what I said I believe the issue to be.

And then beyond all that, I have yet to see any i2c LCD library that had a default pin mapping that used a constructor like you said you were using.

This isn't an issue of switching to a new version of newLiquidCrystal that breaks your code, it is a case of you doing some things, including some manual manipulations of your libraries that you don't remember - which supposedly got things to work. Then later you did some things which includes updating the newLiquidCrystal library, which you also can't fully remember which broke your supposedly working system.

You can't remember what you did, nor have you been able to show us any i2c LCD library code that works the way you say the code works for you.

Given all these unknowns and conflicting information there is no way I can help you and am not going to waste any more of my time on this.

--- bill

bperrybap:
So at some point in time, you installed something

and then deleted it (or tried to), probably.

bperrybap:
edited something in some version of an i2c LCD library installed in one of the several possible libraries directories on your system to make it work and forgot about.

For the xteenth time. I made no edits directly to any libraries. It has been so long since I worked that way, I don’t remember the last time I did.

bperrybap:
What do you mean by “does not include a path (like hd44780 requires)” ?
The hd44780 library works just like any other library with respect header files in the sketch.
i.e.

#include <hd44780.h>                       // main hd44780 header

#include <hd44780ioClass/hd44780_I2Cexp.h> // i2c expander i/o class header



are not specifying a path or where the header files live.

I see a path in the code quote you posted. Allow me to place it in bold. #include <**hd44780ioClass/**hd44780_I2Cexp.h> Which in all my years of C programming mean to use that include file and not the blahblahblah/hd44780_I2Cexp.h named file. You can still run into problem if there are to directories that both include the same subdirectory. Been through that too (I wasn’t the nincompoop that created the secondary same named directory).

bperrybap:
This isn’t an issue of switching to a new version of newLiquidCrystal that breaks your code, it is a case of you doing some things, including some manual manipulations of your libraries that you don’t remember - which supposedly got things to work.
Then later you did some things which includes updating the newLiquidCrystal library, which you also can’t fully remember which broke your supposedly working system.

I love how you combine items into a tangle to try to make an pivot point.
I never said updating to the new library was the issue. I suspected it was part of or related to the issue. Nothing updated now and then more updated later. All the libraries one after the other. Said that all along. Had IDE 1.8.4, updated all libraries. Worked before, broke after. Cleaned house, installed 1.8.5 and the current libraries. Still broke.

bperrybap:
You can’t remember what you did, nor have you been able to show us any i2c LCD library code that works the way you say the code works for you.

If someone had asked this early on, before I removed v1.8.4 then we could have pursued files in the Arduino directory. But alas that was my primary suspect due to have to delete things to install fm’s library.

Besides that, how am I supposed to show you a working file set when it is broke and I don’t know why. What I have provided is what was working or from what was working. This is like you asking to show you that my broke down car can go 100mph. I can’t it’s broke. But I have the speeding ticket to show it used to.

bperrybap:
Given all these unknowns and conflicting information there is no way I can help you and am not going to waste any more of my time on this.

Conflicting? Contradicting? I do not see any two statements that say I did this and then say I did that. May be short on information, mostly that I don’t know and/or cannot now find. But neither conflicting nor contradicting.

This will be my very last post in this thread.

No you don't see path in the include. You see a subdirectory being specified on an include. BIG difference. None of the headers included in hd44780 have a path to the directory where the library is installed No Arduino sketch does. The second include is specifying a subdirectory that is relative to an include directory just like the first included header and all the included headers in arduino sketches. The way Arduino handles what they call "libraries" can and does cause issues when there are header file collisions in libraries. Some of the newer rules added to more recent IDEs are attempts to work around this but the issue is not solvable given the way they process their libraries and the way they use the -I include paths with the compiler. There are alternative ways to handle this, I even proposed a few many years ago, but they rejected them, mainly I think because they didn't understand the real issue until very recently.

Conflicting? Contradicting? I do not see any two statements that say I did this and then say I did that. May be short on information, mostly that I don't know and/or cannot now find. But neither conflicting nor contradicting.

Really? You honestly still don't see any of the issues?

In post 11 you said you were using the fm newLiquidCrystal library v1.3.4 from the bitbucket site. Given the code in that library, it will not work with your hardware. That is a fact. newLiquidCrystal 1.3.4 uses the same default pin mappings as 1.3.5 and the i2c lcd code is the same for both of those libraries and that default pin maping is for the LCDXIO board which will not work with you LCD device. So that is a situation of two things in direct conflict, you say you are using newLiquidCrystal by only specifying the i2c address in the constructor and yet that will not work with any version of newLiquidCrystal library code from fm's bitbucket site. This is what caused david to say "I don't believe you". He got it right in that it is impossible for you to be actually using fm's newLiquidCrystal library with the single i2c address parameter you say you are using and have it working. It simply is not possible. You were not using the library you were telling us you were using, or were using it differently than the way you were saying you were using it. So that is a big conflict in information.

Here another guess on what could have happened based on something I just noticed. This what I just noticed that could be a clue: In your code in post #11 there is this line:

//LiquidCrystal_I2C lcd(0x38, BACKLIGHT_PIN, POSITIVE);  // Set the LCD I2C address

That is not a valid constructor parameter list for newLiquidCrystal. Further, it is not a valid constructor list for any i2c LCD library I've ever seen that uses a LiquidCrytal_I2C class, and I have looked close to 20 different ones. The LiqiudCrystal_I2C library does have a constructor that takes 3 parameters but those are not them. That library uses:

 LiquidCrystal_I2C(uint8_t lcd_Addr,uint8_t lcd_cols,uint8_t lcd_rows);

There are 3 parameters, but the 2nd two are the cols and rows of the LCD. That library historically used lcd.init() instead of begin(cols,rows) but newer versions added begin(cols,rows) If you had the newer LiquidCrystal_I2C library and passed in a backlight pin instead of cols, and POSITIVE instead of rows (which would be incorrect), it could still work if also used lcd.begin(cols,rows)

So if prior to doing your updates you were also using LiquidCrystal_I2C lcd(0x38, BACKLIGHT_PIN, POSITIVE) and had the LiquidCrystal_I2C library installed and calling lcd.begin(cols, rows) instead of lcd.init() as shown in your sample code in post #11 it would work, as you would be using the LiquidCrystal_I2C library which uses the same default pin mapping as your hardware.

But that would be a VERY BIG detail that you left out and would have instantly told us about a messed up installation of multiple LCD libraries.

I have no idea as to what you actually did, but you had to have installed multiple i2c LCD libraries. No question there.

And like I said before, there can and will be issues when you have multiple library directories with header files by the same name. This is a great example of what can happen when installing/using multiple libraries that have a header file with the same name. This issue is quite common when using newLiquidCrystal and any of the LiquidCrystal_I2C library varieties. And I have seen many users screw up their installation when they are playing around with multiple i2c lcd libraries and/or with newLiquidCrystal when not following the installation instructions on fm's site.

And now I'll say goodbye to this thread.

--- bill

bperrybap: No you don't see path in the include. You see a subdirectory being specified on an include. BIG difference.

If you say so. The programming standards I have to follow for my day job, call it a path. Potato, potato. (OK that doesn't work when typed)

bperrybap: In post 11 you said you were using the fm newLiquidCrystal library v1.3.4 from the bitbucket site. Given the code in that library, it will not work with your hardware. That is a fact. newLiquidCrystal 1.3.4 uses the same default pin mappings as 1.3.5 and the i2c lcd code is the same for both of those libraries and that default pin maping is for the LCDXIO board which will not work with you LCD device. So that is a situation of two things in direct conflict, you say you are using newLiquidCrystal by only specifying the i2c address in the constructor and yet that will not work with any version of newLiquidCrystal library code from fm's bitbucket site. This is what caused david to say "I don't believe you". He got it right in that it is impossible for you to be actually using fm's newLiquidCrystal library with the single i2c address parameter you say you are using and have it working. It simply is not possible. You were not using the library you were telling us you were using, or were using it differently than the way you were saying you were using it. So that is a big conflict in information.

Parts of pieces are being made to conflict. I have provided no conflicting or contradicting information. I am providing all the information and answers to the questions to the best of my ability and knowledge. If it doesn't add up, then there is another question to be asked. So ask it. I asked about libraries in post #1. No a single person EVER touched on the original question. Somewhere in that question lies the answer, and you have agreed with it for 10 posts. As I have mentioned, I don't have a copy of the Arduino libraries directories, so I can't answer the question even if asked.

Not once have I ever said "yes I did" then said "no I didn't" or "I did that" then said "I did this". I started in medias res, working both forward and backward from the point in time where the sketches stopped compiling. Prior to the library manager library updates, was installing/uninstalling libraries. I will say it again, that I believed to have been fully uninstalled such that fmalpartida's library was the only one in use.

bperrybap: Here another guess on what could have happened based on something I just noticed. This what I just noticed that could be a clue: In your code in post #11 there is this line:

//LiquidCrystal_I2C lcd(0x38, BACKLIGHT_PIN, POSITIVE);  // Set the LCD I2C address

That is not a valid constructor parameter list for newLiquidCrystal. Further, it is not a valid constructor list for any i2c LCD library I've ever seen that uses a LiquidCrytal_I2C class, and I have looked close to 20 different ones.

It's also not even a valid line of programming. In your rush, you missed two small characters. Allow me to point them out, the first is / and the second is /. Put together, they mean comment in C programming.

That line in and of itself is useless. It is NOT part of the compiled program. That isn't the constructor being used.

But it does allude to the fact that at some time I was playing with multiple libraries. I acknowledged with that when asked. As I said, (I thought) I had removed all of the other libraries completely and properly installed (without modification) fmalpartida's library. Have I ever even alluded to or insinuated that I had modified the internals of any library (yes I modified the Arduino LiquidCrystal library by deleting it, not sure if that counts but I also acknowledge it)?

I still have no understanding why the focus is on the constructor rather on the library/libraries being used. The sketches worked until the libraries were updated. Therefore something with the library updates caused the problem. I wanted to look at the library updates and the files that may have changed at a macro level, but everyone wanted to delve into the micro level of what was in a few files.

bperrybap: So if prior to doing your updates you were also using LiquidCrystal_I2C lcd(0x38, BACKLIGHT_PIN, POSITIVE) and had the LiquidCrystal_I2C library installed and calling lcd.begin(cols, rows) instead of lcd.init() as shown in your sample code in post #11 it would work, as you would be using the LiquidCrystal_I2C library which uses the same default pin mapping as your hardware.

Yet again fabricating a pivot point. Did you ever ask, did I ever say the original working constructor was not LiquidCrystal_I2C lcd(0x38)? Allow me to state again and is shown in the SAME sketch on the next line, the constructor being used prior the library updates is LiquidCrystal_I2C lcd(0x38).

I will admit to having dead code from development in the sketch. Yep. There it is. Bill you have highlighted it for the world to see. So I refer you back to my previous comment ("it does allude to the fact that at some time (when, not a clue) I was playing with multiple libraries. I agreed with that when asked. As I said, (I thought) I had removed them all and properly installed (without modification) fmalpartida's library."

bperrybap: And now I'll say goodbye to this thread.

--- bill

As I mentioned, I stuck with the thread only in the hope that an answer or direction may be garnered from the continuing discussion. But as you have only provided criticism instead of questions on this topic (answers would come in their own time) and continued to imply the devices in the field don't work, couldn't work, is impossible to work, I gave up hope of being provided direction 15 posts ago.

I still have no understanding why the focus is on the constructor rather on the library/libraries being used. The sketches worked until the libraries were updated.

This is because the constructor which works LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE); was not the default, one parameter, constructor of the F. Malpartida library in any version of that code. David didn't believe that you were using that library. Neither did I.

continued to imply the devices in the field don't work, couldn't work

The devices that were working in the field were not using the unmodified F.Malpartida library.

@cattledog, Thank you for proving my point. Focusing again on the constructor rather than the libraries used. If there is no belief the F. Malpartida library is being used, then which one was or where is the library (in the Arduino IDE possible compile locations).

cattledog: The devices that were working in the field were not using the unmodified F.Malpartida library.

Partially agree, because there are two items tied together erroneously. The F.Malpartida library is (was) unmodified and was the project compiled using only the F.Malpartida library. The first part is true. The second part must not be. Again was there not a single question to investigate that aspect further.

Back in July of 2015, we saw an earlier verse of this same bad song: https://forum.arduino.cc/index.php?topic=336870.0 I just wish I had recognized the tune so I could have changed the station sooner.

In several of your posts in other threads over the past couple of years you have used this constructor in the code you provided:

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

Including in this post from August 22, 2017 (about 7 months ago)https://forum.arduino.cc/index.php?topic=496246.msg3385547#msg3385547

Where you also broke your system by doing some kind of change or update. But in no code you have provided in your previous posts in other threads were you ever using fm's library with a default pin mapping like you claimed to have been using in this thread.

Back in July of 2015, we saw an earlier verse of this same bad song

Yikes.

https://www.youtube.com/watch?v=TN-cNe4EpgE