Strange problem with my I2C LCD and "Hello World" Sketch

Hi, I’m very new to this so any help is greatly appreciated. I’m trying the basic “Hello World” program for my LCD and Arduino Uno R3. It seems to be partially working. I say partial because the only thing that it will display is the letter “H”.

This is the Sketch I’m using:

//DFRobot.com
//Compatible with the Arduino IDE 1.0
//Library version:1.1
#include <Wire.h>
#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x3F,16,2); // set the LCD address to 0x3F for a 16 chars and 2 line display

void setup()
{
lcd.init(); // initialize the lcd

// Print a message to the LCD.
lcd.backlight();
lcd.print(“Hello, world!”);

}

void loop()
{
}

I’ve searched the forums and had no luck finding an answer to this. Any suggestions are appreciated!

Upon further searching, I found some threads that seem to cover this.

hi,

i made a projekt with I2C Display's.

since then, a couple of month have gone.

last time i worked with Ardiuno IDE 1.5.4, used the one of the first LiquidCrystal library's.

Now i have new Projekt, a new Display that's a bit diffrend from my first and the same Problem like you.

It show's only the first character - "H" from Hello.

To solve this, you have to update the IDE.

Remove all old or wrong librarys -> LiquidCrystal_I2C

download the latest library (NewliquidCrystal_1.3.4.zip) from

https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads

Import it via IDE -> ADD ZIP Library

you can find this all at

http://arduino-info.wikispaces.com/LCD-Blue-I2C

now try the example

and it works.

THX @ fmalpartida for this great work

Yes, there is a similar discussion going on elsewhere.
One thing I just noticed - the constructor used in this case has SPI address and display size - columns X rows.
The one used in the other discussion has different parterres passed to it - address and the I/O pins of the piggyback converter.
It should not make a difference what parameters are passed as long as the correct constructor works,but…

BTW last time I looked in my I2C library it runs true Hitachi “init()” code in constrictor , no need to run it separately. init() includes proper timing.

It should not make a difference what parameters are passed as long as the correct constructor works,but...

It makes all the difference in the world. The parameters that are passed must match the parameters that are expected.

The basic underlying problem is that each I2C library seems to expect different parameters yet all I2C libraries seem to have the same name. That means that unless you know exactly which I2C library is being used you cannot make any assumptions about what is expected in the constructor.

Don

floresta:
It makes all the difference in the world. The parameters that are passed must match the parameters that are expected.

The basic underlying problem is that each I2C library seems to expect different parameters yet all I2C libraries seem to have the same name. That means that unless you know exactly which I2C library is being used you cannot make any assumptions about what is expected in the constructor.

Don

Let's not bicker about semantics - most libraries have mutiple ( overloaded ) constructors and the compiler will use the one whose parameters match.
But if the constructor whose parameters are as discussed - address and LCD size - and has no code to interface between I2C controller and LCD header pins, now what ?
I would hope some of the missing parameters are programmed as defaults for some common hardware.

That is what I suspect is the "difference " between various I2C libraries.

That is what I suspect is the "difference " between various I2C libraries.

The primary difference between the various I2C libraries does indeed have to do with the interface between the I2C controller and the LCD header pins. Unfortunately, since the various I2C adapters use different wiring then the library for each adapter has to have different code from the others.

It is the fact that most I2C adapters look similar on the surface and that the libraries have the same name that leads newcomers to believe that the libraries themselves are interchangeable.

At the present time I believe that the library written by Francisco Malpartida, referenced in reply #2, is the only one that provides for dealing with the differences in I2C adapter wiring by means of the constructor. I am not sure if this is the library supplied by DFRobot, but I doubt it.

The Malpartida library is not an I2C library designed to be used in conjunction with the generic LiquidCrystal library, it is a total replacement for that library. Hence the requirement to remove or rename all traces of the generic library as well as doing the same for any other I2C libraries that were installed.

This discussion of constructors is not pertinent to the problem that the original poster had, that problem was due to the way most I2C libraries interact with the IDE. As I understand it most I2C libraries were not handling some some return values properly. Older versions of the IDE were tolerant of that situation but the newest version is more strict. I believe that the Malpartida library works correctly with the latest version of the IDE so the use of that library should solve the original problem.

Don

So it remains that - warts and all - the fmalpartida library should in all common sense be the one supplied with the IDE and the fact that it is not, is but one of the shocking failings of the project.

Paul__B:
So it remains that - warts and all - the fmalpartida library should in all common sense be the one supplied with the IDE and the fact that it is not, is but one of the shocking failings of the project.

I am generally pretty open when discussing technical aspect, I just don't believe that pussyfooting around the issue helps much or is necessary, barring foul language of course.
( But what is wrong with RTFM - to me it is as generic as xerox, keenex (sic?) etc. )

I still maintain that the Arduino was designed for kindergarten level users and has no intention to get out of that mindset.

These "included / canned libraries within IDE" are just spoon feeding the " I want Arduino to shoot rocket to the Moon, but cannot be bothered with learning how to code " should go away and the users should be using the most recent "library manager" to actually given a chance to select the needed library.
It would somewhat (?) force Arduino.cc to better manage the quality of such libraries so similar issues as with I2C LCD libraries could be prevented.

I usually "solve" which library is in use by setting preference to verbose and actually pay attention to compiler messages.

Since "libraries" are open source I sometime make local copies and add comments, versions , #pragma message(s) , modify etc.

Adding full path to #include also works for me.

But the bottom line - why do users need to jump thru all these hoops?

And the answer is - what do you want for free?!

Off soapbox, again at 05:30 ( AM !)