DIsplay Issues with latest Arduino LiquidCrystal_I2C and SainSmart2004

I’ve seem some threads on this, but never found a real answer.
I am using the latest Arduino 1.6.7 and the LiquidCrystal_I2C library the program automatically updated.
When I go to print a string, it only displays the first character.
The code is merely:

#include “Arduino.h”
#include <LiquidCrystal_I2C.h>
LiquidCrystal_I2C lcd(0x3F,20,4); // set the LCD address to 0x3F for a 16 chars and 2 line display

void setup() {
lcd.init(); // Initialize the LCD class
lcd.print(“Hello, world!”);


I’m assuming it thinks the end of line has been reached., but I’m not sure how to fix it. Any assistance would be greatly appreciated.


It seems that this pops up almost daily.

Look here: → http://forum.arduino.cc/index.php?topic=361411.msg2492228#msg2492228


mbarnick, i2c backpacks on hd44780 displays is a bit of mess and you are stumbling into the heap. The #1 issue is that there is no way to make a library "plug and play" since how the PCF8574 port pins are wired to the hd44780 pins is not standardized and there is no way for a library to reliably determine this information in cases.

This means that the library must know how these pins are wired. (which is done in etch in the PCB) Some libraries hard code this information and a few allow the sketch to configure this information. Compounding this is that there are multiple libraries with the same name.

The biggest issue with all this mess is that if the library information about how the PCF8574 is wired up to the HD44780 pins is incorrect, then the LCD won't display anything all.

You are actually quite lucky that it works at all given that this library hard codes the PCF8574 pin mapping. You got lucky in that the library has a hard coded pin mapping that happens to match your i2c backpack. i.e. if you buy another backpack there is no guarantee that it will work with this library.

And now back to your specific issue. There are other additional complications on top of those mentioned above. The core code included with the IDE was recently changed and that is why this particular library is not working correctly and only displaying a single character. The library was always broken but the bug didn't happen to show up. When the IDE core code was updated, the bug finally showed up.

With respect to the library automatically being updated: The IDE includes the ability to download, install, and receive updates for 3rd party libraries from github repositories. For this library: "LiquidCrystal_I2C", there appears to be two choices. The IDE was not supposed to allow this, but at least they apparently both point to the same library on github. And while the author of the 3rd party library updated the code to fix this issue 4 months ago, he forgot to re-release it by tagging it. So while it has been fixed, the fix is not available to the IDE library manager as the library manager looks for tags and the fixed version of the library code is not tagged.

I have prodded Marco, to re-tag it over on his github repo. Hopefully, he will do that soon.

In the mean time, if you want it fixed you will need to fix it manually.

And keep in mind that with this library there is no guarantee that it will work with another i2c LCD backpack you purchase in the future since this library does not allow the sketch to configure the pin mappings.

--- bill

Thanks to both Bill and Don for such good replies. Now I think I can move forward. This does lead to a follow on question. I've seen a lot of 2 line LCD displays available, but not the four line. Are there any 4 line LCD I2C displays that can be counted on as an available product for the long term? Sincerely, -Mike

The commonly available I2C adapters that use the PCF8574 chips will work equally well (or poorly) with all HD44780 type character mode displays regardless of their configuration.


The best library I have found so far https://github.com/mrkale/LiquidCrystal_I2C The single character problem is fixed but it still has a problem. When printing past the end of a row, it advances 2 lines instead of one. Just don't stream past the end of the row and you will be fine. I just went through this yesterday with a 4x20 display. Everything worked well except for the double line feed if you go past the end of the row. You will see that if you run the test code. LiquidCrystal_I2C Library

@Nasa, Long story short, the lcd module doesn't treat the display like a streaming device or "terminal" that understands line endings and wrapping, And almost none of the hd44780 libraries have the code in them to provide this added functionality. So as a result you see "odd" things happening, when trying to push characters to the LCD device when assuming that line endings and wrapping is supported. I said "almost none" since out of the dozens of hd44780 libraries I've looked at, I have seen 1 library that does provide this end of line processing functionality.

more details:

The issue with linewrap you are seeing is because nearly all the hd44780 libraries just send characters to the display and do not do any sort of end of line processing. hd44780 displays are very dumb devices and also do not perform any line ending processing. As a result no line ending processing is being done. Characters are just written to the next display memory location on the module.

This creates some odd effects on the display if the more than a single line of characters are sent. What is observed visually varies depending on how the display memory is mapped to the LCD characters on the physical display. How this done varies depending on the lcd geometry. In many cases there is more display memory for characters than characters on the physical display.

What you are seeing on the 4x20 display is "normal" when characters are written sequentially to display memory without consideration for how characters are mapped from display memory to physical locations on the display. In other words, on hd44780 lcd displays, the display memory is not a block of memory that starts at zero and advances to location rows x cols -1 that maps one to one to the characters on the physical display.

On smaller displays, if you continue to write beyond the end of a line the characters will "disapear" as they are written to memory but not displayed on the display.

In effect, each line of characters on the physical display is a windows into display memory. The chip-set even allows moving that window.

When printing past the end of a row, it advances 2 lines instead of one.

I just went through this yesterday with a 4x20 display. Everything worked well except for the double line feed if you go past the end of the row. You will see that if you run the test code.

The display is not 'advancing two lines', the controller is just placing the character in the next memory location as it always does.

If you send 80 sequential printable ASCII codes to 20x4 display controlled by an HD44780U the characters will be displayed in the following sequence: row 1, row 3, row 2, row 4. This is due to the characteristics of the HD44780U controller.

For a complete description of why it works this way follow the [u]LCD Addressing[/u] link at http://web.alfredstate.edu/weimandn.