Arduino Forum

Using Arduino => Programming Questions => Topic started by: adwsystems on Mar 21, 2018, 01:53 am

Title: A useless discussion about how a working sketch can't possibly work
Post by: adwsystems on Mar 21, 2018, 01:53 am
I have been using the NewLiquidCrystal library from fmalpartida for years (basically since I started using I2C LCD in my second Arduino project).

I recently started a new project and thought it would be a good idea to update my libraries to the latest. I thought it was a good idea. Apparently I was wrong.

None of my sketches that include I2C LCDs work. They used to and now they don't.

I had been using the line to define the LCD
LiquidCrystal_I2C lcd(0x27);

now I have to use
LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);

Any idea on what other library update may have caused this issue?
Title: Re: New issue with NewLiquidCrystal Library
Post by: groundFungus on Mar 21, 2018, 02:47 am
I don't know what the update changed.  I, too, used that library for years.  Just lately I discoverd the hd44780 library. (https://github.com/duinoWitchery/hd44780)  I believe the hd44780 library is superior.  It will auto detect the I2C address and the I2C expander to LCD wiring.  Most of the functions are the same as the other liquid crystal libraries.   Use the hd44780_I2Cexp class.
Title: Re: New issue with NewLiquidCrystal Library
Post by: pert on Mar 21, 2018, 06:31 am
The frustrating thing is that there are multiple libraries of the same name but with different APIs. So it may be that you updated to a different library of the same name. Or maybe the API of the library you were using changed since the version you were using previously. You have the choice of updating your code according to the new API or finding a library/version compatible with your code.

It's a good idea to document the dependencies of your projects with links to where they can be downloaded from and which version the code was written for. That only takes a few seconds while you're writing the project and can save you or someone else a ton of time and frustration later. I like to add a comment after the #include directive for each external dependency.
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 21, 2018, 11:16 am
The frustrating thing is that there are multiple libraries of the same name but with different APIs. So it may be that you updated to a different library of the same name. ...

It's a good idea to document the dependencies of your projects with links to where they can be downloaded from and which version the code was written for. That only takes a few seconds while you're writing the project and can save you or someone else a ton of time and frustration later. I like to add a comment after the #include directive for each external dependency.
Been there done that. I know exactly who wrote it and where I got both libraries from. They are both revisions of the NewLiquidCrystal library written by fmalpartida. I even have copies of the new and the old libraries Though I cannot find a revision or revision history in the old library, so I'm not sure which version it is; but I do have a copy of it.


Or maybe the API of the library you were using changed since the version you were using previously. You have the choice of updating your code according to the new API or finding a library/version compatible with your code.
Very possible. But I'm not sure of that and here is why:

I uninstalled IDE v1.8.4 cleaned everything. Installed 1.8.5, updated all the built-in libraries and then added the old fmalpartida NewLiquidCrystal library and they still don't work on the project without the change  (they compile fine, just not work on the project). Since I'm not interested in being stuck on one IDE version, it did not make sense to reinstall 1.8.4 and try to get my sketches to work. I want to keep moving forward, not stuck in the past. So my interest is to understand what changed that caused my sketches to now fail to work.
Title: Re: New issue with NewLiquidCrystal Library
Post by: david_prentice on Mar 21, 2018, 11:41 am
I had been using the line to define the LCD
LiquidCrystal_I2C lcd(0x27);

now I have to use
LiquidCrystal_I2C lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);

Any idea on what other library update may have caused this issue?
I don't believe you.   From the "older" Malpardita library:
Code: [Select]

#define D4 0
#define D5 1
#define D6 2
#define D7 3


// CONSTRUCTORS
// ---------------------------------------------------------------------------
LiquidCrystal_I2C::LiquidCrystal_I2C( uint8_t lcd_Addr )
{
   config(lcd_Addr, EN, RW, RS, D4, D5, D6, D7);
}

i.e. the short form constructor puts the data bus on P0, P1, P2, P3 of the PCF8574
your long form constructor puts the data bus on P4, P5, P6, P7 of the PCF8574

All the backpacks that I possess use P4, P5, P6, P7.
Obviously there are a whole load of P0, P1, P2, P3 style backpacks on the market but I have never seen one.

Whichever library you choose,   it is wise to run a diagnostic to determine which style of backpack you possess.
Personally,   I would advise using the hd44780 library.   Especially since it is supported by the Library Manager.

David.
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 21, 2018, 12:25 pm
I don't believe you.
That's fine. But it is a fact.

I have two dozen happy customers with units with this code installed:

Code: [Select]
#include <LiquidCrystal_I2C.h>
#include <Wire.h>

// DEBUG_MODE
// 1 ADC Readings
// 2 Temp reading timer
// 4 DAC
#define DEBUG_MODE 4

#define TEMP_READ_INTERVAL 250 // enter interval in milliseconds
#define SP_DISPLAY_TIME 5000 // enter interval in milliseconds

#define ALM_ACK 2
#define ALM_LIGHT 12
#define ALM_BUZZER 11

#define TEMP_PIN 2
#define OFF_SP_PIN 1
#define ON_SP_PIN 3

#define SP_Offset 100.0 //degF
#define SP_Sens 100.0 / 5.0 //100 degF span over 5.0 volts
#define temp_amp_gain 2.0
#define on_amp_gain 1.0
#define off_amp_gain 1.0
#define adc_sens 1.0*5.0/1024.0 // voltage value of one ADC step

LiquidCrystal_I2C lcd(0x27);


// define some values used by the panel and buttons
int lcd_key     = 0;
int adc_key_in  = 0;
byte adc_pin = 0;

int adcReading;
boolean adcStarted=false;
boolean adcDone=false;

float on_temp_sp, off_temp_sp, temp_reading;

byte Startup_Complete =0;

boolean alarm_status = 0;
boolean alarm_ack = 0;


// ADC complete ISR
ISR (ADC_vect)
{
  byte low, high;

  low = ADCL;
  high = ADCH;

  adcReading = (high << 8) | low;
  adcDone = true;
}  // end of ADC_vect

void setup()
{
  lcd.begin(16, 2);

  Serial.begin (115200);

  pinMode(ALM_ACK, INPUT);
  pinMode(ALM_BUZZER, OUTPUT);
  pinMode(ALM_LIGHT, OUTPUT);

  Startup_Complete=0;
  alarm_ack=0;
  digitalWrite(ALM_BUZZER, 0);
  digitalWrite(ALM_LIGHT, 0);
  
  adc_pin = TEMP_PIN;
  
  Wire.begin();
}


Please feel free to explain how it works.

(only the relevant part posted as the whole program exceeds the 9k limit)

Edit:

Here is the code from the HelloWorld_I2C included with fmalpartida NewLiquidCrystal library:

Code: [Select]
#include <Wire.h>
#include <LiquidCrystal_I2C.h>



#define BACKLIGHT_PIN     13

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

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


// Creat a set of new characters
const uint8_t charBitmap[][8] = {
   { 0xc, 0x12, 0x12, 0xc, 0, 0, 0, 0 },
   { 0x6, 0x9, 0x9, 0x6, 0, 0, 0, 0 },
   { 0x0, 0x6, 0x9, 0x9, 0x6, 0, 0, 0x0 },
   { 0x0, 0xc, 0x12, 0x12, 0xc, 0, 0, 0x0 },
   { 0x0, 0x0, 0xc, 0x12, 0x12, 0xc, 0, 0x0 },
   { 0x0, 0x0, 0x6, 0x9, 0x9, 0x6, 0, 0x0 },
   { 0x0, 0x0, 0x0, 0x6, 0x9, 0x9, 0x6, 0x0 },
   { 0x0, 0x0, 0x0, 0xc, 0x12, 0x12, 0xc, 0x0 }
   
};

void setup()
{
   int charBitmapSize = (sizeof(charBitmap ) / sizeof (charBitmap[0]));

  // Switch on the backlight
  pinMode ( BACKLIGHT_PIN, OUTPUT );
  digitalWrite ( BACKLIGHT_PIN, HIGH );
 
  lcd.begin(16,2);               // initialize the lcd

   for ( int i = 0; i < charBitmapSize; i++ )
   {
      lcd.createChar ( i, (uint8_t *)charBitmap[i] );
   }

  lcd.home ();                   // go home
  lcd.print("Hello, ARDUINO "); 
  lcd.setCursor ( 0, 1 );        // go to the next line
  lcd.print (" FORUM - fm   ");
  delay ( 1000 );
}

void loop()
{
   lcd.home ();
   // Do a little animation by writing to the same location
   for ( int i = 0; i < 2; i++ )
   {
      for ( int j = 0; j < 16; j++ )
      {
         lcd.print (char(random(7)));
      }
      lcd.setCursor ( 0, 1 );
   }
   delay (200);
}


Two items to note:
1. The constructor is LiquidCrystal_I2C lcd(0x38);
2. It doesn't work either without modifying the constructor. It used to work, I used it and the I2CLCDGuesser to test each LCD when it arrives.
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 21, 2018, 12:28 pm
This is from the readme.md file of the old library:
Code: [Select]
# README #

## Introduction ##

![LCD library](https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads/I2CLCDextraIO_assemblyProject_small.jpg)

Welcome to the *LCD Library* for **Arduino** and **Chipkit**. It is a derivate of the original LiquidCrystal Library as sourced in the Arduino SDK. It has been developed to be compatible with the current LiquidCrystal library,
its performance is almost 5 times faster and fully extendable if need be.

It supports most ``Hitachi HD44780`` based LCDs, or compatible, connected to any project using: 4, 8
wire parallel interface, I2C IO port expander (native I2C and bit bang) and Shift Regiter.

It currently supports 4 types of connections:

* 4 bit parallel LCD interface
* 8 bit parallel LCD interface
* I2C IO bus expansion board with the PCF8574* I2C IO expander ASIC such as [I2C LCD extra IO](http://www.electrofunltd.com/2011/10/i2c-lcd-extra-io.html "I2C LCD extra IO").
* ShiftRegister adaptor board as described [Shift Register project home](http://code.google.com/p/arduinoshiftreglcd/ "Shift Register project home") or in the HW configuration described below, 2 and 3 wire configurations supported.
* ShiftRegister 3 wire latch adaptor board as described [ShiftRegister 3 Wire Home](http://www.arduino.cc/playground/Code/LCD3wires "ShiftRegister 3 Wire Home")
* Support for 1 wire shift register [ShiftRegister 1 Wire](http://www.romanblack.com/shift1.htm "ShiftRegister 1 Wire")
* I2C bus expansion using general purpose IO lines.

### How do I get set up? ###

* Please refer to the project's [wiki](https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home "wiki")


### Contributors
The library has had the invaluable contribution of:

* [piccaso](http://www.3guys1laser.com/blog-cheap-arduino-2-wire-lcd-display-0 "picas") - Florian Fida - Flo, thanks for testing and improving the SR library, initial version of the 1 wire interface and speed improvements.
* B. Perry - *bperrybap@opensource.billsworld.billandterrie.com*, with his thoughtful contribution, speed improvements and development support for the SR2W library.
* Adrian Piccioli, with his contribution to the i2c GPIO support.
* [todbot](https://github.com/todbot "todbot") Tod E. Kurt for the [softwarei2cmaster](https://github.com/todbot/SoftI2CMaster "softwarei2cmaster") library.
* [felias-fogg](https://github.com/felias-fogg) - Bernhard for the [softwarei2cmaster fast](https://github.com/felias-fogg/SoftI2CMaster "softwirei2cmaster")

#### Contribution guidelines

* Writing tests
* Code review
* Help out with bug fixing
* Setup a project logo
* Write new drivers to support more LCDs.

### Who do I talk to? ###

* Repo owner or admin
* For SoftI2CMaster latest versions, updates and support, please refer to [SoftI2CMaster](https://github.com/todbot/SoftI2CMaster "todbot")


I had the following libraries in the 'mysketches'->libraries directory:
Adafruit_ADS1X15-master
DallasTemperature
Firmata
NewliquidCrystal
OneWire
RTClib-master
SD
SDFat

I'm not BSing you all. It is as I said.
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 21, 2018, 12:33 pm
Whichever library you choose,   it is wise to run a diagnostic to determine which style of backpack you possess.
I use the i2cLCDguesser to determine the backpack settings. I now have two different backpacks to deal with.  >:( The older backpacks are YWRobot, where I do not think you can change the I2C address. I now have several PCF8574A backpacks, where you can set/change the I2C address. Both have different settings for the pin assignments and for the addresses. I cannot set the PCF8574A version to the 0x27 address of the YWRobot version.  :(
Title: Re: New issue with NewLiquidCrystal Library
Post by: groundFungus on Mar 21, 2018, 12:35 pm
You have 2 dozen LCD displays that use the library's default constructor to determine the LCD to I2C expander pin mapping.  If you change to a different LCD display, there is no guarantee that It's pin mapping is the same.  Then you have to modify the constructor in the sketch to match the new display.

With the hd44780 library, if you change a display, the library will, automatically, detect the new pin mapping (and the I2C address).
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 21, 2018, 12:41 pm
You have 2 dozen LCD displays that use the library's default constructor to determine the LCD to I2C expander pin mapping.
Understood.

If you change to a different LCD display, there is no guarantee that It's pin mapping is the same.  Then you have to modify the constructor in the sketch to match the new display.
Understood. Expect the previously working sketches with the previously work YWRobot backpack no longer work. (I have put the new carton of PCF8574A LCDs aside until I can get the previously working YWRobot versions operable again.)

So no change to LCD model (ie., use old one) = does not work post-library update.
Title: Re: New issue with NewLiquidCrystal Library
Post by: sterretje on Mar 21, 2018, 12:46 pm
Can you provide links to the libraries (old and new). I did have a look around and found https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads/ (https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads/).

Installed 1.3.5 from there and compiled the HelloWorld_i2c without errors in IDE 1.8.5 (Windows 8); plenty warnings about unused parameters though.
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 21, 2018, 12:48 pm
Can you provide links to the libraries (old and new). I did have a look around and found https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads/ (https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads/).

Installed 1.3.5 from there and compiled the HelloWorld_i2c without errors in IDE 1.8.5 (Windows 8); plenty warnings about unused parameters though.
You have the link (same as in the readme file quoted above), only I am using 1.3.4. I have no errors of any sort during the compile or upload of the HelloWorld_I2C sketch to an Arduino UNO.

Code: [Select]
#include <Wire.h>
#include <LiquidCrystal_I2C.h>

#define BACKLIGHT_PIN     13

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

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


// Creat a set of new characters
const uint8_t charBitmap[][8] = {
   { 0xc, 0x12, 0x12, 0xc, 0, 0, 0, 0 },
   { 0x6, 0x9, 0x9, 0x6, 0, 0, 0, 0 },
   { 0x0, 0x6, 0x9, 0x9, 0x6, 0, 0, 0x0 },
   { 0x0, 0xc, 0x12, 0x12, 0xc, 0, 0, 0x0 },
   { 0x0, 0x0, 0xc, 0x12, 0x12, 0xc, 0, 0x0 },
   { 0x0, 0x0, 0x6, 0x9, 0x9, 0x6, 0, 0x0 },
   { 0x0, 0x0, 0x0, 0x6, 0x9, 0x9, 0x6, 0x0 },
   { 0x0, 0x0, 0x0, 0xc, 0x12, 0x12, 0xc, 0x0 }
   
};

void setup()
{
   int charBitmapSize = (sizeof(charBitmap ) / sizeof (charBitmap[0]));

  // Switch on the backlight
  pinMode ( BACKLIGHT_PIN, OUTPUT );
  digitalWrite ( BACKLIGHT_PIN, HIGH );
 
  lcd.begin(16,2);               // initialize the lcd

   for ( int i = 0; i < charBitmapSize; i++ )
   {
      lcd.createChar ( i, (uint8_t *)charBitmap[i] );
   }

  lcd.home ();                   // go home
  lcd.print("Hello, ARDUINO "); 
  lcd.setCursor ( 0, 1 );        // go to the next line
  lcd.print (" FORUM - fm   ");
  delay ( 1000 );
}

void loop()
{
   lcd.home ();
   // Do a little animation by writing to the same location
   for ( int i = 0; i < 2; i++ )
   {
      for ( int j = 0; j < 16; j++ )
      {
         lcd.print (char(random(7)));
      }
      lcd.setCursor ( 0, 1 );
   }
   delay (200);
}


From the output window (blank spaces included to show that it is the actual output):
Code: [Select]










Sketch uses 4114 bytes (12%) of program storage space. Maximum is 32256 bytes.
Global variables use 332 bytes (16%) of dynamic memory, leaving 1716 bytes for local variables. Maximum is 2048 bytes.
Title: Re: New issue with NewLiquidCrystal Library
Post by: david_prentice on Mar 21, 2018, 01:05 pm
Follow Mr Groundfungus's advice.   Install the hd44780 library.    It will detect the I2C address and wiring style automatically.   
Your customers will never have to worry about the make and model of I2C backpack.

For your own information.    Run the diagnostic on each of your 12 LCD displays.   Stick a label on each one with address and  wiring style.

There are 16 possible addresses and two common wiring styles.   That makes MANY ways to go wrong.

The common wiring styles are data bus on P0..P3 and data bus on P4..P7.
The backlight could be active-high or active-low.   The control pins could be in a different order.    You can see that the permutations get enormous.

The other advantage of hd44780 is that you have one set of class methods.    All the other
LiquidCrystal_I2C classes have incompatible API.    Your customers will not always install Malpartida's library.   They just use the first one they find.

David.
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 21, 2018, 01:22 pm
Your customers will never have to worry about the make and model of I2C backpack.

The other advantage of hd44780 is that you have one set of class methods.    All the other
LiquidCrystal_I2C classes have incompatible API.    Your customers will not always install Malpartida's library.   They just use the first one they find.
The customers use the device as programmed. They do not program it. If they do, that is their issue. But I don't think any of them are in to this sort of thing.

For your own information.    Run the diagnostic on each of your 12 LCD displays.   Stick a label on each one with address and  wiring style.
I have. I have two versions, discernible by just looking at the backpack. As for the settings, I have them noted for each.

We are straying from the OP. I'm interested to know what library update caused fmalpartida NewCrystalLibrary to now require the full constructor.
Title: Re: New issue with NewLiquidCrystal Library
Post by: groundFungus on Mar 21, 2018, 01:43 pm
Quote
NewCrystalLibrary to now require the full constructor.
If the I2C expander pin map is the default, there is a constuctor that requires only the I2C address of the I2C expander.

From LiquidCrystal_I2C.cpp:

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


// CONSTRUCTORS
// ---------------------------------------------------------------------------
LiquidCrystal_I2C::LiquidCrystal_I2C( uint8_t lcd_Addr )
{
   config(lcd_Addr, EN, RW, RS, D4, D5, D6, D7);
}


Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 21, 2018, 01:50 pm
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?
Title: Re: New issue with NewLiquidCrystal Library
Post by: david_prentice on Mar 21, 2018, 02:19 pm
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.

David.
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 21, 2018, 02:24 pm
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.
Title: Re: New issue with NewLiquidCrystal Library
Post by: david_prentice on Mar 21, 2018, 02:28 pm
I give up.   Both I and GroundFungus have explained it very clearly.
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 21, 2018, 02:36 pm
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)
Title: Re: New issue with NewLiquidCrystal Library
Post by: groundFungus on Mar 21, 2018, 03:05 pm
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?

Quote
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?
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 21, 2018, 03:19 pm
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.
Title: Re: New issue with NewLiquidCrystal Library
Post by: groundFungus on Mar 21, 2018, 03:33 pm
Well, that was my best shot.  I can see no other explanation.
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 21, 2018, 03:51 pm
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).
Title: Re: New issue with NewLiquidCrystal Library
Post by: sterretje on Mar 21, 2018, 06:07 pm
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.
Title: Re: New issue with NewLiquidCrystal Library
Post by: bperrybap on Mar 21, 2018, 08:16 pm
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 (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 (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









Title: Re: New issue with NewLiquidCrystal Library
Post by: david_prentice on Mar 22, 2018, 12:05 am
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 (https://www.ebay.co.uk/itm/New-IIC-I2C-TWI-SPI-Serial-Interface-Board-Module-For-Arduino-1602-LCD-Display/272445496968?hash=item3f6f045e88:g:i7sAAOSwTM5Ytp6I)
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.
Title: Re: New issue with NewLiquidCrystal Library
Post by: bperrybap on Mar 22, 2018, 01:09 am
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
Title: Re: New issue with NewLiquidCrystal Library
Post by: bperrybap on Mar 24, 2018, 04:53 pm
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
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 24, 2018, 11:14 pm
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:
http://arduino.cc/forum/index.php/topic,76041.0.html (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)
Title: Re: New issue with NewLiquidCrystal Library
Post by: bperrybap on Mar 25, 2018, 03:13 am
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
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 25, 2018, 04:46 am
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.
Title: Re: New issue with NewLiquidCrystal Library
Post by: bperrybap on Mar 25, 2018, 08:26 pm
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
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 25, 2018, 09:20 pm
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.
Title: Re: New issue with NewLiquidCrystal Library
Post by: bperrybap on Mar 25, 2018, 10:32 pm
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
Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 25, 2018, 11:56 pm
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.

Title: Re: New issue with NewLiquidCrystal Library
Post by: bperrybap on Mar 26, 2018, 01:26 am
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








Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 26, 2018, 02:07 am
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.
Title: Re: New issue with NewLiquidCrystal Library
Post by: bperrybap on Mar 26, 2018, 03:06 am
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









Title: Re: New issue with NewLiquidCrystal Library
Post by: adwsystems on Mar 26, 2018, 04:42 am
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.







Title: Re: A useless discussion about how a working sketch can't possibly work
Post by: cattledog on Mar 26, 2018, 05:04 am
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.

Title: Re: A useless discussion about how a working sketch can't possibly work
Post by: adwsystems on Mar 26, 2018, 11:34 am
@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.
Title: Re: A useless discussion about how a working sketch can't possibly work
Post by: bperrybap on Mar 27, 2018, 03:14 pm
Back in July of 2015, we saw an earlier verse of this same bad song: https://forum.arduino.cc/index.php?topic=336870.0 (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.
Title: Re: A useless discussion about how a working sketch can't possibly work
Post by: bperrybap on Mar 27, 2018, 04:37 pm
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 (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.


Title: Re: A useless discussion about how a working sketch can't possibly work
Post by: cattledog on Mar 27, 2018, 05:31 pm
Quote
Back in July of 2015, we saw an earlier verse of this same bad song
Yikes.

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