Go Down

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

adwsystems

#15
Jul 22, 2015, 07:24 pm Last Edit: Jul 22, 2015, 07:26 pm by adwsystems
Chuck:

The fmalpartida library, that was suggested to be used (post #6), is not working for the same displays.

If you are suggesting to use the fdebrabander library, then you are linking to the library I am using and is working for me (see post #9). Is that what I am reading?

chucktodd

Chuck:

The fmalpartida library, that was suggested to be used (post #6), is not working for the same displays.

If you are suggesting to use the fdebrabander library, then you are linking to the library I am using and is working for me (see post #9). Is that what I am reading?
I understood that you had not been able to use your I2C LCD.

I was trying to show you how you could modify that library to fit your hardware.

If your LCD is now working, sorry I wasted your time. I thought you had not yet found a matching library.

Chuck.
Currently built mega http server, Now converting it to ESP32.

adwsystems

The situation started as a question about a library capable of running both the 16x2 and 20x4 LCD via I2C. I have been using the fdebrabander library, which you suggested, to run the 16x2 I2C LCD quite successfully. Paul suggested using the fmalpartida library, which when implemented did not work on any of my LCDs. Do you know if the fdebrabander library is compatible and will also drive a 20x4 LCD?

chucktodd

The situation started as a question about a library capable of running both the 16x2 and 20x4 LCD via I2C. I have been using the fdebrabander library, which you suggested, to run the 16x2 I2C LCD quite successfully. Paul suggested using the fmalpartida library, which when implemented did not work on any of my LCDs. Do you know if the fdebrabander library is compatible and will also drive a 20x4 LCD?
as long as the LCD module uses the HD44780 controller, and it is wired the same, it will work.

The HD44780 is used with 8x2,8x1,16x2 .. 40x2 displays. 
I have one 40x4 display that is actually 2 40x2 displays in the same case. I have to keep track of where the next character is, turn off cursor on one, turn cursor on the other when I scroll from line 2 to line 3.

I have substituted 16x2 with 20x4,  the display still works, but all of the row/column positions are different. Data shows up on the displays but not where you expect it.
(0,0) = top left, if you continously write data after the first line is filled the next position filled is the first character of the third line, then a few missing (hidden characters) then the second line is filled, then the forth line is filled.

You will have to change how you use the display; extra screen space, organization of prompts, etc..

chuck.
Currently built mega http server, Now converting it to ESP32.

Paul__B

I used Nick Gammon's I2C scanner in addition to the fact that I already knew and had working the displays. The address is 0x27 and the only thing connected to the Arduino UNO (nothing else on the I2C or anywhere else on the Arduino).
You do not appear to be reading or understanding my explanations and clearly do not understand what a "descriptor" is. :smiley-roll:

My comments stand.  If you care to read the instructions, the fmalpartida library works beautifully.

adwsystems

#20
Jul 23, 2015, 12:30 am Last Edit: Jul 23, 2015, 12:44 am by adwsystems
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.

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.

adwsystems

#22
Jul 23, 2015, 04:03 pm Last Edit: Jul 24, 2015, 01:38 am by adwsystems
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
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.

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.

Paul__B

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

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.

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?

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

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.

adwsystems

#24
Jul 24, 2015, 03:14 pm Last Edit: Jul 24, 2015, 03:20 pm by adwsystems
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.

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

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.

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.

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.

Paul__B

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.

adwsystems

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.

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

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?


Paul__B

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.

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.

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.

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.

adwsystems

#28
Jul 25, 2015, 05:32 pm Last Edit: Jul 25, 2015, 05:38 pm by adwsystems
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.

Not removing the original LiquidCrystal library?
Sorry. Not following you direction on this comment.

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.



bperrybap

#29
Jul 25, 2015, 06:14 pm Last Edit: Jul 25, 2015, 06:14 pm by bperrybap
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






Go Up