As stated in the title I have issues with lcd.print and string variables. I have no problems with
lcd.print("hello world");
But if say I try
String a="hello world";
lcd.print(a);
I get one ascii character on the screen. I have tried several LCD libraries as I know some changes in the IDE broke the original libraries due to a return (0) issue but they all produce the same result.
I have searched the forums intensely but I cannot find this particular problem.
Some additional info,I use an Arduino nano, and a 20x4 LCD with an I2C adapter.
Things I have tried:
-Converting string to character array and displaying character by character to the screen by for loop.
-using f Matilda (?sp) library -all versions
I would really appreciate your help as it's driving me nuts.
There are so many third party "LiquidCrystal_I2C.h" libraries and most of them are buggy.
I suggest that you install the "HD44780" library via the Library Manager.
The hd44780 library will automatically self configure itself, including the i2c address and pin mappings.
It includes several features not available in other libraries and is also faster as the Arduino can run in parallel to LCD commands.
The i/o class for i2c backpacks is hd44780_I2Cexp
I'd recommend running the included I2CexpDiag sketch first to verify that the library is able to talk to the LCD.
Thank you for your replies.
David, the highest version of Malpartida's library on bitbucket is 1.3.5. Could you please give me a link to your version?
I have otherwise implemented the hd44780 library as you both suggested. It works fine for the simple test sketch thus indicating to me that the problem lies in my actual sketch.
I have a sketch which communicates with an HC05 Bluetooth adapter that is in AT mode via software serial. The idea is to have the display show what the HC05 is echoing in response to commands in the serial monitor. I built the string up character by character while the BTserial is available. The serial monitor confirms the string is OK, but the screen is displaying the last character only(ascii equivalent of NL). If I include a delay I can see that it is displaying the entire string but overwriting at the same cursor position, which leads me to suggest that the issue lies in the lcd.setCursor command?
Is there something painfully obvious you see in my code? (PS. my programming experience is in Matlab and Turbo Pascal. I am still trying to learn C++)
Many thanks,
MTech
#include <SoftwareSerial.h>
#include <Wire.h>
#include <hd44780.h>
#include <hd44780ioClass/hd44780_I2Cexp.h>
SoftwareSerial BTserial(8,9); // RX | TX
byte inData;
char inChar;
String BuildINString="";
char c="";
boolean NL = true;
hd44780_I2Cexp lcd;
void setup()
{ lcd.begin(20,4);
lcd.backlight();
Serial.begin(9600);
Serial.println("Arduino is ready");
// HC-05 default serial speed for commincation mode is 9600
BTserial.begin(38400); //AT mode
}
void loop()
{
// Keep reading from Arduino Serial Monitor and send to HC-05
if (Serial.available())
{ c = Serial.read();
BTserial.write(c);
}
//This part accumulates the characters from the HC05 TX in a serial fasion and concats a string(BuildINstring) out of them
BuildINString="";
if (BTserial.available()>0)
{ inData=0;
inChar=0;
inData = BTserial.read();
inChar = char(inData);
BuildINString = BuildINString + inChar;
// Echo the user input to the main window. The ">" character indicates the user entered text.
if (NL) { Serial.print(">"); NL = false; }
if (inChar==10) { NL = true; }
}
Serial.print(BuildINString);
lcd.setCursor(1, 1);
lcd.print("This works fine"); //This prints fine to screen
lcd.setCursor(1, 2);
Serial.print(BuildINString); //This confirms that string is ok in serial monitor
lcd.print(BuildINString); //This gives single ascii character???
//delay(500);
}
I installed my Malpartida library some while ago. (October 2015)
The Malpardita library does not appear on the Library Manager.
It is not obvious what version I have.
But the real problem is that there are multiple libraries with exactly the same names.
Bill Perry's HD44780 library is supported by the Library Manager.
I can see that I have v0.9.0 and that it is up to date.
Personally, I think that it is important to use unique and intuitive Class names.
Then you would know what you are using e.g. from the Library Manager.
In practice, you only mention the Library name twice in a sketch. Once in the include and once in the constructor().
david_prentice:
I installed my Malpartida library some while ago. (October 2015)
The Malpardita library does not appear on the Library Manager.
It is not obvious what version I have.
It doesn't have a library.properties file which tells the library manager the version of the library.
If you got the library in october 2015, it is probably 1.3.4
But the real problem is that there are multiple libraries with exactly the same names.
Yep. Seems silly that so many people used the same or similar names for their library.
This is one of the big reasons I created hd44780. A library that is easier to install, easier to use, and does not interfere with any other library.
That said, fm's library is a very different from all the other "LiquidCrystal" type libraries in that it was done to work as a LiquidCrystal replacement.
It drops in and transparently replaces LiquidCrystal with no, literally ZERO, changes required to any existing LiquidCrystal sketches. It also provides other capabilities for other i/o interfaces.
Keep in mind that it was done long before the IDE Library manager existed.
And at the time, it was a big leap forward over other hd44780 LCD type libraries.
Now that the library manager exists, its required manual installation and some of its dependencies on file locations of IDE include files makes it a bit tricky to install and it can have issues with some cores on certain IDE versions.
Because it is a LiquidCrystal library replacement, it won't ever be able to use the library manager as the Arduino team only allows a single library with a given name and would never allow a 3rd party library to "steal" their LiquidCrystal name. Also, the goofy way the IDE uses and locates "libraries" would get confused if fm's library were installed by the library manager with another name like "NewLiquidCrystal" since there are header file name collisions with other libraries.
Given the direction the IDE has taken over the past few years, NewLiquidCrystal has kind of been painted into a corner that is difficult to get out of.
Also, there are several copyright and licensing violations with the NewLiquidCrystal library.
At this point, I'd suggest to people to use libraries in the library manager whenever possible.
For i2c backpacks on hd44780 LCDs, that would be using LiquidCrystal_I2C or my hd44780 library with my stronger recommendation for hd44780.
hd44780 will see an update in the next week or so.
Besides some minor bug fixes and cleanup, the main features is it adds support for AVR PROGMEM for createChar() and adds support for some new Noritake VFDs.
It will either be 1.0.0 or very close to it. The goal is for it to be the 1.0.0 release.
Bill, great job on the library. It's really easy to use and auto detects the pins and address. This will definitely help not just novices to get their LCD screens running right away, but many other people who are not exactly sure what LCD screen they have. We need to spread the good word as I must admit that when I first started using the LCD screen, hd44780 was not the first name I typed into the search bar.
The LCD Display (QAPASS with I2C module) shows just a ">". If I use the LiquidCystal_I2C library, it shows a "&" with the same code, so similar unusable.
If I do this, it shows the "ein" respectively "aus" correctly:
The diagnostic sketch shows this on the LCD:
LCD:0 (0x3F) + the uptime
This is the output of the serial monitor:
Serial Initialized
--------------------------------------------------------------------
I2CexpDiag - i2c LCD i/o expander backpack diagnostic tool
--------------------------------------------------------------------
hd44780 lib version: 1.1.0
--------------------------------------------------------------------
Reported Arduino Revision: 1.8.10
CPU ARCH: AVR - F_CPU: 16000000
--------------------------------------------------------------------
SDA digital pin: 18 A4
SCL digital pin: 19 A5
--------------------------------------------------------------------
Checking for required external I2C pull-up on SDA - YES
Checking for required external I2C pull-up on SCL - YES
Checking for I2C pins shorted together - Not Shorted
--------------------------------------------------------------------
Scanning i2c bus for devices..
i2c device found at address 0x3F
Total I2C devices found: 1
--------------------------------------------------------------------
Scanning i2c bus for all lcd displays
LCD at address: 0x3F | config: P01245673H | R/W control: Yes
Total LCD devices found: 1
--------------------------------------------------------------------
LCD Display Memory Test
Display: 0
Walking 1s data test: PASSED
Address line test: PASSED
--------------------------------------------------------------------
Each working display should have its backlight on
and be displaying its #, address, and config information
If all pixels are on, or no pixels are showing, but backlight is on, try adjusting contrast pot
If backlight is off, wait for next test
--------------------------------------------------------------------
Blinking backlight test: to verify BL level autodetection
If backlight is mostly off but
you briefly see "BL Off" on display with backlight on,
then the library autodetected incorrect BL level
and the library cannot autoconfigure the device
--------------------------------------------------------------------
Displaying 'uptime' on all displays
Sounds like the diagnostic passed.
Your code seems to work as expected on the LCD modules I have, but I don't have the one you have.
You have a different issue.
Start a new thread, and in that thread post some photos of your LCD module and of the display so we can see what the display looks like with your code running.
...
bool HHein; //true or false
...
char HHeinOut; //should be a char*
...
//HHein = digitalRead(HHeinPin);
HHein = LOW; //LOW happens to have the same value as false
if (HHein == HIGH){ //HIGH happens to have the same value as true
HHeinOut = "ein";
}
else {
HHeinOut = "aus";
}
...
lcd.print(HHeinOut);
...
The AVR C++ compiler will probably compile the bool assignments without complaint.
The optimiser will remove the "ein" statement completely
ALL Compilers should complain about assigning a char* to a char variable
The print() statement will be garbage.