Go Down

Topic: A useless discussion about how a working sketch can't possibly work (Read 2826 times) previous topic - next topic

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

adwsystems

#31
Mar 25, 2018, 04:46 am Last Edit: Mar 25, 2018, 04:53 am by adwsystems
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.

bperrybap

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?

Quote
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:
Code: [Select]
#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:
Code: [Select]
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

adwsystems

#33
Mar 25, 2018, 09:20 pm Last Edit: Mar 25, 2018, 09:21 pm by adwsystems
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.

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.
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.
That library uses a default mapping that is the pin mapping for fm's LCDXIO board when only an address is passed in:
Code: [Select]
#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:
Code: [Select]
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.

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.

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.
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.

bperrybap

#34
Mar 25, 2018, 10:32 pm Last Edit: Mar 25, 2018, 10:33 pm by bperrybap
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

Quote
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

adwsystems

#35
Mar 25, 2018, 11:56 pm Last Edit: Mar 26, 2018, 01:21 am by adwsystems
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.

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.

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?

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).

installed a modified newLiquidCrystal library
I said I hadn't and showed what I had. Insert colloquialism for insanity here.

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.

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.


bperrybap

#36
Mar 26, 2018, 01:26 am Last Edit: Mar 26, 2018, 01:28 am by bperrybap
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.

Quote
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.


Quote
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.


Quote
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.
Code: [Select]
#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.
The IDE still must scan multiple Arduino library locations to locate the directory where the hd44780 library lives just like any other Arduino library.

Quote
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









adwsystems

#37
Mar 26, 2018, 02:07 am Last Edit: Mar 26, 2018, 03:05 am by adwsystems
So at some point in time, you installed something
and then deleted it (or tried to), probably.

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.

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.
Code: [Select]
#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).

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.

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.

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.

bperrybap

#38
Mar 26, 2018, 03:06 am Last Edit: Mar 26, 2018, 03:07 am by bperrybap
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.

Quote
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:
Code: [Select]
//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:
Code: [Select]
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










adwsystems

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)


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.

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:
Code: [Select]
//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.

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."

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.








cattledog

Quote
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
Code: [Select]
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.

Quote
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.


adwsystems

@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).

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.

bperrybap

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.

bperrybap

In several of your posts in other threads over the past couple of years you have used this constructor in the code you provided:
Code: [Select]
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.



cattledog


Go Up