Go Down

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


If the I2C expander pin map is the default, there is a constuctor that requires only the I2C address of the I2C expander.
I know because it used to work. But the displays I had on hand and worked previous with just the address in the constructor now require the full constructor. So are there any ideas on what may have happened to now require the full constructor to be specified where previously just the address worked?


Mar 21, 2018, 02:19 pm Last Edit: Mar 21, 2018, 02:19 pm by david_prentice
Go on.   The short form of constructor defaults to EN=6, RW=5, RS=4, D4=0, D5=1, D6=2, D7=3, BL=7

This will be equivalent to
Code: [Select]

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

If you have the other style of adapter you must use the full-fat constructor:
Code: [Select]
LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);

Since you own 12 different backpacks,   you can use the appropriate constructor.

It has always surprised me that the default is  D4=0, D5=1, D6=2, D7=3 because in my experience P4..P7 is more common.



Mar 21, 2018, 02:24 pm Last Edit: Mar 21, 2018, 02:37 pm by adwsystems
Since you own 12 different backpacks, you can use the appropriate constructor.
I have 2 different backpacks, and many of each.

But that isn't explaining why the full constructor is now required when prior to the library updates it was not.


I give up.   Both I and GroundFungus have explained it very clearly.


Mar 21, 2018, 02:36 pm Last Edit: Mar 21, 2018, 02:44 pm by adwsystems
I give up.   Both I and GroundFungus have explained it very clearly.
I'm sorry I must not be seeing the answer. I see lot's of really good information, but not the answer. Can you give me a hint as to which post explains why the full constructor is now required when prior to the library updates it was not?

(stating to use a different library instead of a library that had been used and working for years, is not an explanation for why the sketch no longer works after having updated other libraries)


OK, no more about the much better library.  

The logical explanation, from what I see, is that the older library that you were using had the defaults in the .cpp file to match your old displays.  The new version has different defaults.  How did you do the update?  Through Library Manager or download the library and manual install?  Do you still have the old library and can check the default pin map to see if it is different?

I had the following libraries in the 'mysketches'->libraries directory:
The proper path for the library folder should be \Documents\Arduino\libraries.  Is that what you mean?


The proper path for the library folder should be \Documents\Arduino\libraries.  Is that what you mean?
Yes, more or less (basically, depending on the OS and drive layout but that another topic). That is to say not in the Program Files\Arduino\libraries directory.

OK, no more about the much better library.
I'll get back to that, especially if i have to change all my sketches. Then I might as well also change the library being used.

How did you do the update?  Through Library Manager or download the library and manual install?
It was updated through the 'Add a .ZIP Library...' option. The defaults look the same between the new and old. I wish I could tell what the old version number is. I don't see the version number documented anywhere.


Well, that was my best shot.  I can see no other explanation.


Well, that was my best shot.  I can see no other explanation.
I ran out of ideas myself, hence the thread. I'm hoping fmalpartida is still around and will chime in.

I have one thing to try, but I am not optimistic (and can't try until I'm at home with my stuff) as I think it only applies to the parallel displays (as I recall there is some sort of name conflict with the Arduino IDE and fmalpartida's library).


I had a look at the file that contains the LiquidCrystal_I2C constructors; there does not seem to be a difference between 1.2.1 (not even called NewLiquidCrystal), 1.3.1 and 1.3.4.

Checked with WinMerge.
If you understand an example, use it.
If you don't understand an example, don't use it.

Electronics engineer by trade, software engineer by profession. Trying to get back into electronics after 15 years absence.


Mar 21, 2018, 08:16 pm Last Edit: Mar 21, 2018, 08:27 pm by bperrybap
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:
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


Mar 22, 2018, 12:05 am Last Edit: Mar 22, 2018, 12:06 am by david_prentice
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.



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:
This thread is a duplicate of the discussion in this thread:
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)

Go Up