Anyone else experiencing bad displays? In two orders I have 3 of 3 bad and 1 of 2 (4 out of 5). Displays light up, display the standard two rows of squares, then nothing. The contrast has been adjusted, all it does it erase the squares. No characters show up. These displays are plugged into a lab unit where I test megas and displays, so I know I have a working system.
thanks
I find that hard to believe.
Do you have any working displays? If so then get it to display a simple message on the first row, crank up the contrast to maximum (darkest), and then disconnect the power to your Arduino.
Try not to disturb the wiring as you substitute one of the supposedly defective displays. Don't make any changes to the program even if the display geometry is different and reapply the power. You should see the same message.
Don
Many working displays and many working systems. This is not a problem on my end.
The reason I asked the question is because it appears that the displays may be functional but that some recent small change in the I2C clock timing or some other small tweak is making them difficult to talk to. I'm even suspicious of my connector/header. So I've swapped 4 of my older displays and they all work. It's just this new batch (from two vendors) in the last month that have problems.
You didn't mention I2C in your header or in your original post. That makes a big difference. Have you tried the 'HD44780' library?
Don
Also, have you run an I2C scanner to confirm the I2C addresses? The hd44780 library, usually, will automatically find the I2C address and suss out the I2C expander to LCD pin wiring.
All my units are single display. I have 13 of them in running controllers throughout the house, no problems. I have an uneasy feeling that there might be an address change or some other gremlin in these new units. The code I've been using is pretty simple:
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
#define I2C_ADDR 0x27
//Initialise the LCD
#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
LiquidCrystal_I2C lcd(I2C_ADDR, En_pin, Rw_pin, Rs_pin, D4_pin, D5_pin, D6_pin, D7_pin);
//----------------------- setup ---------------------------------
void setup() {
// Switch on the backlight
lcd.setBacklightPin(BACKLIGHT_PIN, POSITIVE);
lcd.setBacklight(HIGH);
lcd.begin(20, 4); // initialize the lcd
...
...
I had a different problem a month ago and a forum member noticed my LCD code and said he thought my code wasn't up to snuff. Seems to work for me, but I'm open to ideas.
floresta, thanks for the "Have you tried the 'HD44780' library?" I have not, maybe I should?
Dr_Quark:
All my units are single display. I have 13 of them in running controllers throughout the house, no problems.
You have been extremely lucky.
This line:
LiquidCrystal_I2C lcd(I2C_ADDR, En_pin, Rw_pin, Rs_pin, D4_pin, D5_pin, D6_pin, D7_pin);
configures that library.
It tells the library not only the i2c address but also how the PCF8574 chips is wired to the LCD.
If any of that information is incorrect for the device you have, it won't work.
You have been lucky so far that all the devices you have purchased had matching i2c address AND pin mappings.
Different manufacturers use not only different i2c addresses but also different pin mappings.
The issue you are having is that the library configuration you are using is incorrect for your new devices since your LCD new devices are different from your previous devices and will require different constructor parameters.
i.e. you are telling the library incorrect initialization parameters for the new devices you have.
To use that library, you will need correct the constructor to match the device you have.
You must make sure the parameters exactly match your device h/w.
This means you must:
The reason Don said to use my hd44780 library is that it can auto detect the i2c address, pin mappings, and backlight active level by probing the backpack.
This means you don't have to hard code the configuration to a specific h/w.
And because the auto configuration is done at run time, you can swap out devices and the library will figure it out the next time the Arduino powers up.
It also includes a diagnostic sketch that will test the i2c signals and the internal LCD RAM to make sure the library and LCD device are communicating.
The library is available in the IDE library manager.
I would highly encourage reading about the library before blindly trying to install/use it as this library is a library package that supports multiple h/w interfaces.
You can read more about it here: GitHub - duinoWitchery/hd44780: Extensible hd44780 LCD library
The library also includes a "Documentation" sketch that provides links to lots of additional information.
You can bring int up in the IDE after installation.
The i/o class for a PCF8574 backpack is hd44780_I2Cexp
The documentation & wiki explains where to locate the examples for that i/o class as well as the diagnostic sketch.
BTW as an aside, these lines of code should not be used:
lcd.setBacklightPin(BACKLIGHT_PIN, POSITIVE);
lcd.setBacklight(HIGH);
setBAcklightPin() is obsolete and should no longer be used. The full constructor should be used which includes the backlight pin and polarity.
setBacklight() does not take a HIGH/LOW argument but rather a dimlevel 0-255.
When sending it HIGH you are asking the library to create a very dim backlight. The only reason the backlight is on, is that the backpack does not support dimming and so it gives the dimmest it can do which is full on.
Unless you want dimming, you should use backlight() and noBacklight() API functions.
I have yet to encounter an I2C backpack where the controller wasn't wired in the "standard" way (such that the liquidcrystal_I2C library that doesn't have an option to specify the connections between PCF8574 and LCD works)
However, there are two common I2C addresses used, depending on whether it's a PCF8574 or PCF8574A... Check that. I got screwed on that recently.
DrAzzy:
I have yet to encounter an I2C backpack where the controller wasn't wired in the "standard" way (such that the liquidcrystal_I2C library that doesn't have an option to specify the connections between PCF8574 and LCD works)
Then you either haven't played with very many devices or you have been very lucky.
There is no "standard" way to wire the PCF8574 to the LCD and that is the problem.
I have seen (and actually have) devices with 5 different pin mappings and back-light control.
While the pin mappings and active level backlight control used by the LiquidCrystal_I2C library available in the IDE library manager is popular, there are two other pin mappings and backlight control that are also quite common.
The LiquidCrystal_I2C library hard codes the pin mapping to a popular mapping.
fm's newLiquidCrystal LiquidCrystal_I2C class took the approach to support any backpack but it must be manually configured.
hd44780 took the approach to automatically figure everything out including the i2c address.
The OP was using newLiquidCrystal LiquidCrystal_I2C and had it configured to match the pin mappings used by LiquidCrystal_I2C.
But there are other backpacks that use different mappings and active level that are common.
The backpacks commonly sold under MJKDZ or GYI2LCD use the lower nibble rather than the upper nibble and use active low for the backlight rather than active high.
The backpacks sold under the name "LCM1602" that often come with 20x4 LCDs use the same pin mapping as what is hard coded in the LiquidCrystal_I2C library but use active low for backlight control rather than active high.
But there is so much copying and brand spoofing going on in these types of products that even a given name printed on the backpack doesn't mean much. I've got two backpacks that have the same name printed on them but use different pin mappings.
So you never really know what you may end up getting.
With the hd44780 hd44780_I2Cexp i/o class, it doesn't matter.
If you have a single LCD device, you plug it in and it should "just work", regardless of the i2c address, pin mapping, or backlight active level.
--- bill
Karma to all. I suspected the sort of issue (out of date library, etc.) you guys describe. I'll check out using the hd44780 library. Fortunately, the one bad display that I've reported to the vendor also had a bad solder connection that has to be pressed on to work. I'll see if I can get the other 3 to function with new code.
Dr_Quark:
Fortunately, the one bad display that I've reported to the vendor also had a bad solder connection that has to be pressed on to work.
I've seen issues like that before.
A quick touch up with a soldering iron should fix the issue.
I've seen cases where the PCF8474 chip had poor soldering and some pins were not making contact with the solder pad.
I'll see if I can get the other 3 to function with new code.
I'd recommend first running the I2CexpDiag diagnostic sketch to test them.
--- bill
Partly solved: One of the new displays (marked 2004A-1 with "MH" on the driver board) was shorted to the mechanical display attachment tabs. The tabs are in a new position where they can touch the 2-pin display power connector. This board was at address 0x3F, but once I got it working it had a small group of pixels in the center of row 0 and row 1 that are bad.
An identical board, from the same vendor in the same order, was at address 0x27. I guess I'm going to have to do an I2C address search during setup() if I want to use these as plug and play.
One remaining issue: some of the boards are plug and play, in the sense that I can unplug one and replace with another and the display comes alive with the current messages. Others require that the Arduino be reset in order for the messages to appear.
All of the above is based on using the code above, the "out of date" stuff. I'm still working on understanding all the functions in the HD4470 library.