I2C library conflict?

I am working on a project Arduino UNO (Genuine), nrf24l01+, I2C eeprom and parallel LCD, for exporting data I use Serial.print() and a Sparkfun OpenLog logger so I can either use the Terminal or the logger. This behaved very well for two years.

#include <Wire.h>
#include <EEPROM.h>
#include <LiquidCrystal.h>
#include <RF24Network.h>
#include <RF24.h>
#include <SPI.h>

Everything worked fine until I ran out of pins and decided to add an I2C backpack to my LCD. Now I use:

#include <Wire.h>
#include <EEPROM.h>
#include <LiquidCrystal_I2C.h>
#include <RF24Network.h>
#include <RF24.h>
#include <SPI.h>

Then two weird things started to occur.

  1. The serial.println(); function gets ignored (sometimes, cannot find when it does or does not), so all data comes out in one line, correct numbers but difficult to read.
  2. The eeprom value of one of my parameters gets lost after usage, by re-reading from EEPROM before I need the value in a calculation or showing the value on the lcd this can be compensated.

Working with a Genuine UNO I do not expect a hardware failure but start to doubt. Can this be the case?
My sketch uses 50% of storage and 70% of dynamic memory
I am using Arduino 1.8.7 (Windows Store 1.8.15.0)

Which I2C LiquidCrystal library? (post link)

You will also need to post an wiring diagram so we can see what pins you are using. There are multiple places the I2C lines come out and you may be "doubling up" and have something connected to one or both of them (this was a problem one poster had just last week).

I2C Library Frank de Brabander v 1.1.2

I2C wiring, SDA, SCL straight to I2C backpack of the display.

Display shows correct numbers and text except for the value that is read from (Internal) EEPROM.

Display shows correct numbers from I2C EEPROM and calculations made with these numbers.

Every time the value that is read from the (Internal) EEPROM is used it loses its value and changes to 100 or 255, I repaired this by a value = EEPROM.read(adress); on every occasion where I need it.

int value can be 1, 2 or 3

Big problem is why Serial.println(); is ignored

erikjanssen:
Every time the value that is read from the (Internal) EEPROM is used it loses its value and changes to 100 or 255, I repaired this by a value = EEPROM.read(adress); on every occasion where I need it.

That does not make sense. Every time would include the repair case.

If you don't post your code nobody can really help you.

erikjanssen:
I2C Library Frank de Brabander v 1.1.2

I2C wiring, SDA, SCL straight to I2C backpack of the display.

Only two wires in your system? I thought you were out of pins?

erikjanssen:
Display shows correct numbers and text except for the value that is read from (Internal) EEPROM.

Display shows correct numbers from I2C EEPROM and calculations made with these numbers.

Every time the value that is read from the (Internal) EEPROM is used it loses its value and changes to 100 or 255, I repaired this by a value = EEPROM.read(adress); on every occasion where I need it.

What EEPROM? I don't see and code for reading from an EEPROM?

erikjanssen:
int value can be 1, 2 or 3

Big problem is why Serial.println(); is ignored

I don't see and code printing to the serial port?

Seeing the program and the complete wiring diagram, the assumption is you either have a wiring error or a programming mistake.

The Frank de Brabander library was one of the better ones but it requires modifying the IDE installation to make it work. The better library is the hd44780. It will take a little reprogramming, but is currently supported here and the installation follows standard Arduino IDE methods.

You may have too many pullup resistors on the I2C lines after adding the last module. Find the schematics for each module (shield) and calculate the parallel resistance from the resistor values shown.

If one of your I2C devices requires low-speed then maybe the new library has forced all I2C comms into high-speed mode. Very few libraries "play nice" with this because it is rare to find any slow-only devices.

I deleted the I2C library and replaced it with the hd44780 library, the I2C LCD performs well but the Serial.println(); is still ignored

When removing the I2C LCD from my sketch and returning to the parallel LCD the Serial.println(); is good again

I have to postpone further investigation, thanks for the suggestions this gives me some ideas where to look into.

In my sketch I use large numbers which I write to EEPROM with:

void EEPROMWritelong(int address, long value)
{
//Decomposition from a long to 4 bytes by using bitshift.
//One = Most significant → Four = Least significant byte
byte four = (value & 0xFF);
byte three = ((value >> 8) & 0xFF);
byte two = ((value >> 16) & 0xFF);
byte one = ((value >> 24) & 0xFF);

//Write the 4 bytes into the eeprom memory.
EEPROM.write(address, four);
EEPROM.write(address + 1, three);
EEPROM.write(address + 2, two);
EEPROM.write(address + 3, one);
}

//This function will return a 4 byte (32bit) long from the eeprom
//at the specified address to address + 3.
long EEPROMReadlong(int address)
{
//Read the 4 bytes from the eeprom memory.
long four = EEPROM.read(address);
long three = EEPROM.read(address + 1);
long two = EEPROM.read(address + 2);
long one = EEPROM.read(address + 3);

//Return the recomposed long by using bitshift.
return ((four << 0) & 0xFF) + ((three << 8) & 0xFFFF) + ((two << 16) & 0xFFFFFF) + ((one << 24) & 0xFFFFFFFF);
}

In my sketch I use number = EEPROMReadlong(location);

The error found is the definition of number:
unsigned long int number; // gives unexpected behaviour of println and maintaining values read from EEPROM
long number; //makes everything work as designed

I cannot explain why but all my displays and serial output work now correctly

long and unsigned long may have the same size, but they mean different values. Explains any unexpected value of 0 or 255. Your bits were not where you want them per value.

NTM, I always get random bugs if I mixing variable types without converting them.