mjkdz I2C - modify lcd constructor

Hello there.

First of all, I'm a newbie.

I have a mjkdz I2C board and a LCD (+arduino, of course). The LCD pins are {VSS, VDD, VD0, RS, RW, E, D0, D1, D2, D3, D4, D5, D6, D7, A, K} in this order. The I2C circuit is connected to LCD like this: 1-VSS, 2-VDD, 3-VD0......16-K (when the soldering is a square, that means that pin is the first pin, right?)

https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/schematics#
Here says an order for my I2C circuit. But in my opinion, if the I2C is connected to LCD how I said upper, the order from there is wrong.

The constructor would not be LiquidCrystal_I2C lcd(0x20, 4, 5, 6, 0, 1, 2, 3, 7, NEGATIVE);.
It will be LiquidCrystal_I2C lcd(0x20, 6, 5, 4, 11, 12, 14, 14, 15, NEGATIVE);

The trouble is that none of the two lines of code do not work. The LCD only has backlight and 16 squares on the first line.

Any help would be very appreciated.

Don't be offended but do you know what I2C is ?
(YES, a square SOLDER-PAD indicates pin-1)

Check out this post:
http://forum.arduino.cc/index.php?topic=142255.0

I said in the first post that the pin the connection is 1-VSS, 2-VDD, 3-VD0, 4-RS, 5-RW, 6-E....and so on.
In the link you posted that guy uses lcd (adress, 4, 5, 6....). In my case it will be (adress, 6, 5, 4...), right?
And there is a pin 0: the pin connected to D4. Which is the pin 0?

I said in the first post that the pin the connection is 1-VSS, 2-VDD, 3-VD0, 4-RS, 5-RW, 6-E....and so on.

I think you may be confused about which connections have to be specified in the constructor.

Virtually all LCD modules have the same pin configuration at their board edge, where they connect to the outside world.

Virtually all I2C adapters have the same pin configuration at their board edge as well. The difference comes in when you consider how those external pins are connected to the actual I2C chip on the adapter board. It is that information which has to be passed to the I2C library via the constructor since it varies from adapter to adapter.

And there is a pin 0: the pin connected to D4. Which is the pin 0?

I believe that this may be referring to the bit number of the port on the I2C adapter, not the pin number of the chip.

Don

I think you should re-read the entire post of the link I gave you, particularly the part by Bperrybap.
Pay particular attention to the comments about lcd constructor. I don't know what you mean by pin 0. Show me something, a drawing or diagram that shows pin-0 and I will try to answer your question. Give me some documentation.

The order of the LCD pinout connections on the LCD module has no bearing on the bit numbers used in the
lcd library constructor.
Almost all hd44780 based LCD modules will use that same 16 pin pinout -
some move things around for the A and K connections since those are
technically not part of hd44780.

When the I2c backpack is designed, the connections between the i2c chip outputs
and the LCD module are created for a fixed LCD module pinout.
All the i2c backpacks I've seen, use that standard 16 pin LCD pinout - but they all are not wired
up the same between the LCD and the PCF8574 and hence require different constructors.

The bit numbers used in the constructor is based on how the PCF8574 i2c chip's
output port is wired up to the LCD module connections.
The wiring is done in etch on the PCB.
Yes there is more than one wiring used on these types of i2c boards.
While most of the "mjkdz" ones out there seem to have wired them up the same,
the only way to really know for sure is to look at the traces on the i2c board
between the PCF8574 chip and the LCD module to see how they wired up
the PCF8574 output port bits.

(this is a quote from Bperrybap discussing the same thing Don just referred to )

Robert

I think you should re-read the entire post of the link I gave you, particularly the part by Bperrybap. Pay particular attention to the comments about lcd constructor.

I agree.

I don't know what you mean by pin 0. Show me something, a drawing or diagram that shows pin-0 and I will try to answer your question. Give me some documentation.

The 'documentation' mentioning bit 0 is in reply #2 of that same post. The OP misinterpreted this as a pin number as I have already pointed out.

In your quote above Bill mentions "The bit numbers used in the constructor is based on how the PCF8574 i2c chip's
output port is wired up to the LCD module connections".

There's nothing more to answer about the mysterious 'pin 0'.

Don

Got it

Actually there is a "pin 0" at least if you look at the PCF8574 datasheet
and this is where some of the confusion probably comes from.
If you look at the datasheet you will see that it calls
the i/o pins P0, P1, P2, P3, P4, P5, P6, P7
In other words i/o "pin 0", i/o "pin 1" etc....
It also happens that that those PCF8574 Px "pins" are directly mapped to the
corresponding bit number inside the i/o port register.

The LiquidCrystal_I2c constructor wants to see those PCF8574 bit numbers,
which are the same as the Px numbers
which could be called i/o "pin numbers", but those "pin" numbers should not be confused
with the physical pin numbers of the chip.
i.e. P0 "pin 0" is physical pin 4 on the 16 pin packages.

To avoid confusion it is probably best to call them either by their Px name P0, P1, etc...
or by the bit.
So P0 or bit 0 is much clearer than saying "pin 0".

psycho22,
You seem to have a total misunderstanding as to what the numbers in the LiquidCrystal_I2C()
constructor are.
The constructor wants PCF8574 Px numbers or the bit number of the i/o register.
These numbers depend on how the PCF8574 is wired up to the HD44780 pins.
This constructor:

 LiquidCrystal_I2C lcd(0x20, 6, 5, 4,  11, 12, 14, 14, 15, NEGATIVE);

Could never be correct as the Px numbers/bit numbers only go from zero to seven.
There is no single way to hook up a PCF8574 port to a HD44780 interface and that is
why it is configurable. It allows for the different ways different vendors
hook up their boards.
You are using a mjkdz board which is a popular backpack. Unfortunately there
are a few different boards that use the name "mjkdz" on them.
However, the most popular one does use the constructor that you said
would not be the constructor. More than likely it is the correct constructor.
If it is, and it isn't working, then there could be other issues like the i2c address is incorrect
or the backpack hasn't been soldered properly.
You will need to track down what the issue is.

If you want to take the lazy way out you could run my guesser sketch:
http://forum.arduino.cc//index.php?topic=157817.msg1235230#msg1235230
and it will locate the i2c address guess the the constructor for you.

--- bill

Thanks for the clearing that up Bill.

I tried the sketch for guessing the lcd construct. It's interesting because no construct from there worked (I tried all the 6 different constructs), but it seems that is a communication between arduino and I2C. For example, at some construts LCD had only one blink of backlight and then off. At another constructs LCD stay with backlight on forever.

If you are running a windows system try changing your serial monitor line ending to "NEWLINE". When I used the guesser it showed multiple guesses but when it got to the correct one it flashed the backlight 3 times and displayed the correct CONSTRUCTOR on the lcd. It did not display any other constructs.

I had an issue with the same unit and the contrast was off so badly that it looked like it wasn't working

run the code below and take a jumper wire from ground to pin 3 on the lcd. If you can see a the display working properly, then you know you need to adjust the screw until it works.

#include <LiquidCrystal_I2C.h>
LiquidCrystal_I2C lcd(0x20, 4, 5, 6, 0, 1, 2, 3, 7, NEGATIVE);

in your setup

void setup()
{
 lcd.begin(16, 2);  
  lcd.print("Startup");
  lcd.setCursor(0,1);
  lcd.print("Version 3.1");
}
void loop()
{
}

@jasit
This is all good advice that (aside from the constructor) would also apply to standard implementations without an I2C adapter.

Your advice doesn't really apply in this particular case since he already had a viewable display ("The LCD only has backlight and 16 squares on the first line") but is still worth keeping in mind.

The key points that I see are:
(1) Keeping the code in setup() with nothing in loop() is very important when you have a display but the information is incorrect.

(2) Connecting pin 3 to GND as a test is important when the display is completely blank since most displays will then show something. It may be a single row (on a two row display) of blocks if the initialization is incorrect or it may be faint blocks in all positions if the initialization is correct but other display code is incorrect.

Don

psycho22:
I tried the sketch for guessing the lcd construct. It's interesting because no construct from there worked (I tried all the 6 different constructs), but it seems that is a communication between arduino and I2C. For example, at some construts LCD had only one blink of backlight and then off. At another constructs LCD stay with backlight on forever.

As noted in the guesser instructions,
The backlight will blink 3 times when the backlight pin/bit in the constructor is correct.
The 3 blinks will occur even if the other pin/bits are incorrect and the polarity is wrong.
So if you don't ever see 3 blinks of the backlight something else is likely an issue.
But if you do see the backlight blink 3 times and remain on, then it is possible
as Don, and jasit pointed out a contrast control/adjustment issue.
Some of these backpacks use a multi-turn pot that requires many turns
just to get it to the point of getting any pixels to show up.
If you are not comfortable connecting a jumper to pin 3 of the LCD,
you can also just adjust the pot all the way to the end where it stops.
If you run the guesser and don't see anything, adjust the pot all the way
to the other end and run the guesser again.
Once you get a display with some block characters it, turn the pot until you
see the characters.

Alternatively, if you see the backlight on and no characters or pixels, and
if you ground pin 3 of the LCD, and suddenly see pixels, then the pot
adjustment is wrong and needs to be adjusted.

How about showing a photo of your LCD and backpack so we can take a look at it?
This will allow us to see which backpack you have and check the orientation and soldering.
I've seen cases where the backpack has been soldered upsidedown and cases where
the soldering was bad.
Either of those will cause the lcd to not work correctly.

It would great to see both sides of the backpack & LCD so we can see
the soldering of both the LCD and the backpack.
I needs to be close up clear photos so we can actually see the soldering.

--- bill

Here's the photo's.

20140312_155124.jpg2560×1920 545 KB

LCD connected to Arduino and the backpack.

20140312_183335.jpg1920×2560 1.15 MB

20140313_220223.jpg1920×2560 545 KB

exact same one I have, did you try the jumper wire from GND to Pin 3? I looked at the solder job, kinda looks like you heated just the pins and not the lcd board , the lcd board should have alot more solder on it.

jasit:
exact same one I have, did you try the jumper wire from GND to Pin 3?

Clearly the jumper test is not needed. You can see pixels on the display.

In looking at the photos, I immediately see a few things.

• The orientation (pin 1 location) looks correct
• The pot is a multi turn pot so it may take many turns to adjust the contrast.
• Many of the solder joints on the LCD module look bad.

With a good solder joint the solder should flow out and you shouldn't see any of the
gold around the hole where the solder is attached to the header pin.
The connections should look more like the connections on the backpack.

You need to go back over the solder connections on the LCD panel to get
the solder to melt & flow out a bit more.

--- bill

I can see at least two pins that have not been soldered. I think you need to take a close up photo of the solder joints so we can see it from directly above instead of from an angle. Clearly the soldering has some "issues".