[SOLVED] Only blobs, using nano and Emall-4u backpack.

Im using a nano board v3.0
Malpartida v1.2.1 library

This is the backpack I2C im using:
http://www.ebay.com/itm/390527388644?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2648

The LCD itself is a 20x4 (J204A):
http://www.ebay.com/itm/290703654171?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2648

So far, the LCD lights up, gives me blobs on rows 1 and 3 (Not initializing). I ha no problems getting the LCD up without I2C.

I traced the pins. *(Pin on the chip)

BACKLIGHT_PIN 3 (7)*

En_pin 2 (6)
Rw_pin 1 (5)
Rs_pin 0 (4)
D4_pin 4 (9)
D5_pin 5 (10)
D6_pin 6 (11)
D7_pin 7 (12)

For now im running this code. It does turn the light on and off.

#include <Wire.h>
#include <LCD.h>
#include <LiquidCrystal_I2C.h>

#define I2C_ADDR    0x20  // Define I2C Address where the PCF8574A is
#define BACKLIGHT_PIN     3
#define En_pin  2
#define Rw_pin  1
#define Rs_pin  0
#define D4_pin  4
#define D5_pin  5
#define D6_pin  6
#define D7_pin  7

int n = 1;

LiquidCrystal_I2C	 lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin);

void setup()
{

  lcd.begin (20,4);
  // Switch on the backlight
  lcd.setBacklightPin(BACKLIGHT_PIN,POSITIVE);
  lcd.setBacklight(HIGH);
  lcd.home ();                   // go home

  lcd.print("SainSmart I2C test");  
  lcd.setCursor ( 0, 1 );        // go to the next line
  lcd.print("F Malpartida library");
  
  

  
 }

void loop()
{
  
    delay(1000);
    lcd.setBacklight(LOW);
      delay(1000);
    lcd.setBacklight(HIGH);
}

#define I2C_ADDR    0x20  // Define I2C Address where the PCF8574A is

Well something is wrong here since the 'A' version of the device has addresses between 0x38 and 0x3F.

Don

floresta:

#define I2C_ADDR    0x20  // Define I2C Address where the PCF8574A is

Well something is wrong here since the 'A' version of the device has addresses between 0x38 and 0x3F.

Don

The comment is not up to date. I got 0x20 from the supplier and I2C-detected it aswell..

Edit: It's a PCF8574T BTW..

The comment is not up to date.

You got a response based on the information that you supplied.

Don

I have not used that library but this line looks strange.

LiquidCrystal_I2C	 lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin);

If I were writing the library I would have arranged it with En and Rs swapped to match the device itself.

LiquidCrystal_I2C	 lcd(I2C_ADDR,Rs_pin,Rw_pin,En_pin,D4_pin,D5_pin,D6_pin,D7_pin);

Don

floresta:
I have not used that library but this line looks strange.

LiquidCrystal_I2C	 lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin);

If I were writing the library I would have arranged it with En and Rs swapped to match the device itself.

LiquidCrystal_I2C	 lcd(I2C_ADDR,Rs_pin,Rw_pin,En_pin,D4_pin,D5_pin,D6_pin,D7_pin);

Don

Seem logical. Sadly it made no difference…

Seem logical. Sadly it made no difference...

But which one is correct?

You haven't provided a link to the library so I can't check it myself.

Don

floresta:
I have not used that library but this line looks strange.

LiquidCrystal_I2C	 lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin);

If I were writing the library I would have arranged it with En and Rs swapped to match the device itself.

LiquidCrystal_I2C	 lcd(I2C_ADDR,Rs_pin,Rw_pin,En_pin,D4_pin,D5_pin,D6_pin,D7_pin);

Don

Don,
The library is fm's library. He stated that right up front
and in the other thread.

Yes indeed the i2c constructor and the parallel constructor define the LCD pin parameters in different orders.
The parallel is:
lcd(rs, rw, en, d0, d1, d2, d3, d4, d5, d6, d7); // 8 bit
lcd(rs, en, d4, d5, d6, d7); // 4 bit

The i2c is:
lcd(addr, En, Rw, Rs, d4, d5, d6, d7 [, backlight, polarity]); // old constructor didn't support BL or polarity

The SR3W interface uses the same order as the i2c code.


puttelino,
If the pin numbers between the LCD and the PCF8574
in your table are correct then the bit numbers you used in the constructor appear to be correct.

What value is the pullup resistor?
To me the photo it looks like
Yellow/Orange/Black = 43 ohm?
Or possibly
Yellow/Red/Black = 42 ohm?

Which is too low. I think min is like 1k.
Have you measured the resistors just to verify that they
are what you think they are?

With the blinking in the sketch
Are you saying the backlight is now blinking at 1 second intervals?
If you change the delays in loop() does it change accordingly?


Not that it will matter in this case but
I would use the newer constructor that includes the bit number of the backlight and the polarity
and not use the setBacklightPin() - that function it is obsolete.
I'd also not use the setBacklight() function particularly with the value HIGH.
HIGH is for digitalWrite() and not for this function. setBacklight(brightvalue) is to set the
intensity of the backlight, which this hardware does not support.
If it did, it would be very dim when a value of 1 is used.
A better function to use would be backlight() and noBacklight().
Using those ensures that the code will work correctly even on interfaces
that do support dimming as those function are guaranteed to turn the backlight
on full bright or completely off regardless of whether the hardware supports dimming.

--- bill

The library is fm's library. He stated that right up front
and in the other thread.

I don't know which version of which library he is using. The best way to provide reliable answers is to not make any assumptions.

Yes indeed the i2c constructor and the parallel constructor define the LCD pin parameters in different orders.

Is there some reason that he did this? Maybe it's those funny cigarettes.

Don

The SR3W interface uses the same order as the i2c code.

Why did he use that order there?

Also - I guess he didn't do a Google search for SR3W before he chose that abbreviation.

Don

bperrybap:

floresta:
I have not used that library but this line looks strange.


puttelino,
If the pin numbers between the LCD and the PCF8574
in your table are correct then the bit numbers you used in the constructor appear to be correct.

What value is the pullup resistor?
To me the photo it looks like
Yellow/Orange/Black = 43 ohm?
Or possibly
Yellow/Red/Black = 42 ohm?

Which is too low. I think min is like 1k.
Have you measured the resistors just to verify that they
are what you think they are?

With the blinking in the sketch
Are you saying the backlight is now blinking at 1 second intervals?
If you change the delays in loop() does it change accordingly?


Not that it will matter in this case but
I would use the newer constructor that includes the bit number of the backlight and the polarity
and not use the setBacklightPin() - that function it is obsolete.
I'd also not use the setBacklight() function particularly with the value HIGH.
HIGH is for digitalWrite() and not for this function. setBacklight(brightvalue) is to set the
intensity of the backlight, which this hardware does not support.
If it did, it would be very dim when a value of 1 is used.
A better function to use would be backlight() and noBacklight().
Using those ensures that the code will work correctly even on interfaces
that do support dimming as those function are guaranteed to turn the backlight
on full bright or completely off regardless of whether the hardware supports dimming.

--- bill
[/quote]
[/quote]
Resistors are 4k6

Yes the backlight does what the codesays. I will post more at home!

Resistors are 4k6

How did you determine this?

Don

floresta:

Resistors are 4k6

How did you determine this?

Don

I used a multimeter.. And the engineer i got them from told me :slight_smile:

I found some new code, updated on the suppliers page (I2C supplier)

definitions in LiquidCrystal_I2C.cpp are incorrect and must be changed

#define LCD_BACKLIGHT 0x08
#define LCD_NOBACKLIGHT 0x00

#define En B00000100 // Enable bit
#define Rw B00000010 // Read/Write bit
#define Rs B00000001 // Register select bit

void LiquidCrystal_I2C::send(uint8_t value, uint8_t mode) {
uint8_t highnib=value&0xf0;
uint8_t lownib=(value<<4)&0xf0;
write4bits((highnib)|mode);
write4bits((lownib)|mode);
}

Still no mention of what library to use. I have sent a mail asking though…

So, beeing a newbie, could anyone explain to me what im supposed to do with this? :slight_smile:

EDIT: I searched through the mentioned file and changed about half of it until i reliazed i whould probably ask you guys first the values i FMs lib did not match the ones in my quote…

What really matters is how the i2c chip is wired up to the LCD.

The code fragment reference above does indicate a wiring.
From that code listed, you can see
the bit numbers:

3 backlight
2 Enable
1 RW
0 RS

And the data bits based on the nibble shift code use
4 D4
5 D5
6 D6
7 D7

Those bit numbers match the bit numbers you reported in your initial post.

--- bill

Sooo… :roll_eyes:

First i would like to thank you for all yout help.

The problem is now solved. Last time I checked the soldering between the pins on I2C and the LCD i found that one had i glitch so i soldered it better. I was getting ready to remove the I2C and keep going with my project. But i thought that i should check the pins once more. I foud that V0 and RS didn’t connect att all…

So, what can we learn from this thread? The picture sends a clear message…

bild.JPG