I have a project that uses a UNO R3 and a 20x4 display. Pretty much everything works fine, except that if I write to the LCD using (for example) lcd.println("Sensor error!"); the display will show Sensor error! but after that text, there will be two character blocks with garbage characters (they look like two backwards "C" characters on top of one another). If I just use lcd.print("Sensor error!"); all is well. If I want to display two lines:
lcd.println("Sensor error!");
lcd.print("Fix connections.");
The display will show the first line, then the garbage characters, then start what should be the second line right after the garbage characters.
Basically, it seems that a newline character is not being correctly handled. I'm using 1.6.5 version of Arduino IDE.
Hopefully, the pic I attached will show what I mean.
It appears that the println function just doesn't work for lcd, one has to use lcd.setCursor instead. Why is that?
It appears that the println function just doesn't work for lcd, one has to use lcd.setCursor instead. Why is that?
Because println appends the ASCII control codes for CR (carriage return) and LF (linefeed) to your string but the LCD controller does not interpret them as such.
The two 'garbage' characters represent what your particular LCD controller has in two of its it's RAM locations if you have not created any custom characters.
Your LCD was designed to display short one or two word messages, not lines of text as on a CRT.
Don
So it is simple.
Do not use println on the LCD. There is absolutely no need to do so anyway when you think about it.
Thanks for the clarification. In thinking about Paul__B's reply, it would be a nice feature to have the functionality implemented anyway, just so moving from a serial print environment to an lcd environment would be easier. I have often done initial work using the serial print function, then after the software is doing what I want, I port it to an LCD display. A 2x16 display may not work very well with l/f or c/r, but larger displays, and the ability to vertically scroll the display, would be nice. I'll have to see if I can come up with something!
I'll have to see if I can come up with something!
You may want to look at the LCD Addressing link at http://web.alfredstate.edu/weimandn for some background information.
Also keep in mind that the LiquidCrystal library does not correctly implement the cursor positioning on rows 3 and 4 of the 16x4 displays.
Don
davetelling:
A 2x16 display may not work very well with l/f or c/r, but larger displays, and the ability to vertically scroll the display, would be nice.
And that is precisely the point as floresta said in reply #2.
A 16 by 2 - or a 20 by 4 - display is not suitable for scrolling text; it simply does not have sufficient width or depth and it does not really have the requisite response time either. And line wrap to accommodate more than 20 characters is not really practical from a visual point of view.
If you want to do this, then you do not want the HD44780-based displays, you want a full screen TFT display - different hardware, different libraries.
Hmmm.. what a mess...
floresta:
You may want to look at the LCD Addressing link at http://web.alfredstate.edu/weimandn for some background information.Also keep in mind that the LiquidCrystal library does not correctly implement the cursor positioning on rows 3 and 4 of the 16x4 displays.
Don
I did take a look at this - it is quite convoluted. Paul__B has the right idea, I think - use a matrix display.
Paul__B:
And that is precisely the point as floresta said in reply #2.A 16 by 2 - or a 20 by 4 - display is not suitable for scrolling text; it simply does not have sufficient width or depth and it does not really have the requisite response time either. And line wrap to accommodate more than 20 characters is not really practical from a visual point of view.
I would disagree with this. There is value to supporting line wrapping and vertical scrolling.
The individual application writer should be the one to decide its value for his particular application.
There are certain applications where it can be quite useful.
Currently I've only seen one Arduino hd44780 LCD library library that supports it.
All the others took the easy way out and simply send the and characters directly to the display which is guaranteed to not work the way the user would expect.
And if you are clever in the way you handle vertical scrolling, you don't actually have to move/scroll the characters in display memory. You can simply change the starting memory address for the display.
It does require some additional smarts in the library code since among other things, the 0,row memory addresses are no longer simple constants.
--- bill
davetelling:
Also keep in mind that the LiquidCrystal library does not correctly implement the cursor positioning on rows 3 and 4 of the 16x4 displays.Don
setCursor(col,row) memory addressing changed starting in the IDE 1.6.0 supplied LiquidCrystal library so I'm not sure this is the case any more. (at least for that library)
The current memory addresses for the 4 lines is:
0x0, 0x40, 0x0+cols, 0x40 + cols
So if cols is 16 you get: 0x0, 0x40, 0x10, 0x50
which I believe is correct for a 16x4 display.
Also, starting with IDE 1.6.0 you can call setRowOffsets() to set the memory addresses of the 4 lines to be anything you want. So if there is an addressing issue, you can easily correct it in the sketch.
--- bill
setCursor(col,row) memory addressing changed starting in the IDE 1.6.0 supplied LiquidCrystal library so I'm not sure this is the case any more. (at least for that library)
That's good to hear. It only took 4 years to get this fix implemented (see [solved] 16x4 LCD: Characters in row 3&4 are moved to the right - Displays - Arduino Forum). Of course there had to be some slight changes made due to the NIH problem.
Now if we could get the default configuration mentioned in that same forum thread fixed we would be in fairly good shape.
The only other recurring problem I can recall is the fact that some, probably out-of-spec, devices don't work reliably in 4-bit mode. I'm not sure if this is a library problem or not but since it does pop up occasionally a flag that could be invoked to increase the delays a bit could be of help.
Don