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