Available LCDs and libraries

Paul: I appreciated thank you (and everyone) for all of the comments and help. I read all of them and I understand them. But the comments to the fmalpartida library do not yet seem applicable as I have tried the example and it is not working.

I know the LCD I2C address is 0x27, that address corresponds with the successful operation with the fdebrabander library and Nick Gammon's I2C Scanner.

Did you read my comments back in post #11? I am not seeing anything wrong in the example code. Do you have any idea why the 'Hello World' example from the fmalpartida library isn't working? If the fmalpartida library does work "for all available backpacks", then what do I have wrong? Please provide some help or direction rather than generalized criticism.

It is not generalised.

You have not exhibited code that includes a full descriptor - you appear not to understand what a descriptor is. While I have not deeply studied the instructions for the fmalpartida library as I already know - from inspecting the code - how to use it, I am sure that actually reading such instructions would reveal what a descriptor is and how to use it. I can only then conclude that you have not.

And you claim to have tried "Nick Gammon's I2C scanner", which suggests you have not read my instruction to use the I2Cguesser code.

You are reading superficially (a problem my wife and I share as we have discussed - when we explain things, we mean what we say, not what people imagine we have said because they did not pay attention) - you think " I2C scanner" means "I2Cguesser" - it does not.

If you can assure me (and prove) that you have actually done what I recommended, well I will be concerned that a genuine problem exists, but I think you simply have not.

Paul__B:
It is not generalised.

You have not exhibited code that includes a full descriptor - you appear not to understand what a descriptor is. While I have not deeply studied the instructions for the fmalpartida library as I already know - from inspecting the code - how to use it, I am sure that actually reading such instructions would reveal what a descriptor is and how to use it. I can only then conclude that you have not.

And you claim to have tried "Nick Gammon's I2C scanner", which suggests you have not read my instruction to use the I2Cguesser code.

You are reading superficially (a problem my wife and I share as we have discussed - when we explain things, we mean what we say, not what people imagine we have said because they did not pay attention) - you think " I2C scanner" means "I2Cguesser" - it does not.

If you can assure me (and prove) that you have actually done what I recommended, well I will be concerned that a genuine problem exists, but I think you simply have not.

3 out of 4 statements that tell no one anything. Most definitely general. Comments such as

Paul__B:
you appear not to understand what a descriptor is

are quite general, unfounded, and not necessary.

You are correct I have not run your "I2CGuesser" program. Why would I? It sounds the same as I2CScanner by Nick. After doing research on my own due to the lack of specific information the name in the post is wrong. Some explanation had been provided about what the program you were referring to did would have been specific and useful.

Paul__B:
You have not exhibited code that includes a full descriptor.

So if I read between the lines of your comments in general on the descriptor, you are saying the example code provided (post #6) does not include a full descriptor? Based on the instructions that is the descriptor for use with the library. If there is more information on the descriptor or the descriptor given is incomplete, please provide specifics.

Per your requirements, I have run the I2CLCDGuesser (the correct name) program. It had limited success. It was able to locate the chip at 0x27 (no surprise there). But it does not flicker the backlight 3 times on any of my displays as the comments state. Are you familiar with the inner workings of the I2CLCDGuesser program? Any specific points I should be looking to modify? Any specific items to look at would be helpful.

adwsystems:
You are correct I have not run your "I2CGuesser" program. Why would I? It sounds the same as I2CScanner by Nick.

Which was the reason I mentioned my - and my wife's - concern for attention to detail

When dealing with computers/ microprocessors/ engineering in general, "It sounds the same" just doesn't cut it!

As she cites: "The O-ring is a millimetre out when it's cold." "Nah, that will be fine! What could possibly go wrong?"

adwsystems:
After doing research on my own due to the lack of specific information the name in the post is wrong. Some explanation had been provided about what the program you were referring to did would have been specific and useful.

As I say, it's a difference in attitude. I pointed you to it; I sincerely believed it came with instructions.

adwsystems:
So if I read between the lines of your comments in general on the descriptor, you are saying the example code provided (post #6) does not include a full descriptor? Based on the instructions that is the descriptor for use with the library. If there is more information on the descriptor or the descriptor given is incomplete, please provide specifics.

I don’t follow. Which example code is this? From the fmalpartida library, or something else?

adwsystems:
Per your requirements, I have run the I2CLCDGuesser (the correct name) program. It had limited success. It was able to locate the chip at 0x27 (no surprise there). But it does not flicker the backlight 3 times on any of my displays as the comments state.

And you ran it using the - correctly installed as the only LiquidCrystal_I2C LCD library in the IDE - fmalpartida library? (Naturally, you had the contrast control correctly set.) And I did not realise it was supposed to "flicker the backlight 3 times", for me it simply lights the backlight when you get to the correct descriptor (and some incorrect ones as well).

adwsystems:
Are you familiar with the inner workings of the I2CLCDGuesser program? Any specific points I should be looking to modify? Any specific items to look at would be helpful.

Actually it does not work as such for me due to a problem with the "serial" library not responding to input from the Serial Monitor when I hit Enter, so I tend to use a modified version which just cycles continuously through the options. Clearly that does get the results I need with a little jiggery-pokery with the Reset button, but I do not know whether or why you would need to modify it in any way.

When you get the working descriptor (at least 7 arguments) from the "guesser", you cut-and paste that from the Serial Monitor into your code.

OK some progress. A few logical questions, some already answered. Overall general response with no direction, no specific items to try, or rocks to look under.

Paul__B:
I don’t follow. Which example code is this? From the fmalpartida library, or something else?

The code is copy paste from the fmalpartida Hello_World_I2C example. The only change to the example is to the I2C address (changed from 0x38 to 0x27).

Paul__B:
And you ran it using the - correctly installed as the only LiquidCrystal_I2C LCD library in the IDE - fmalpartida library? (Naturally, you had the contrast control correctly set.) And I did not realise it was supposed to "flicker the backlight 3 times", for me it simply lights the backlight when you get to the correct descriptor (and some incorrect ones as well).

As previously mentioned, I deleted the old library and replaced it. When that did not work, I uninstalled the Arduino IDE and deleted the Arduino directory from My Documents to ensure a clean install of both the IDE and the fmalpartida library.

Paul__B:
Actually it does not work as such for me due to a problem with the "serial" library not responding to input from the Serial Monitor when I hit Enter, so I tend to use a modified version which just cycles continuously through the options. Clearly that does get the results I need with a little jiggery-pokery with the Reset button, but I do not know whether or why you would need to modify it in any way.

Why would I need to modify it? Because it doesn't work [for me/my LCDs]. I know the LCDs work (both physically and logically with the other library that I have been using for more than 6 months) therefore there must be something wrong with the program.

Paul__B:
When you get the working descriptor (at least 7 arguments) from the "guesser", you cut-and paste that from the Serial Monitor into your code.

Like you said, you thought those details were provided. I do not see them. What is the descriptor supposed to be? What are the 7 arguments? I get the general problem. I do not see the specific answer...yet.

adwsystems:
As previously mentioned, I deleted the old library and replaced it. When that did not work, I uninstalled the Arduino IDE and deleted the Arduino directory from My Documents to ensure a clean install of both the IDE and the fmalpartida library.

Which of course means you have to again delete the supplied LiquidCrystal_I2C LCD library from the installed IDE when you install the fmalpartida library.

OK, so fmalpartida clearly doesn't properly describe the descriptor in the direct example given. The presumption is extended from the original LiquidCrystal library that you are using one particular model of backpack - I guess he needs to update and correct it, wherever he now is! The description is hidden within the branch "/LiquidCrystal/docs/html/class_liquid_crystal___i2_c.html".

Ah well. The point is, at least the i2cLCDguesser sketch contains the full prototype code for using the library.

Paul__B:
Which of course means you have to again delete the supplied LiquidCrystal_I2C LCD library from the installed IDE when you install the fmalpartida library.

There isn't one! There is no LiquidCrystal_I2C library as part of the native IDE install. Only a LiquidCrystal library for direct IO is included with the IDE. I figured that out 6 months ago when I had to find a I2C LCD library in the first place.

Paul__B:
OK, so fmalpartida clearly doesn't properly describe the descriptor in the direct example given. The presumption is extended from the original LiquidCrystal library that you are using one particular model of backpack - I guess he needs to update and correct it, wherever he now is! The description is hidden within the branch "/LiquidCrystal/docs/html/class_liquid_crystal___i2_c.html".

Not sure where you are intending to send me with the hmtl link. Unfortunately, my HTML never came up to the same grade as my C/C++.

Paul__B:
Ah well. The point is, at least the i2cLCDguesser sketch contains the full prototype code for using the library.

I'm going to take a stab that the complete descriptor is like lcd(addr, EN, RW, RS, D4, D5, D6, D7, BL, POL). If so, would it have killed you to just post that two days ago.

So I have a full constructor now (I think), with 7 parameters just like you wanted but only know one of them (addr=0x27). Now can you provide any insight as to why the I2CLCDGuesser doesn't guess so well?

Your specifics are getting better. What exactly do you need to know to help me get the software to correlate to the hardware?

adwsystems:
There isn't one! There is no LiquidCrystal_I2C library as part of the native IDE install. Only a LiquidCrystal library for direct IO is included with the IDE. I figured that out 6 months ago when I had to find a I2C LCD library in the first place.

Nevertheless, you need to remove the original LiquidCrystal library to make the new one (which covers virtually all of the various interfaces) work.

adwsystems:
Not sure where you are intending to send me with the html link. Unfortunately, my HTML never came up to the same grade as my C/C++.

That is where the information is relative to the LiquidCrystal library directory when you install it.

adwsystems:
I'm going to take a stab that the complete descriptor is like lcd(addr, EN, RW, RS, D4, D5, D6, D7, BL, POL). If so, would it have killed you to just post that two days ago.

My apologies. As I say, having worked from code posted in the forums here, I presumed the instructions would be with the library.

adwsystems:
So I have a full constructor now (I think), with 7 parameters just like you wanted but only know one of them (addr=0x27). Now can you provide any insight as to why the I2CLCDGuesser doesn't guess so well?

Not removing the original LiquidCrystal library?

Sorry, it just works for me with the modules I have on hand (and as the topic comes up so often, I have deliberately attempted to collect all available versions of the I2C backpack in order to verify them and post a comprehensive HOWTO). Had you chosen to post a picture of the board you are using (as suggested by the master instructions) I probably would have simply located and posted the corresponding descriptor for you.

Paul__B:
Nevertheless, you need to remove the original LiquidCrystal library to make the new one (which covers virtually all of the various interfaces) work.

News to me. Since the header files/libraries are unique between the IDE and the downloaded libraries there is no reason to delete an irrelevent, uncalled library (standard C/C++ program methodologies at work here). In 30 years of programming C/C++ I have never had to delete header files/libraries that were not used in the project. But for you, I tried it. Huh. No effect. No change. Still doesn't work.

Paul__B:
Not removing the original LiquidCrystal library?

Sorry. Not following you direction on this comment.

Paul__B:
Sorry, it just works for me with the modules I have on hand (and as the topic comes up so often, I have deliberately attempted to collect all available versions of the I2C backpack in order to verify them and post a comprehensive HOWTO). Had you chosen to post a picture of the board you are using (as suggested by the master instructions) I probably would have simply located and posted the corresponding descriptor for you.

If you wanted a picture, need a picture, all you had to do was ask. I have attached photos. Please let me know how they help you.

So from your lack of details, I take it you have no idea what may be wrong or any other information on what may need to be changed to get fmalpartida library to work with the LCDs I have.

Can anyone else assist with what I may have to do to get the fmalpartida library to work with my LCDs. As it is the library listed from the Arduino website here, I would think it would be the preferred library to use. But I've not been able to get it to work.

lcd front.jpg

lcd back.png

adwsystems,
You appear to have some knowledge gaps in how the i2c backpacks work and the use of a constructor initialize a library as you seem to be not realizing why things are working/not working and how to properly initialize the libraries.

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".

Here is some background to help fill in the missing gaps about i2c backpacks and libraries:

The i2c backpacks use a i2c i/o expander chip (PCF8574). Ignore the various versions of that chip as that is all noise and doesn't affect how it interfaces to the hd44780 lcd pins. Different versions of the chip have different base i2c addresses which is the only real difference between the different versions.

The problem you are experiencing with the libraries not "working" is due to the h/w architecture of this type of backpack.
The backpack contains an i/o expander (PCF8574) that has 8 i/o pins.
Those 8 pins can be controlled over the i2c bus using the Wire library.
6 or 7 of those pins are wired/connected to hd44780 lcd pins
1 of those pins is typically wired up to control the lcd backlight.

The issue with this type of design is that there is no standard way to connect the 8 i/o expander chip pins
to the hd44780 pins and the backlight control circuit.
So while the i2c interface and how you talk to the PCF8574 chip is all standardized, there is no standard that says which i/o pin on the i/o expander should be connected to which hd44780 pin or which i/o pin should be used to control the backlight.

As a result, different makes of the backpacks will wire the connections differently.

Because there is no standard way to wire up an i/o expander to a hd44780 LCD, there is no way to make a "plug and play" library that will work with all i2c backpacks. It simply cannot be done.

The library must "know" how the i/o pins are connected because it toggles the i/o pins to control the lcd and backlight.
If the library is toggling i/o pins incorrectly, then the lcd and backlight won't work correctly.

It is no different then when wiring up an hd44780 lcd display to use with the IDE supplied LiquidCrystal library.
The library must "know" which i/o pins are connected which hd44780 pins.
The IDE LiquidCrystal library has no default wiring and must be told by the sketch how the Arduino pins are connected to the LCD. These i2c backpacks are no different other than the i/o pins are no directly connected the microcontroller chip but rather are pins on a i/o expander that is controlled over the i2c bus.

So now back to the issue of a library constructor.
Unfortunately, there are several different "LiquidCrystal_I2C" libraries out there.
They all work differently and some of them use slightly different API calls for initialization.
All of them other than fm's library have chosen hard coded i/o expander pin mappings inside them.
So if you use one of those libraries, it will work only if the hard coded pin mappings inside the library exactly match how the i/o pins on the backpack are wired up to the lcd.
fm's library on the other hand allows the sketch to specify how the i/o expander i/o pins are wired. This is why it can work with any of the i2c backpacks.
The reason that fm's library is recommended over others is because the pin mappings can be configured in the sketch.
The way these pin mappings are configured is by using a constructor.
Unfortunately, the examples in fm's library are not good examples of how to use the library.
(I actually dislike them and think they should be ignored, particularly the i2c example as it has several issues in it)
The i2c example does not use the full constructor but rather uses a partial one which uses a default internal pin mapping.
This default pin mapping is for fm's ElectroFun LCD i/o board, so unless your board matches that board (which is VERY unlikely as I've not seen any backpack so far use this mapping) it will not work with your board.

The best thing to do is to use fm's library but then use a full constructor to tell the library exactly how the i/o expander is wired up to the LCD and backlight circuitry.
In order to do that you use the full constructor which has all 8 pins and the backlight polarity, but you must fill it with the correct parameters of how the i/o chip is wired up.
The best way to get the pin mapping information is to visually examine the board to determine how the traces on the PCB are wired up to the hd44780 pins and the type of on board transistor for the backlight. For those with h/w skills this will only take a couple of minutes.
For those that lack h/w skills, I wrote the guesser sketch which was referenced earlier in this thread.
The guesser sketch, when used properly, will go through various combinations of pin mappings to determine the correct pin mappings. The mappings will be displayed on the LCD and on the serial port and the resulting pins can be placed in the LiquidCrystal_I2C constructor in your sketch.
While there are 40,000+ permutations of how to wire up a i/o expander to an LCD and backlight, there are only about 8-10 ways that backpacks are using and most use 2 different mappings.
The guesser will go through all those combinations to help less technical users determine which pin mapping is used.

The thing to remember is that there is no way to produce a "plug and play" library for an i2c backpack that "just works".
Don't get mad at the libraries for not working.
Most libraries have been written for specific h/w to make it "plug and play" for that h/w but it won't work for other backpacks. This is what many backpack makers do. They hardcode their library for their h/w.
fm's library has a default pin mapping to make it simpler for his boards, but it won't work others.
fm's library can work for any backpack but it requires filling in the constructor to tell the library how the i/o expander is wired up.
If you are unable to look at the backpack PCB to determine the pin mappings, use the guesser sketch.

--- bill

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.

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)?

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.

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.

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.

My only question ...

Where were you?

:grinning:

bperrybap:
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?

adwsystems:
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.

(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)

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.

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:

// 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

bperrybap:
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.

bperrybap:
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.

adwsystems:
It does not appear to try all combinations.?

It cannot try all possible combinations.

adwsystems:
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.

Paul__B:
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.

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

:slight_smile:

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

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

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 /[send] button to advance guesses?
and pausing after each?

What do you mean by:

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