Go Down

Topic: Available LCDs and libraries (Read 4994 times) previous topic - next topic

adwsystems

Thank you for the response Bill.

I take it then the full constructor is lcd(addr, EN, RW, RS, D4, D5, D6, D7, BL, POL)?

The LCD Guesser is not working? It is not finding any results that work. Any thoughts?

I will take an ohm meter to the LCD module and reverse engineer the pin out per your request. Once I have confirmation of the correct constructor, I will give it another shot. I still have not reinstalled the Arduino UNO IDE LiquidCrystal library. So it is operating as you suggest and Paul alluded to.

I am not upset with the library not "working". I'm disappointed with the lack of instructions on how to use and implement the "preferred" library in addition to the less than helpful general comments that provide no direction or directions. So no that I have a little direction, I can now attempt to make some progress.

bperrybap

#31
Jul 25, 2015, 07:47 pm Last Edit: Jul 25, 2015, 07:51 pm by bperrybap
Thank you for the response Bill.

I take it then the full constructor is lcd(addr, EN, RW, RS, D4, D5, D6, D7, BL, POL)?
Yes.

And then the lcd.begin will turn on the backlight for you.
And you don't use the setBacklightpin calls. That is old stuf left over from very early versions of the library.

Quote
The LCD Guesser is not working? It is not finding any results that work. Any thoughts?
If the guesser sketch compiled and uploaded then fm's library is installed properly.
So far every case I've seen were the guesser was not working it was user error.
Did you follow the instructions that are in top of guesser sketch?
and went through all the guesses?

What happened?
- Did you see each guess on the serial monitor and nothring worked?
- Did the sketch hang?
other??

If there really is a issue in the sketch, I'd really like to know so I can update/fix it.



Quote
I am not upset with the library not "working". I'm disappointed with the lack of instructions on how to use and implement the "preferred" library in addition to the less than helpful general comments that provide no direction or directions. So no that I have a little direction, I can now attempt to make some progress.
I know what you mean.
I'm in the process of putting together a better hd44780 library package.
It will be better documented, with better examples, and will eliminate most of the issues that people are having and all of the installation issues.
I've improved the guesser sketch and it will be part of a diagnostic sketch that will be included with the library.
It also includes support for the MCP23008 which is on some of the backpacks like the adafruit backpack.
That one is tricky since if you put in the incorrect pin mappings you can potentially damage the backpack or lcd.
It isn't ready for distribution yet.

Paul__B

My only question ...

Where were you?

 :smiley-lol:

adwsystems

#33
Jul 26, 2015, 02:00 am Last Edit: Jul 26, 2015, 02:07 am by adwsystems
There are also some library interaction and conflict issues that have to be dealt with as well.

First a bit on the library conflict issues.
There are several libraries with the same name "LiquidCrystal_I2C".
The Arduino IDE uses a very crappy build methodology and this gets all tangled up when there are header file collisions and there are collisions when using these libraries.
Also, fm's library will have additional collisions because it used a hybrid approach by essentially combining multiple libraries into a single library directory and is intended to replace the original IDE LiquidCrystal library.
It was done this way to be a replacement for the IDE LiquidCrystal library and to make the install easier as it was created long before all this very recent library manager stuff.
Because of these issues, when playing with fm's library you must properly install it and that means removing any/all other traces of any other LiquidCrystal_I2C library AND the system supplied LiquidCrystal library.
But when playing any of these LiquidCrystal_I2C libraries you will have to fully remove one in order to try a different one.
If they are left in place, all kinds of weird and strange things can happen which is mostly build errors, again mostly because of the crappy build methodology used by the Arduino IDE and its "libraries".

Looks like we are going to have to make a side trip and discuss installing the library.

https://www.arduino.cc/en/guide/libraries gives three methods:
1) Manage Libraries
2) Import a .ZIP library
3) Manual Installation

(1) Doesn't work...the fmalpartida library is not listed.
(2) Doesn't work...the .zip file is not recognized as a .zip library file by the IDE
That leaves only (3). The instructions say to install it in the sketch->library folder. That is what I have been doing. Bill mentioned it should replace the LiquidCrystal library included from the IDE install. Having no instructions, I assume the method is to shutdown the IDE, navigate to the arduino program directory, delete the old and install the new? Hope that's right because it is what I did.

Just a note on installing the fmalpartida library per the manual install instructions. I have not ever received an error. The program compiles without error.

As for the I2C LCD Guesser. It finds the PCF8574 at address 0x27. But I only see one blink of the backlight per 'send' click and garbage characters on an unlit screens. It does not appear to try all combinations. Only six combinations are attempted, the most popular ones?

bperrybap

#34
Jul 26, 2015, 03:42 am Last Edit: Jul 26, 2015, 03:44 am by bperrybap
Looks like we are going to have to make a side trip and discuss installing the library.

https://www.arduino.cc/en/guide/libraries gives three methods:
1) Manage Libraries
2) Import a .ZIP library
3) Manual Installation

(1) Doesn't work...the fmalpartida library is not listed.
It doesn't have support for it. but given the way the library combines multiple libraries and needs to replace the supplied LiquidCrystal library it is unlikely it could be supported by the library manager in its current form.
And even if the files could be massaged to make it work, I doubt that team Arduino would add support for it to the library manager since it replaces their library as I'm sure they would rather it be separate/different library with a different name.

Quote
(2) Doesn't work...the .zip file is not recognized as a .zip library file by the IDE
i thought it used to work. But I don't install it that way. I either do it manually or git clone it directly into my sketchbook libraries directory so that I can track all my changes with git.
(actually I'm not using it much anymore since I'm using my hd44780 i2c library)

Quote
That leaves only (3). The instructions say to install it in the sketch->library folder. That is what I have been doing. Bill mentioned it should replace the LiquidCrystal library included from the IDE install. Having no instructions, I assume the method is to shutdown the IDE, navigate to the arduino program directory, delete the old and install the new? Hope that's right because it is what I did.
You can place it either in your sketchbook/libraries directory or replace the system supplied LiquidCrystal library. Either will work. The important thing is that to avoid any IDE build issues the library directory needs to be named "LiquidCrystal" and the orignal LiquidCrystal library directory must be removed or move away to some other place.

Quote
As for the I2C LCD Guesser. It finds the PCF8574 at address 0x27. But I only see one blink of the backlight per 'send' click and garbage characters on an unlit screens. It does not appear to try all combinations. Only six combinations are attempted, the most popular ones?
Yes it only tries 6 permutations of the wiring. (All the wirings, I've seen after looking any MANY different backpacks)
Nearly all the bapacks are using 1 of 2 wirings. There are 2 other wirings that I've seen used but they are less popular and one of those I've only seen used on fm's ElectoFun board.
As it guesses, it is unpredictable what the lcd or backlight will do with incorrect guesses.
When it is correct, you will see the constructor on the LCD and the backlight will remain on.

I'm curious as to why it is not working with your backpack.
It could be that there is an issue with the sketch or you have a wiring that I've not seen before.
From looking at the blurry photo of the backpack you posted in post #28, it appears that:
PCF8574 P5 connects to hd44780 D5
PCF8574 P6 connects to hd44780 D6
PCF8574 P7 connects to hd44780 D7
PCF8574 P2 connects to hd44780 E

And it kind of looks like (but it is very hard to tell with the blurry photo)
PCF8574 P1 connects to hd44780 R/W

While I can't see the other traces well enough to see where they go, that wiring
matches with the first two guesses which are the two most common wirings for these types of backpacks.
The only difference between those two most common wirings is the backlight control polarity.

The best thing is to simply look at the board. A good visual check can verify the board wiring in just a minute or so.
If you can't see all the traces because it is soldered then use a ohm meter to resolve the wiring you can't see.
These 3 wirings are the most common and have account for all the boards I've ever seen other than fm's ElectroFun board:

Code: [Select]

// EN, RW, RS, D4, D5, D6, D7, BL, POL
  { 2,  1,  0,  4,  5,  6,  7,  3, POSITIVE }, // YwRobot/DFRobot/SainSmart
  { 2,  1,  0,  4,  5,  6,  7,  3, NEGATIVE }, // Robot Arduino LCM1602/2004
  { 4,  5,  6,  0,  1,  2,  3,  7, NEGATIVE }, // MJKDZ board


However, I really want to know why it is not working on your board.
There have only been 3 other cases where it wasn't working for people and in each of those 3 times, the person disappeared without resolving the "problem" and I never heard back from them.
So I have no idea if there is really an issue or whether they finally got it working an just didn't want to come back and report their final solution.
In a couple of cases there were serial issues on the mac which caused the guesser to lock up.
That is not to say the guesser doesn't have an issue, it is just that so far, I've not been able to confirm a case where the guesser didn't work.


--- bill

Paul__B

There have only been 3 other cases where it wasn't working for people and in each of those 3 times, the person disappeared without resolving the "problem" and I never heard back from them.
That says loads.

And even if the files could be massaged to make it work, I doubt that team Arduino would add support for it to the library manager since it replaces their library as I'm sure they would rather it be separate/different library with a different name.
Arrogance more to the point.  Their library should be removed and replaced with the upgraded one.  There is no reason to use the current one.

It does not appear to try all combinations.?
It cannot try all possible combinations.

Only six combinations are attempted, the most popular ones?
The only known combinations.

Working on the picture of your board.  I should have that backpack.  The question is where.


adwsystems

It cannot try all possible combinations.
The only known combinations.
It could try all of the combinations. Very easily. But I would not want to sit through it.

Based on my ohm meter, the wiring corresponds to the YwRobot/DFRobot/SainSmart version. With the full descriptor in my program it is working. Still not sure about the I2CLCDGuesser.

bperrybap




It could try all of the combinations. Very easily. But I would not want to sit through it.
:)

Quote
Based on my ohm meter, the wiring corresponds to the YwRobot/DFRobot/SainSmart version. With the full descriptor in my program it is working. Still not sure about the I2CLCDGuesser.
Ok. So there appears to be some sort of issue either in the guesser sketch or how it is being used.
I'd really like to resolve it.
The YwRobot/DFRobot/SainSmart wiring is the very fist guess that the guesser does so I'm not sure why it isn't working for your environment.
Can you hang around long enough to resolve the issue?

Can you provide more information as to your environment and what is happening and what you are seeing on the serial port vs the LCD as you use the IDE serial port monitor to talk to the guesser and step between each guess?

I'd also like to know:
- host operating system
- IDE version


--- bill



Paul,
In terms of replacing the IDE supplied LiquidCrystal library with fm's library, I actually wouldn't be in favor of that.
In order to replace the LiquidCrystal library with something new/better, it really needs to pretty much "just work" for all the environments.
While there are some great improvements in fm's library over the stock LiquidCrystal library, there are some actual issues with the current code and library structure that crop up in certain h/w and s/w environments.
(including build/compile/link issues)
Also, given the way the IDE works, you end up with dead code in your build.
For example, you can end up with I2C/Wire code in your sketch when you are not using i2c.
This has to do with an interaction between the IDE's dumb build methodology, the wire code, some of the low level arduino core code and AVR macros for handling interrupts, and fm's library code.

Looking forward, I'd rather see a new/different set of multiple and separate/independent arduino libraries that are layered rather than the current design implementation  in fm's library package.
A base hd44780 lcd library and then i/o interface libraries that sit on top of that that depend on that base library.
This keeps everything very clean and you will never get any unused code in your build.
While fm's library is close to that type of architecture model, that is not where it is today.

The hd44780 library package that I'm working on, will use this model so it will not have library collision issues with any other libraries and should be easier to install.

The real problem with libraries and in particular layered libraries is in the IDE itself. Very early on, the Arduino team decided to pick a build methodology that didn't use REAL libraries and didn't use a clean location structure for "library" directories.
i.e. headers should have been specified as #include <libdirectoryname/libheader.h> instead of just as <libheader.h>
so that the sketch explicitly specifies the desired library by specifying its directory rather than expecting the IDE to magically locate the library by having to scan all the directories looking for the header file.
Because of that implementation decision as well as a few others, it is impossible for the IDE to determine sub library dependencies and because of not using REAL libraries, the linker can't be used to find them. And that is what makes doing sub libraries a mess.
The truly sad part is that what they have implemented is much more complicated, bigger, slower, and more effort to maintain with lots of subtle collision and and linking issues than having done it the "normal" way of handling header files.

They are a victim of their own ignorance and inexperience.

--- bill


adwsystems

Can you hang around long enough to resolve the issue?

Can you provide more information as to your environment and what is happening and what you are seeing on the serial port vs the LCD as you use the IDE serial port monitor to talk to the guesser and step between each guess?

I'd also like to know:
- host operating system
- IDE version


--- bill

Windows 7 64 bit

Arduino 1.6.0

Serial Port Output:

i2cLCDguesser v1.4.1
 - Guess constructor for i2c LCD backpack
----------------------------------------------------------------
NOTE/WARNING: Guessing the i2c constructor is not really a
good thing since it could damage the hardware. Use with caution!
Do not leave things with an incorrect guess for too long.
i.e. advance to the next guess as soon as possible
when the guess in incorrect.
If the guess is correct, the constructor will show up
on the LCD.
----------------------------------------------------------------

<Press <ENTER> or click [Send] to Continue>
Scanning i2c bus for devices..
i2c device found at address 0x27
Device found: PCF8574
<Press <ENTER> or click [Send] to start guessing>
Trying: lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE)
<Press <ENTER> or click [Send] to Continue>
Trying: lcd(0x27, 2, 1, 0, 4, 5, 6, 7, 3, NEGATIVE)
<Press <ENTER> or click [Send] to Continue>
Trying: lcd(0x27, 4, 5, 6, 0, 1, 2, 3, 7, NEGATIVE)
<Press <ENTER> or click [Send] to Continue>
Trying: lcd(0x27, 6, 5, 4, 0, 1, 2, 3, 7, NEGATIVE)
<Press <ENTER> or click [Send] to Continue>
Trying: lcd(0x27, 6, 5, 4, 0, 1, 2, 3, 7, POSITIVE)
<Press <ENTER> or click [Send] to Continue>
Trying: lcd(0x27, 4, 5, 6, 0, 1, 2, 3, 7, POSITIVE)
<Press <ENTER> or click [Send] to Continue>


LCD Response:

For the first two, I get a few blinks of the backlight and all the lcd dots light on the entire display. No funky text, just all dots/pixels illuminated. For the others, I get some quick blinks and some funny things written on a dark screen.


bperrybap

Interesting.

And the constructor parameters:
0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE
works properly in your sketch to display text and provide back light control?

Which Arduino board are you using and what geometry LCD are you using? (16x2, 20x4 etc...)


Do you power everything off before starting the guessing?
A power cycle for the LCD is important as there is no other way to reset the lcd.
It is possible that if the LCD gets into a confused state it won't properly respond even when the signals are correct.

I am assuming you are pushing/clicking the <enter>/[send] button to advance guesses?
and pausing after each?

What do you mean by:
Quote
For the first two, I get a few blinks of the backlight and all the lcd dots light on the entire display. No funky text, just all dots/pixels illuminated
How many blinks and for how long?
(The guesser tries to do 3 blinks of 1/4 second each)

Does the backlight stay on after the first guess? which is:
0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE
(It should turn on the backlight if that constructor works in your sketch)

Are you seeing any text on the LCD after the first guess?

and what does "all the lcd dots light on the entire display" mean?
As in all dots in each 5x8 character for all the character positions on the lcd display?
That sounds like a contrast issue.
Have you ever seen any text on that display?
i.e. is the contrast pot incorrectly adjusted?


Would it be possible to take a video of fist two guesses?

--- bill

adwsystems

Interesting.

And the constructor parameters:
0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE
works properly in your sketch to display text and provide back light control?

Yes, but backlight control is relative, I do not toggle the backlight (the old library did not provide that functionality and I don't (think I) need it.

Which Arduino board are you using and what geometry LCD are you using? (16x2, 20x4 etc...)
16x2

Do you power everything off before starting the guessing?
A power cycle for the LCD is important as there is no other way to reset the lcd.
It is possible that if the LCD gets into a confused state it won't properly respond even when the signals are correct.

I am assuming you are pushing/clicking the <enter>/[send] button to advance guesses?
and pausing after each?
I have not been power cycling. Just download, reset, and go.

I am clicking the send button and waiting for the lcd to stop doing whatever it was doing.

What do you mean by:
How many blinks and for how long?
(The guesser tries to do 3 blinks of 1/4 second each)
Maybe three blinks, but definitely not 1/4 sec each. Blinks are so quick I can't really count.

Does the backlight stay on after the first guess? which is:
0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE
(It should turn on the backlight if that constructor works in your sketch)
Yes backlight stays on.

Are you seeing any text on the LCD after the first guess?

and what does "all the lcd dots light on the entire display" mean?
As in all dots in each 5x8 character for all the character positions on the lcd display?
That sounds like a contrast issue.
Have you ever seen any text on that display?
i.e. is the contrast pot incorrectly adjusted?
No text. All dots in all positions. I too would think it would be a contrast issue except (a) the funky text I can see without the backlight in some of the other guesses and (b) it works (worked) with the old library and does work with my sketch.

Would it be possible to take a video of first two guesses?
Sorry. I don't have anything that videos to the computer.

Any chance the library and guesser I have are corrupt? Bad sketches?

bperrybap

#41
Jul 27, 2015, 01:08 am Last Edit: Jul 27, 2015, 01:11 am by bperrybap
Just to verify the setup.
I just downloaded Arduino 1.6.0 and fm's v1.2.1 library from his bitbucket site
https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads
, and the guesser sketch linked to in this thread.
To make that all that work with 1.6.0 all that is necessary is to unzip the LiquidCrystal library directory (not the MACios directory turd) from fm's zip v1.2.1 zip file into your sketchbook/libraries directory.
Make sure the directory for fm's library is named LiquidCrystal - which it should be after extracting from the zip image. The IDE will allow this library to override the system supplied directory.
You can still remove the IDE supplied one, but it is not necessary in this case with more recent IDEs  like 1.6.0
BTW, you may want to look at a newer IDE since there have been some really useful updates and bug fixes to the IDE since 1.6.0

I tested the guesser sketch on 4 different backpacks including one that uses the same wiring you said was on your backpack.


Just to confirm what you are seeing:
you are saying that after the guesser fails work, you can immediately upload your own sketch using a
LiquidCrystal_I2C(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE) constructor with these exact parameters and it works?
No power off?

The reason I ask is that a power cycle is the only way to reset the LCD. If the LCD module is off in NeverNeverLand then it tends to remain that way until it is power cycled.
A power cycle before doing the guesses is the most reliable method to ensure that the LCD starts in a known state.

The blinks the guesser uses should be 250ms (1/4 second) each as it uses delay(250) to pause between backlight state transitions.
The backlight control is separate from the LCD initialization and should work even if the LCD is not working.
When the backlight pin and polarity is correct in the constructor, you will see 3 very distinct blinks by the guesser sketch and then the backlight will remain on.
You may want to look at only the backlight or side of the LCD where the backlight protrudes to see the actual backlight vs look directly at the front of the LCD as seeing the backlight can sometimes be difficult on reverse pixel displays like the one you have.

The very first guess the guesser sketch does is using the wiring that you said your backpack uses, so
If the backlight blinking is not working for that very first guess then something very basic is not working correctly as the backlight h/w and control is completely separate from the LCD control so it takes very little in terms of s/w configuration and setup to maket the backlight work.

What Arduino are you using and what clock rate is it running?

--- bill




adwsystems

Just to verify the setup.
I just downloaded Arduino 1.6.0 and fm's v1.2.1 library from his bitbucket site
https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads
, and the guesser sketch linked to in this thread.
To make that all that work with 1.6.0 all that is necessary is to unzip the LiquidCrystal library directory (not the MACios directory turd) from fm's zip v1.2.1 zip file into your sketchbook/libraries directory.
Make sure the directory for fm's library is named LiquidCrystal - which it should be after extracting from the zip image. The IDE will allow this library to override the system supplied directory.
You can still remove the IDE supplied one, but it is not necessary in this case with more recent IDEs  like 1.6.0
That was the source for the library per my browser history. Since I was afraid of a collision in the file names, was not as knowledgeable about the issues with fm's library, and most of all was replacing the previous LCD I2C libary, the directory was called LiquidCrystal_I2C.

The guesser sketch link a few posts back is the correct one? I downloaded the sketch from the most recent post with the link in this thread.

BTW, you may want to look at a newer IDE since there have been some really useful updates and bug fixes to the IDE since 1.6.0
Will do, but let's not change too many variables at once.

I tested the guesser sketch on 4 different backpacks including one that uses the same wiring you said was on your backpack.


Just to confirm what you are seeing:
you are saying that after the guesser fails work, you can immediately upload your own sketch using a
LiquidCrystal_I2C(0x27, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE) constructor with these exact parameters and it works?
No power off?

The reason I ask is that a power cycle is the only way to reset the LCD. If the LCD module is off in NeverNeverLand then it tends to remain that way until it is power cycled.
That is 100% correct.

A power cycle before doing the guesses is the most reliable method to ensure that the LCD starts in a known state.

The blinks the guesser uses should be 250ms (1/4 second) each as it uses delay(250) to pause between backlight state transitions.
The backlight control is separate from the LCD initialization and should work even if the LCD is not working.
When the backlight pin and polarity is correct in the constructor, you will see 3 very distinct blinks by the guesser sketch and then the backlight will remain on.
You may want to look at only the backlight or side of the LCD where the backlight protrudes to see the actual backlight vs look directly at the front of the LCD as seeing the backlight can sometimes be difficult on reverse pixel displays like the one you have.

The very first guess the guesser sketch does is using the wiring that you said your backpack uses, so
If the backlight blinking is not working for that very first guess then something very basic is not working correctly as the backlight h/w and control is completely separate from the LCD control so it takes very little in terms of s/w configuration and setup to maket the backlight work.

What Arduino are you using and what clock rate is it running?

--- bill
I have noticed if I plug the LCD after power on and start up, then I must reset the Arduino/program/sketch (whatever you want to call it).

The unit is an Arduino Uno and genuine as far as I can tell. (I ended up with a counterfeit one, but am not using it especially for debugging). The crystal says 16.000, I'm assuming MHz.

I'm thinking the problem is on my end. Since all my data seems to match yours, it would be the logical conclusion.

I opted to go the Arduino route because I did not have the ambition to develop all the low level drivers the Arduino appeared to have already. I have spent too much time in my life doing that, but at least I was being paid for it. I have several development partnership projects in the works. This is one. The only thing I get is experience until they hit the market.

bperrybap

That was the source for the library per my browser history. Since I was afraid of a collision in the file names, was not as knowledgeable about the issues with fm's library, and most of all was replacing the previous LCD I2C libary, the directory was called LiquidCrystal_I2C.

The guesser sketch link a few posts back is the correct one? I downloaded the sketch from the most recent post with the link in this thread.
That is the latest one that I've published and that is the one I used.


Quote
I have noticed if I plug the LCD after power on and start up, then I must reset the Arduino/program/sketch (whatever you want to call it).
How are you plugging in the LCD? Are you removing/attaching the 4 pin i2c cable while the Arduino is powered?
It could be creating a power glitch on the Arduino board.
I do yank/attach the 4 pin cable when using the sketch, but I reset the Arduino when I do it because not all my backpacks use the same i2c address so I just push the reset button on the board to start the sketch clean so the sketch can probe for the i2c address.

Quote
The unit is an Arduino Uno and genuine as far as I can tell. (I ended up with a counterfeit one, but am not using it especially for debugging). The crystal says 16.000, I'm assuming MHz.
good enough. I was mainly wanting to know which microcontroller it was.
AVR 328, 1284, ARM, etc...

Quote
I'm thinking the problem is on my end. Since all my data seems to match yours, it would be the logical conclusion.
Hard to say for sure. There are some other differences between what the guesser does and what the normal library does in terms of handling of the PCF8574 from powerup (guesser does some probing first).
Also, your i2c chip may be different than the ones on my backpacks.
It could be that the probing I'm doing to detect the PCF8574 is freaking out the LCD chip or getting it out of sync with how the library is initializing things.
It shouldn't matter as a proper initialization sequence should clear up everything no matter what state the LCD and PCF8574 is in but perhaps there is an issue there for some LCD modules.

At this point, I'm not sure what the issue is, but I'd sure like to track it down as it could be an issue that might eventually show up in the library.

One thing that would be nice to know is if the R/W signal on the LCD is wired up to P1 on the PCF8574 or whether it is just grounded. Some backpacks ground it, and others wire R/W to a PCF8574 i/o pin.
Did you verify where LCD R/W pin goes?

In the mean time, I'm going to have a look at the library code and take a close look at the initialization code of the 8574 output port and LCD to see if I see anything.

--- bill

bperrybap

So there is a piece of code that is incorrect in the LiquidCrystal_I2c code.
I fixed this long ago so I'm not sure why it is still there in the latest code.

In the module LiquidCrystal_I2C.cpp
look for this:
Code: [Select]
// setBacklightPin
void LiquidCrystal_I2C::setBacklightPin ( uint8_t value, t_backlighPol pol = POSITIVE )
{
   _backlightPinMask = ( 1 << value );
   _polarity = pol;
   setBacklight(BACKLIGHT_OFF);
}


And change it to this:
Code: [Select]
// setBacklightPin
void LiquidCrystal_I2C::setBacklightPin ( uint8_t value, t_backlighPol pol = POSITIVE )
{
   _backlightPinMask = ( 1 << value );
   _polarity = pol;
}


(remove the setBacklight() call.)

I'm not sure how the code is working with that there. In the older versions of the IDE that would hang because it was making i/o calls before other parts of the code and Wire h/w were initialized.
That call is not necessary anyway.
Not sure how that could cause the issue we are seeing but it needs to be fixed anyway.

--- bill

Go Up