I ran your code @david_prentice. Please find the output in below link. And yes there are many blank chars. i am seeing. Is it possible to place 0x20 with other hex value to get the empty space ?
your LCD is probably a bad one.. get it replaced if you can
Letters 0x20, 0x40, 0x60, 0x80, 0xA0, 0xC0, 0xE0 are corrupted.
You could write 0x10 instead of 0x20. Or several other blank letters.
But you would also need to replace 0x40 @ with a custom character.
Just show the video or Forum page to the shop. They will replace your faulty LCD.
Here is an overview.
It is pretty crazy so strap in.
My history with this library goes back more than 10 years.
I've been involved with this library, as well as several others including fm's NewLiquidCrystal and then my own hd44780 library.
This LiquidCrystal_I2C code is from library that goes back more than 10 years.
When the library manager was added to the IDE, Marco Schwartz created a github project and had his project added to the library manager.
All he wanted was to help out by adding the library to the IDE library manager.
He didn't have the time or skills to actually maintain it.
A few years ago, he asked for someone else to take it over.
I didn't want to do it, but a guy named John Rickman stepped in.
At this point, unfortunately, Marco re-assigned the repo to Rickman (rather than giving him update privileges to his repo).
Rickman went in and made a few changes and one of them was changing the license away from LGPL to BSD - which is not allowed under the LGPL license.
I called him out on it and he moved the project to gitlab and put in the note about it being moved to gitlab.
Moving it to gitlab wouldn't work since the IDE library manager points to github.
I again called him out on the copyright issue on gitlab
He then changed the repo name on gitlab a couple of different times before it finally disappeared - and I couldn't find it anymore.
He no longer will answer any of my emails.
The emails are not bouncing so I assume that he is getting them.
A few months ago I exchanged emails with Marco, and have offered to take it over.
Not that I want to, since I have the hd4480 library, but there are some serious issues with the LiquidCrystal_I2C library it and some of its tags that confuses the library manager. So I'd be willing to take it over and likely create an organization account to make it easier to assign/re-assign developers and at least get the library to a more stable state where it can be maintained.
At this point the github project that Marco created has been assigned to Rickman.
Rickman is AOL and there is no way to get control of the repo back from Rickman.
Marco can't even get control back as when repos are re-assigned the original repo is essentially removed and in its place is a link to the new repo and the original owner loses control.
So what we have now is a mess.
I think the only way to correct it is to either, get arduino.cc involved to re-assign the library to a new repo, or create a yet another "LiquidCrystal_I2C" library and get it added to the IDE library manager.
--- bill
Thanks for the explanation.
Is it possible to make a compatible wrapper around your hd44780 library and name it "LiquidCrystal I2C" and ask the Arduino team to point to your wrapper ?
On that note.
I'll have a major update to the hd44780 library to try to address this.
The issue now is that getting to the proper examples is not intuitive and while it is documented, it can definitely be made better.
I'll also be separating out the actual examples from the hd44780 library special purpose demos that are bundled to make things easier/simpler.
Unfortunately, IDE 2.0 has broken the ability to bring up local html files which cripples some of the enhanced documentation I had planned.
I was hoping it would be fixed in the actual 2.0 release, but it wasn't.
I've had all this in place for quit a while, I just haven't released it yet.
It is part of major update that also includes support for new devices and also has some new capabilities that allow the user to configure things like which Wire library object to use in the constructor so it can easily & smoothly can work with things like multiple i2c busses or software wire implementations.
Other libraries have attempted to solve this i2c Wire object issue, but so far, all them, IMO, have failed as they took an incorrect approach so they don't "just work" and have issues depending on the environment.
--- bill
I agree 100% with the mess and futility that is LiquidCrystal_I2C.
But in this case it appears to be a problem with the actual font inside the hd44780 chip.
@Bill,
Have you ever seen this before ?
Incidentally, the class name conflicts appear in several third party libraries.
It would seem wise for the Arduino Library Manager authorities to specify that a new class requires a unique name if it does not follow the original class API.
Of course you can't stop companies distributing hacked versions of obsolete libraries. But at least you can recommend the IDE Library Manager which will point to a known URL on GitHub.
David.
It would be possible to create a new LiquidCrystal_I2C library that is nothing but a wrapper around the hd44780_I2Cexp i/o class, but why?
Given the way the arduino.cc team implemented "libraries" in the IDE and "library" searching and library manager code (they are not actually libraries), it is not possible to have multiple libraries in the IDE library manager with the same name. So this "wrapper" if it had the same name (which it would need to if it were going to be backward compatible with existing code) would have to replace the existing LIquidCrystal_I2C library.
I think it would not be a good idea to do this for a variety of reasons.
If you really want to fix the LiquidCrystal_I2C in the IDE library manager, then I'd talk to arduino.cc and ask them that given the situation, if it would be possible to re-assign the library to a new github repo.
I'd recommend creating a github organization account and put it there with a trusted person running it that can add/remove additional github users for maintenance and/or administration as needed.
But it is very easy to convert sketches written for LiquidCrystal_I2C to the hd44780 library hd44780_I2Cexp i/o class.
The hd44780_I2C i/o class is fully compatible with the LiquidCrystal_I2C API and constructor.
The hd44780_I2Cexp i/o class even supports a constructor with the same parameters as LiquidCrystal_I2C
All you have to change to use the hd44780 library with the hd44780_I2Cexp i/o class is change the includes and the class name for the constructor.
Existing code should work, including code that calls init() instead of begin()
The one difference is that hd44780 turns on the backlight by default so if code does not want it on by default after init() or begin() is called it will have to turn it off.
There is also a licensing difference between LIquidCrystal_I2C and hd44780
LGPL 2.1+ vs GPL v3
--- bill
Looking forward to it! (And while you are at it, I had trouble finding what configuration works in wokwi)
It does look like a font issue. Particularly since other characters are working and I2CexpDiag passed.
It would be interesting to see the output of the LCDcharset demo.
It shows the entire font. (best to tweak the LCD geometry for the larger display)
it is in ioClass->hd44780_I2Cexp->hd44780examples->LCDcharset
You can modify the defines in the wrapper sketch to change the geometry.
I saw an issue like this years ago.
I saw an LCD that used an hd44780 "compatible" chipset.
I can't remember which one, but the space 0x20 character was broken (not all blank pixels)
It was a font issue you had to change 0x20 spaces to another character to something like 0xA0 (memory is foggy on this).
I didn't want to support it because they also added multiple fonts and the way they supported them broke the hd44780 function set initialization in that you could not guarantee that it would always work. i.e. it would fail if 4 bit nibble sync was lost.
They broke the function set commend to add multiple font support.
I have seen other chips have the same multiple font issue because of the way they broke the function set command to support multiple fonts.
The real problem is the way the arduino.cc implemented "libraries" which are not really libraries and the way they guess which header file to use.
I argued with them YEARS ago about how they were handling libraries and header files and offered a simple way to eliminate header file name collisions when they were moving to 1.5x libraries.
It would have totally eliminated the issue of multiple libraries with the same header file name by allowing users to more directly specify the library when doing includes.
i.e. similar to this
#include <libraryname/headerfilename.h>
this would avoid having the IDE having to guess which library to use for the header file name and also having to use an include path for each library.
It could be backward compatible in that IDE could still guess by looking for the header file if the library directory was not specified.
They were not at all open to this even though it was extremely simple to implement as only required adding the "libraries" directory to the include path to eliminate header file collisions.
IMO, they simply did not fully understand the issue and the limitations of include paths.
What they implemented instead was a much more complicated search methodology that gives priority to a header filename that matches the library directory name. It attempts to select the library by specifying its directory in the include path.
While what they did works in some cases it does not fully solve the problem.
Even though the IDE may guess correctly for the specific header file, it may still fail to get the desired header file because of the way they depend on header file include paths.
Whether it works or not when there is a collision can depend on the order the sketch included header files from the libraries since it is dependent on the include paths. It can also fail depending on the alphabetic order of the library names.
i.e. there is no way to absolutely specify with certainty which header is used with their methodology of using include paths.
They still could add what I proposed and it would enhance what they are currently doing and eliminate the problem for users that would specify the library directory in their includes.
--- bill
The hd44780_I2Cexp i/o class will not work in wokwi.
I had a discussion with one of their developers about it.
It is a problem on their side.
They have not fully and properly emulated the PCF8574 chip, and its interactions with external h/w like the hd44780 chipset, and i2c backpack backlight circuitry.
To do this properly you have a have a full understanding of how the inputs and outputs work when connected and emulate those behaviors.
They have not done this. PCF8574 reads are not working properly.
(note: other LCD backpack libraries do not do reads from the PCF8574 chip)
The hd44780_I2Cexp uses PCF8574 reads and the real world h/w interactions to do auto configuration.
Because they are not properly emulating these interactions,
the auto configuration will fail.
Until they fix that, it won't work.
One the developers got pretty testy with me. It got bad so I walked away.
It is their issue. Their emulation/simulation is incomplete and does not properly emulated what happens on real h/w.
Until they fix PCF8574 reads when connected to hd44780 LCD and backlight circuitry it it won't work.
Now I think you can use the hd44780_I2Cexp i/o class if you fully specify the configuration (all the pin mappings and backlight active level) to by pass the auto configuration, but that kind of defeats one of the big features of using it.
--- bill
Ok understood
Unfortunately, in the mind of the developer I was talking with, it was an issue in the hd44780 library since it was "working" with all the other LCD backpack libraries.
So I'm not sure if fixing the PCF8574 emulation will get any attention.
--- bill
Hey guys, Thank you for the support. I got the new LCD and now everything is working fine. Just curious can we replace 0x20 with some other hex value directly inside the library so that my faulty LCD also works after the code compilation?
you could explore modifying the write() function of the print class of your LCD library so that it traps the 0x20 byte and replace that by a custom character
Yes you could replace each 0x20 space with 0x10 or other character.
Note that you need your own lcd.clear() function e.g. to write 0x10 to every place on the screen. (80 characters)
J-M-L's suggestion could work transparently. e.g. by writing a C++ class that extends the existing class. But this gets a bit fiddly when you are trapping the low level register that implements lcd.clear()
David.
clear probably would work too with a custom char, once uploaded.
here is an example where I took the initial library from post 1 and modified the write method to read
inline size_t LiquidCrystal_I2C::write(uint8_t value) {
send(value == 0x20 ? 0x0 : value, Rs);
return 1;
}
so basically it says, "if I'm being asked to send the character 0x20, then I send the custom char 0"
in the arduino script I define the custom char 0 as an heart so every space will be replaced by an heart
here it is in action:
➜ the code says
lcd.print("spaces[ ]");
and you can see that you get hearts instead
so now, instead of an heart, you could have an empty custom char and get the spaces you want
Yes, you get hearts from a specific write(0x20)
However the library would have called lcd_command(1) as part of the initialisation i.e. lcd.begin().
Or the program calls a specific lcd.clear()
And you have not got any hearts after the periods in line #1 nor in lines #3, #4.
Simple enough to kludge a program for the faulty LCD as a one-off.
It will be irritating when you use the modified library with a good LCD.
While you can modify the library fairly easily to "work" if that is the only issue.
However, my concern would be that if the new LCD is the exact same device as the first one, then something is corrupted on the original device.
It may be something more than just a few bits of corruption in the font for 0x20 character.
Have you looked at all the characters to see if there is any other corruption?
Me, personally, I would just toss it, or keep it around for testing purposes.
To modify the character for space is more than just replacing 0x20 with some other character in the write() routine, it also requires changing the clear() function.
The clear() function would need to be modified to no longer use the clear display command but instead home the cursor, write the full display with the space character, then home the cursor again.
And to make the same library work with normal LCDs and this broken one, you would want to be able to configure the "space" character.
i.e. perhaps add a new API function to set the "space" character and clear the display afterwards.
That way it could default to 0x20, and you could set it something else from the sketch, if desired.
Also, most fonts have another blank character in them so you won't need to use a custom character.
But like I said, I'd be concerned that the issue you are seeing is not the only issue with that LCD.
--- bill
for sure 