Hi , I have tried to print some texts with my I2C display , i have downloaded the LiquidCrystal_I2C library and tried to run a simple code that prints a simple text like " Hello World" , what it does is that it only prints the first character of the text , so the output in the display would be just "H" , i tried some other texts in both rows and it just prints the first char in each row. i tried to test some other functions such as setCursor , and serial.read/write and they worked perfectly. the problem is just in lcd.print(text) where it just prints the first char . it can however print the text if i print each char separately.
here is the code:
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
LiquidCrystal_I2C lcd(0x27,16,2); // run ic2_scanner sketch and get the IC2 address, which is 0x27 in my case
void setup()
{
lcd.init();
// set cursor to first line
lcd.backlight();
lcd.setCursor(0, 0);
lcd.print("Hello World");
}
void loop()
{
}
i could print it if i do this :
lcd.print("H")
lcd.print("e")
lcd.print("l")
lcd.print("l")
lcd.print("o")
...
but why it doesn't print the whole text ? it's really annoying . please help.
I don't have your library so I'm not 100% sure about the answer to this question but should you be calling init or should you instead be calling begin? Most of the code I've seen using one of the LCDs you have to call begin.
floresta:
This is most likely a problem with the IDE as has been reported here about a week ago.
Don
While it shows up as an issue when using the recent IDE, it is not really an IDE issue.
And while the issue is due to an interaction between the Print class supplied with the newer 1.6.6 IDE package, the actual issue is in the i2c lcd library.
The library is incorrectly always returning an error status on the write() function but the older/previous Print class ignored the return status returned by write().
The Print class code supplied in the newer IDE's looks at the return status and stops sending characters down to the library write() function on an error.
That is why a single character works but anything that prints multiple characters only prints the 1st character.
It is an easy/simple fix 1 line fix in the library.
The write() function in the library needs to return 1 and not zero.
Please accept my apologies for this being a NEWBIE question from someone with limited C-experience:
but how do you actually implement DonPedro34's solution?
Do I need to edit the code in the LiquidCrystal_I2C library?
But then ... do I also need to create a new .o-file?
How would I do that?
But it also seems a bit obscure to modify the library ... my code would only work properly on a machines with the same modification to the LiquidCrystal_I2C library ...
Or is the code that DonPedro34 listed meant to be included in your project to (transparently) "overwrite" the library's code? Where would be the appropriate place?
Arduinolaf, when a library is broken the only way to correct the problem is to fix the library and so yes your code can only work properly when you have a correctly working library.
The LiquidCrystal_I2C library has been correctly updated and is available using the library manager.
If this LiquidCrystal_I2C library works with your hardware, (you are seeing only the single character) then all you need to do is update it using the library manager.
The reason I say "works with your hardware" is that this library is not configurable and so it doesn't work with all i2c PCF8474 based backpacks.
The issue of only printing a single character in this thread is not related to this configurability issue. It is an actual bug in the library that was previously hidden that now shows up on more recent versions of the IDE.
Compounding things, is that there are multiple different libraries that provide a "LiquidCrystal_I2C" class and they work differently.
Most are hard coded for a specific version of a backpack, and some can be configured to work with any backpack.
If you are lucky, the LiquidCrystal_I2C library supplied by the library manager works with your h/w.
If it does, all you need to do is update it to the latest version.
If it doesn't work, you will need to use a different library and I would recommend using a library that can be configured to work on any backpack.
Bill, many thanks for the pointer to the library manager. I inherited the setup from a student and did not realize the library was available through the library manager of the IDE ...
I downloaded the newest version (1.1.2) and the source (.cpp) contains the code snippet of DonPedro's fix.
Seeing the whole context in the code, I get the feeling that the compiler instructions are meant to only apply the fix for certain Arduino projects ...
There are two seemingly identical entries for the library in the library manager.
The first one failed to install for me (I think it said "CRC corrupted"?), the second installed just fine.
Since the library worked with my LCD/backpack before I upgraded to Arduino 1.6.8 and I can print single characters I guess this fix is good for me ... I will see when I get back to the breadboard.
Arduinolaf:
Bill, many thanks for the pointer to the library manager. I inherited the setup from a student and did not realize the library was available through the library manager of the IDE ...
I downloaded the newest version (1.1.2) and the source (.cpp) contains the code snippet of DonPedro's fix.
Seeing the whole context in the code, I get the feeling that the compiler instructions are meant to only apply the fix for certain Arduino projects ...
It isn't a fix that that is related to any sort of project. It is that IDE 1.0 and beyond uses different APIs than pre 1.0 and the code in this library was not properly using the IDE 1.0 interface.
The library has to check if it is being used on pre 1.0 or 1.0 and beyond and when used in 1.0 and beyond the code was wrong.
The issue goes back to a major problem the Arduino team created when they released Arduino 1.0
After the final release candidate, but before they create the official 1.0 release The arduino team made some changes that broke 100% of ALL the existing 3rd party libraries.
Think of that for a moment. They consciously decided to break 100% of ALL the existing Arduino 3rd party libraries and to do that in between the final 1.0 release candidate and the final 1.0 release.
No beta, no release candidate for testing. Just BAM. Change the code and break all arduino 3rd party library. What was particularly frustrating was that were ways to provide backward compatibility for almost all the changes to ensure that the pre 1.0x libraries would continue to work. This is not the way s/w release are normally handled as you normally don't make such a major change between a final release candidate and the final release.
There was much controversy over this decision and it has only been recently that some members of the arduino team finally realized what pain they created for the community.
We are still fighting pre 1.x vs post 1.0 library issues to this day even many years after the 1.0 release.
We almost had another Arduino library total meltdown again when switching from the 1.0 library format to the newer 1.5x library format (which is what the IDE is using today).
Luckily a few of us were able to convince the Arduino team to allow the pre 1.5x libraries to work in the post 1.5x IDEs. Otherwise, 100% of ALL the existing 3rd party libraries would have broken and had to be updated to work with the post 1.5x IDEs.
I will say that it took much lobbying to get this to happen, and several of the founding Arduino team members were against pre 1.5x library compatibility.
Luckily, Cristian made the sane decision that backward compatibility is very important and prevented a repeat of the chaos that happened when 1.0 was released.
One of the changes (there were several) the Arduino team made when they went to 1.0 that broke everything was to change how write() worked. Originally it was a void function, the new version returns an integer count.
In this case the lcd library returned the wrong count, but until the newer versions of the IDE, the code in the Print class ignored the return value. As soon as it started looking at the return value, this lcd library broke.
The fixe to this lcd library actually was done in just a matter of days of the issue being discovered. (several months ago)
However, the library was not properly tagged in the git repo so even though the source code for the fix was in the code in the git repo, the library manager didn't see there was a new version available since it was not tagged and tags are how library managers "sees" library versions/updates.
I contacted the maintainer of the library about a week or so ago and had him tag the library so the updated library would show up in the library manager.
There are two seemingly identical entries for the library in the library manager.
The first one failed to install for me (I think it said "CRC corrupted"?), the second installed just fine.
I have seen that as well. I'm not sure what is going on here. I think it is actually a bug in the library manager.
Both libraries point to the same git repo, so there really only is one library and the library manager only allows a single library for any given name. It shouldn't be possible to have two libraries in the library manager with the same name.
This particular library has a different author than maintainer and perhaps that is somehow confusing the library manager into thinking it is two different libraries and creating some sort of issue.
(just a guess)
I may go bug it so it can be resolved.
sorry for the tardy reply. Thanks for the background on this bug. And for helping to make the fixed library available. It saved me some hours and grief to get to the bottom of this issue.
