Help on issue related to LCD, I/O Expander, and hd44780 library

I installed the library using the library manager in the Arduino IDE and have not found a built-in example that will compile.

Anyone have a link to a help file or documentation for the hd44780 library?

Check that. I finally found one that will compile and work. Documentation or help file would be useful, if available.

Is this the library? https://github.com/duinoWitchery/hd44780

Simple Google search found this.

marco_c:
Is this the library? https://github.com/duinoWitchery/hd44780

Since I did not download it but instead installed it through the Arduino IDE Library Manager, I don't know, but doubt it.

Yes, that is the one. If you check in Library Manager there is a “More info” link that leads to that repository. You can find some documentation on the home page of the repository and it looks like there is more in the wiki:

While we're at it. Why causes the LCD address auto detect to fail? How do I force the address and pin settings?

I have the LCD (0x27), RTC (0x68), two PCF8575 I/O expanders (0x22 and 0x23) and , and ADS1115 (0x48) connected.

It looks like it is something to do with the PCF8575 I/O expanders.

I had the same problem. I have a MCP23008 at 0x20 and an LCD (PCF 8574) at 0x27. The auto detect would find the MCP because it is first, address wise. The solution is to specify the address of the LCD in the begin function.

Sorry in the constructor.

hd44780_I2Cexp lcd(0x27);

Makes sense. I changed hd44780_I2Cexp lcd; to hd44780_I2Cexp lcd(0x27); but the display still doesn't work (can't read characters as the backlight isn't turning on).

In the examples in the \hd44780\examples\ioClass\hd44780_I2Cexp\I2CexpDiag folder is a diagnostic program that may help (also available in the File, Examples menu).

groundFungus:
In the examples in the \hd44780\examples\ioClass\hd44780_I2Cexp\I2CexpDiag folder is a diagnostic program that may help (also available in the File, Examples menu).

I'm not sure how to force it to detect the LCD at 0x27.

Here;s the output:

********************************************************************
Serial Initialized
--------------------------------------------------------------------
I2CexpDiag - i2c LCD i/o expander backpack diagnostic tool
--------------------------------------------------------------------
hd44780 lib version: 0.9.3
--------------------------------------------------------------------
Reported Arduino Revision: 1.8.5
CPU ARCH: AVR - F_CPU: 16000000
--------------------------------------------------------------------
 A4: digital pin: 18
 A5: digital pin: 19
SDA: digital pin: 18
SCL: digital pin: 19
--------------------------------------------------------------------
Checking for required external I2C pull-up on SDA - YES
Checking for required external I2C pull-up on SCL - YES
--------------------------------------------------------------------
Scanning i2c bus for devices..
 i2c device found at address 0x22
 i2c device found at address 0x27
 i2c device found at address 0x68
Total I2C devices found: 3
--------------------------------------------------------------------
Scanning i2c bus for all lcd displays
No working LCD devices

adwsystems:
While we're at it. Why causes the LCD address auto detect to fail? How do I force the address and pin settings?

I have the LCD (0x27), RTC (0x68), two PCF8575 I/O expanders (0x22 and 0x23) and , and ADS1115 (0x48) connected.

It looks like it is something to do with the PCF8575 I/O expanders.

When trying to bring up new h/w and s/w you typically want to use the simplest environment possible rather than a more complex one. i.e. I'd recommend hooking up just the i2c backpack lcd(s) to make sure the h/w and library are properly talking before jumping to a more complex environment with additional devices on the i2c bus.

In terms of what is happening, the auto locate code is relatively simplistic.
The auto locate i2c address code will look at all possible addresses for the PCF8574 which is 0x20-0x27 and 0x38-0x3f to try to locate the device - in that order.
In your case you have other i2c devices that are inside the PCF8574 address range.
The diag sketch simply calls the library to try to initialize an LCD device. It assumes that if the library fails to initialize a device there are no more devices to be found. In this case, the initialization is failing at address 0x20 and the way the library code is currently written, it will not skip over the i2c address of a failed initialization when trying to auto locate a device or devices.
The diagnostic tool did not take into consideration that there would be other devices that used i2c addresses in the middle of the PCF8574 address range and more specifically using an address inside the range that is lower than the lowest i2c address of the i2c backpack(s).

The diag tool cannot be used in your full environment. It will fail as you have seen because the address of the PCF8575 devices are lower than the PCF8574 backpack.
But it would work if you only hooked up the backpack.

Currently there is some code in the auto locate library code that attempts to identify a device found inside the range is actually a PCF8574 or a MCP23008 and skip that address if it is not either of those, but it is currently disabled.
However, from a quick read of the PCF8575 datasheet, it is not clear that the current chip identify code would be able to correctly rule out a PCF8575 chip. Also, the current code talks (writes) to the slave using single bytes during this identification which the PCF8575 sheet says should not be done, it may nak the request (but the code currently doesn't check to see if the write failed).
I don't have a PCF8575 so I can't test to see how it behaves to see if the code could be smarter to skip over those chips.
You could try enabling the extra identify code in h444780_I2Cexp.h at lines 716 and 742 but I don't think it will solve the issue.

In the bigger picture you seem to be doing some leaping before looking.
I'd recommend spending a bit more time reading and reviewing what people are writing as some of the questions/issues you are having have been answered.
In particular how to specify the i2c address of the lcd backpack in the constructor, which is all you should need to do as once the library has the i2c address for the lcd object it should be able to auto detect the pin mappings and the backlight active level.
Using this mode would allow you to set all the i2c address of the LCD backpacks to be the same and not have to worry about the specific pin mappings used on the backpack.

If you still want to see how to manually specify everything, have a look at the hd44780_I2Cexp.h header file.
There is quite a bit of information in the comments including all the constructor parameters to manually configure the device.
A word of caution, in that there is a possibility that the constructors for low level manual configuration may change.
I don't forsee any changes to the fully manual constructor (with 11 parameters), however I would discourage using the pre-canned board types at this point in time as those may change or go away in the future.

--- bill

bperrybap:
When trying to bring up new h/w and s/w you typically want to use the simplest environment possible rather than a more complex one. i.e. I'd recommend hooking up just the i2c backpack lcd(s) to make sure the h/w and library are properly talking before jumping to a more complex environment with additional devices on the i2c bus.

That's what I had done. I edited the first post several prior to the first reply as I made progress. I can get the LCD to work with the new library, until I add the PCF8575 boards. Then I add the address to the LCD constructor but the display still fails to work, not even the backlight comes on. I am unsure why the auto detect works until I add the PCF8575 boards. The PCF8575 boards are working fine with and without the LCD attached. That makes me think it is not an address conflict or bus issue.

adwsystems:
That's what I had done. I edited the first post several prior to the first reply as I made progress. I can get the LCD to work with the new library, until I add the PCF8575 boards. Then I add the address to the LCD constructor but the display still fails to work, not even the backlight comes on. I am unsure why the auto detect works until I add the PCF8575 boards. The PCF8575 boards are working fine with and without the LCD attached. That makes me think it is not an address conflict or bus issue.

That is not what you said in your previous posts.
In post #6 you said that when forcing the i2c address to 0x27 the backlight was not working.
In post #8 you showed that there were issues when used in your full system with other devices on the bus.
Nowhere did you ever say that the LCD was actually working correctly including the backlight under certain conditions.
And nowhere ever did you say you used the simplest environment and hooked up only the LCD and ran the diag sketch.

You are now are saying that you have used the simplest environment and run the diag sketch with only the LCD device attached and everything works correctly including the backlight.
You are also saying that the LCD works correctly when the PCF8575 devices are not attached.
And you are also saying that if you specify the i2c address of the LCD device with PCF8575 chips hooked to the bus the LCD fails to work.

That isn't possible given the way the library code is written.

In post #9 I explained how and why it fails when using auto location and the PCF8575 devices are attached.
If you specify the i2c address, auto location is not used and the library will only use the specified i2c address.
The auto configuration code is exactly the same regardless of whether auto location is used or not.
So whether you specify the i2c address or not, the final configuration determined by the library will be same.

At this point I'm assuming you must be doing something different than what you saying or are not doing something that you are saying you are doing or there is some kind of hardware issue.

The examples provide several forms of diagnostics, including a blinking led status when things are not working.
Have you read the information in the sketches about this?

--- bill

bperrybap:
That is not what you said in your previous posts.
In post #6 you said that when forcing the i2c address to 0x27 the backlight was not working.
In post #8 you showed that there were issues when used in your full system with other devices on the bus.
Nowhere did you ever say that the LCD was actually working correctly including the backlight under certain conditions.
And nowhere ever did you say you used the simplest environment and hooked up only the LCD and ran the diag sketch.

I'm sorry I did not detail the setup during the several modifications of post #1 that concluded

adwsystems:
Check that. I finally found one that will compile and work. Documentation or help file would be useful, if available.

There's a difference between compile and work.

bperrybap:
You are now are saying that you have used the simplest environment and run the diag sketch with only the LCD device attached and everything works correctly including the backlight.
You are also saying that the LCD works correctly when the PCF8575 devices are not attached.
And you are also saying that if you specify the i2c address of the LCD device with PCF8575 chips hooked to the bus the LCD fails to work.

That isn't possible given the way the library code is written.

In post #9 I explained how and why it fails when using auto location and the PCF8575 devices are attached.
If you specify the i2c address, auto location is not used and the library will only use the specified i2c address.
The auto configuration code is exactly the same regardless of whether auto location is used or not.
So whether you specify the i2c address or not, the final configuration determined by the library will be same.

Yes on all that.

bperrybap:
At this point I'm assuming you must be doing something different than what you saying or are not doing something that you are saying you are doing or there is some kind of hardware issue.

If I am doing something different then it is unintentional and subconscious. All but on of the boards have pass through connections for the I2C bus, so connecting them is a matter of connecting a 4 pin cable/connector (the ADS1115 has no pass through feature and a funny 4-2x2 Y connector cable).

bperrybap:
The examples provide several forms of diagnostics, including a blinking led status when things are not working.
Have you read the information in the sketches about this?

I have, but have not noticed anything enlightening regarding this situation. Do you have any suggestions to narrow down the search?

I was interested in setting the LCD in the DIAG sketch but have not enough time to reverse engineer it in order to hardcode or parameterize the LCD address to get it to continue beyond the output listed in post #8.

Also keep in mind this 'network' of devices had been working. It was in development, but I was able to read and write to all of the devices as appropriate. Since that point, two items have changed. The library has been switched for the LCD and the compiler updated from 1.8.4 to 1.8.5.

Details matter and accurate details are critical to solve issues.
You posts are not making any sense to me as they are saying many conflicting things and are claiming things that are not possible.

You say you updated your #1 post as you progressed.
However, the last update to post #1 is 2018-03-21, 16:48:21 but yet post #6 is 2018-03-21, 17:19:41 which after the most recent update to post #1

You said "There's a difference between compile and work." which is absolutely true.
Post #1 says " finally found one that will compile and work"
work means well it works, which means you can see all the characters on the LCD display and the backlight is lit.
But yet your post #6 says it still isn't working.

And while in post #12 you seem to be re-iterating that you ran the diagnostic sketch with only a LCD device hooked up and it work, but yet when using fixed i2c address it doesn't work.
That is not possible.

You also state:

I was interested in setting the LCD in the DIAG sketch but have not enough time to reverse engineer it in order to hardcode or parameterize the LCD address to get it to continue beyond the output listed in post #8.

But there is no need to reverse anything or do any modifications to the diag sketch, since you previously said and reconfirmed in post #12 that the LCD is working correctly when only the LCD device is hooked up.

And in post #9 I spent quite a bit of time to explain to you why the library auto locate capability will not work with the PCF8575 devices attached. So there is no need to modify the diagnostic sketch, as there is nothing new to learn as you already know that the LCD device is working, and the hd44780 library is working, and why the hd44780 library cannot do auto location when the PCF8575 devices attached.

At this point, I simply do not believe you. You are saying you have done certain things and that certain combinations things are happening that are simply not possible.
And the information in your posts do not support the combination of things that you say you are doing and are happening.

--- bill

bperrybap:
You say you updated your #1 post as you progressed

“prior to the first reply.” (post #10) Most participants do not like adding details to previous posts once the conversation has started. I saw no problem with updating the first and only post 3 or 4 times prior to the first reply.

bperrybap:
Post #1 says " finally found one that will compile and work"
work means well it works, which means you can see all the characters on the LCD display and the backlight is lit.
But yet your post #6 says it still isn’t working.

Still not working between post #4 and #6. Not between posts #1 where I said it [the LCD and sketch] was working and #6 where the"display still doesn’t work".

bperrybap:
And while in post #12 you seem to be re-iterating that you ran the diagnostic sketch with only a LCD device hooked up and it work, but yet when using fixed i2c address it doesn’t work.

This is a little vague to me. Please allow me to try to clarify.
I ran the diagnostic sketch with only the LCD and it worked.
I did not, cannot (?), do not know how to, run the diagnostic with the LCD at a fixed address.

Hello World was loaded and ran in many many combinations (adding one component at a time to see what does and doesn’t work). The final notable combinations are these four:
Detect the address and only the LCD - worked
Fixed address and only the LCD - worked
Detect the address with the LCD and the PCF8575 attached - did not work, but we expect that
Fixed address and PCF8575 attached - did not work, did not expect that

bperrybap:
That is not possible.
At this point, I simply do not believe you. You are saying you have done certain things and that certain combinations things are happening that are simply not possible.

I’m sorry for that. It doesn’t behoove anyone to BS the information, it won’t get the problem solved. Believe it or not, it is what it is. I’m willing to try anything or provide any information you need to help determine the solution.

bperrybap:
And the information in your posts do not support the combination of things that you say you are doing and are happening.

The posts in this thread have been quite linear and forward progressing. post #1=LCD only, post #4=added things and broke why?, post #5=answer and how to specify address, post #6=update the address didn’t help, posts #8, #10, and #12 are just answering questions and providing information, no additional trials have been performed.

Finally, you are providing more complete, useful, and non conflicting information.
In the previous posts you left out so much information that the information you did provide was no longer consistent and didn't make sense.

adwsystems:
Please allow me to try to clarify.
I ran the diagnostic sketch with only the LCD and it worked.
I did not, cannot (?), do not know how to, run the diagnostic with the LCD at a fixed address.

The diagnostic tool is to determine if the LCD backpack and library are able to communicate.
It also does a basic test of the i2c signals to verify if the required pullup resistors are in place and a RAM test of the LCD memory.
The test has done all that it is designed to do so there is no need to modify the diagnostic tool as there is nothing new that can be learned.
The library is able to communicate properly with the LCD device and the LCD device is working properly and the required pullups are present.
As I mentioned earlier, the diagnostic tool cannot be modified to work with the PCF8575 devices attached since it depends on the library auto location capability and auto location doesn't work when there are other i2c devices within the PCF8574 address range.

Hello World was loaded and ran in many many combinations (adding one component at a time to see what does and doesn't work). The final notable combinations are these four:
Detect the address and only the LCD - worked
Fixed address and only the LCD - worked
Detect the address with the LCD and the PCF8575 attached - did not work, but we expect that
Fixed address and PCF8575 attached - did not work, did not expect that

Finally a description of what you have done that makes sense.

That last case should work as long as there are no i2c address issues.
i.e the PCF8574 and PCF8575 address pins are fully strapped (not left disconnected) either high or low for non conflicting addresses.

I'm assuming that last case is a single I2c LCD backpack and a single PCF8575 attached to the bus.
What address is the LCD backpack using and what address is the PCF8575 using
and what code are you using to test this?
And what status are you getting from lcd.begin() ?
No mention of any blink status. If you are using a provided example and modified it for your i2c backpack address
and the begin() fails, it will return a non zero status and the example will blink the error status on the builtin LED.

--- bill

bperrybap:
Finally a description of what you have done that makes sense.

That last case should work as long as there are no i2c address issues.
i.e the PCF8574 and PCF8575 address pins are fully strapped (not left disconnected) either high or low for non conflicting addresses.

I'm assuming that last case is a single I2c LCD backpack and a single PCF8575 attached to the bus.
What address is the LCD backpack using and what address is the PCF8575 using
and what code are you using to test this?
And what status are you getting from lcd.begin() ?
No mention of any blink status. If you are using a provided example and modified it for your i2c backpack address
and the begin() fails, it will return a non zero status and the example will blink the error status on the builtin LED.

Not finally but all in one place.

As mentioned, it doesn't matter if the RTC and ADC are attached. The Hello World sketch directly from the hd44780 library works until a PCF8575 is attached. The address in use are as in posts #4 and #8. LCD (0x27) and PCF8575 I/O expander (0x22 or 0x23).

I did not note the blinking of the pin 13 LED (when the RTC shield is installed the LED is not noticeable). I will reply later tonight with any code.

FWIW, the RTC shield is a genuine AdaFruit 1141.

adwsystems:
Not finally but all in one place.

Yes, the recent description of things you have provided is finally consistent and makes sense.
This is very different from the information in previous posts.
And if you are unwilling to admit that, then I'm done helping.
--- bill

And here we go again…
You are leaving out so much information and/or are providing misinformation such that the information you are providing becomes inconsistent and confusing.
Again accurate details really matter.

adwsystems:
As mentioned, it doesn’t matter if the RTC and ADC are attached.

And where was this specifically mentioned?
What specific post specifically do you believe says that it worked when the RTC and ADC are attached.
While you may have observed this, I don’t see that specific information in any any post in this thread.
All I can find is Post #4 that mentioned the RTC and ADC but it merely states addressing information and suspects the issue has something to do with the PCF8575.

And that is an example of what I’m talking about.
We can only go by what you have actually written not anything else you may have done or have observed.

The Hello World sketch directly from the hd44780 library works until a PCF8575 is attached. The address in use are as in posts #4 and #8. LCD (0x27) and PCF8575 I/O expander (0x22 or 0x23).

That is inconsistent and/or inaccurate.
Post #4 talks about LCD, RTC, two PCF8575 chips, and a ADS1115 and their addresses.
This is more than what you just stated above.
And post #8 scans the i2c bus and shows devices at 0x22 (I’m assuming PCF8575), 0x27 (assuming PCF8574), 0x68 RTC
There is no ADC showing up in the test results in post #8
So the results of the test in #8 are inconsistent with #4 and inconsistent with your recent comment above of “… works until a PCF8575 is attached” which implies that only the LCD is attached and works but then stops working when the PCF8575 is attached.

And in that most recent comment above

The Hello World sketch directly from the hd44780 library works until a PCF8575 is attached.

The HelloWorld sketch directly from the library will be using auto location.
As I explained in great detail in post #9, auto location does not work with there is another i2c device inside the i2c address range of the PCF8574.

From the information in your posts, it is not possible for me to really tell what is really being done.

We aren’t playing horseshoes here. Close isn’t good enough when it comes to these kinds of details.
Debugging these kinds of issues, requires a very methodical process and paying very close attention to details.
For me to help you, I need you to provide accurate and complete details.
I’m rapidly loosing patience - actually my patience is pretty much already gone from this thread as well as the other newLiquidCrystal thread which had similar types of issues with details, inconsistencies and things that didn’t make sense or were not possible.
Anymore obvious inconsistencies in details and I’m done helping.

— bill

bperrybap:
What specific post specifically do you believe says that it worked when the RTC and ADC are attached.
While you may have observed this, I don't see that specific information in any post in this thread.
All I can find is Post #4 that mentioned the RTC and ADC but it merely states addressing information and suspects the issue has something to do with the PCF8575.

Post #4 just as you state. I worked through adding the parts one at a time until I found the part(s) that caused the issue. My search (yes, I used google :astonished: ) revealed some issue about the PCF8575 and having to assign the address specifically, but none of the threads I read had the details on what was wrong or had to be done to correct or work around the issue. Yes I did not specifically state at that time (as I did in post #14) the components had been added and the system tested in some methodical manner. But that is how I narrowed it down to the PCF8575 being attached to cause the issue (I just don't know what the issue is or why it is caused). When one or both PCF8575 are attached, the LCD doesn't work, independent of anything else being attached. (just another wording for post #4)

Furthermore:

adwsystems:
Hello World was loaded and ran in many many combinations (adding one component at a time to see what does and doesn't work). The final notable combinations are these four:
Detect the address and only the LCD - worked
Fixed address and only the LCD - worked
Detect the address with the LCD and the PCF8575 attached - did not work, but we expect that
Fixed address and PCF8575 attached - did not work, did not expect that

I'm sorry I did not list out each and every combination I tested. I summarized the results to the commonality of when what did and did not work. Same as post #4. Different wording, same test.

bperrybap:
The HelloWorld sketch directly from the library will be using auto location.
As I explained in great detail in post #9, auto location does not work with there is another i2c device inside the i2c address range of the PCF8574.

My apologies, I misspoke in my hurry to move along to providing you new information. The frustration with the lack of direction and guessing at what you are looking for is also getting to me. You are correct. I suppose I should have said "When the tests were performed for post #6, I used the Hello World sketch directly from hd44870->ioClass->hd44870_I2Cexp when testing without specifying the address. When specifying the address the line hd44780_I2Cexp lcd; was changed to hd44780_I2Cexp lcd(0x27);" By saying "I used directly from the examples", I was referring to the fact I was not using some other Hello World sketch or modified in some other unexplained manner (the change to the address was already detailed to show where the change is/was made when needed).

bperrybap:
...the other newLiquidCrystal thread which had similar types of issues with details, inconsistencies and things that didn't make sense or were not possible.

The other thread had other more vague issues. The sketches worked->libraries updated->sketches don't work. That is all I 100% know. Since going back to an older version of the IDE seemed silly as well as using a less supported library. I decided to quit there and move forward instead of back. Even though when this starts working I will have 145 sketches to sort through and update. I am now trying to move to a "better supported" library. I appreciate the time spent, but direct questions and requests for information are needed for me to provide you with information that you need to debug the library you assisted in writing. Vague questions and wordsmithing do not help to move the process along.

As a smart guy I assumed that descriptions like

adwsystems:
Hello World was loaded and ran in many many combinations (adding one component at a time to see what does and doesn't work). The final notable combinations are these four:
Detect the address and only the LCD - worked
Fixed address and only the LCD - worked
Detect the address with the LCD and the PCF8575 attached - did not work, but we expect that
Fixed address and PCF8575 attached - did not work, did not expect that

would be understood that I had already done the process of elimination to determine the area in which the issue is being caused. From my three years posting here, I have seen most of the experts here (like yourself) are used to dealing with Arduino noobs whom are also programming noobs. That is understandable. That comprises the majority of the posters. But when an Arduino noob is also an experienced programmer (like myself), a thread like this one develops. This no slight on anyone person, lots of experts do it as do the Arduino noob experienced programmers. It is a fact of the number of Arduino noob programming noobs that don't bother to even try to debug. Their post #6 would have said "I added a bunch of stuff and it broke. Why?" which is opposed to my post which listed specifically what was added and narrowed it down to one particular item. Please tell me you don't agree on this one point?

Let's move forward. What details do you need in order to help figure out what is going on? (I will get you the error code or lack of code in a few hours when I'm with the stuff). It has been 11 posts since an experiment has been performed, how would you like me to connect the system, what sketch would you like me to test, and what details do you need returned?