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: NewLiquidCrystal library with I2C LCD - #2 by bperrybap - Displays - Arduino Forum
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