Go Down

Topic: Wierd characters on display (Read 5325 times) previous topic - next topic


Oct 24, 2012, 07:18 am Last Edit: Oct 24, 2012, 07:30 am by bperrybap Reason: 1

IMHO, this should be done: println should instead of calling print then print(0d, 0a), call print then cursor(home), cursor(next line). This way lcd library needs to define cursor(home) to be setcursor(0,current row), and cursor(next line) as setcursor(column,current row+1). Since lcd library is not making use of cursor position, it can't be implemented. Then serial can define cursor(home) as write(od) etc.

It is an interesting idea/concept, but newline processing isn't that simple.
For example, there is also how to handle the display and cursor position
when the characters hit the edge of the line on the display (right side, when using a left to right orientation)
before a newline is sent.
Things like do you wrap and drop down a line when the edge is reached on a line or do you wrap to the beginning
of the same line or do you start dropping the characters.
Then there is what to do on the bottom line. Do you wrap back to the top line or start dropping characters or
do you scroll the existing text on the display and then wrap back to column 0 and erase any characters on the line.
In order to scroll the text up/down on a device like a hd44780,
you have to have a shadow buffer of all the characters on the display and re-write the data "scrolled"
to the display.

In the grand scheme of things, would support for these new cursor functions that Print could use
really be any different than simply using write(0xd) and write(0xa)?
It seems to be inventing a new way of doing the same functionality that could be handled with the existing
0xd and 0xa characters.
(other devices and libraries including other lcd & glcd libraries are handling newlines ok without the need for these new functions)

In order to handle line wrapping of long lines and scrolling I believe it would be too much of a burden
and start to get messy to have to communicate
the display dimensions to the Print class as well as have to configure it for newline, wrapping, and scrolling behaviors.
I think Print is ok as it is.
Print is fairly clean and simple as it lets the lower layer deal with any/all the newline, wrapping, and scrolling issues
of the device.

As a Quick & Dirty ugly but effective hack to prevent println() from being used,
the LiquidCrystal.h header file could add this line after the #include "Print.h"
Code: [Select]
#define println println_IS_NOT_SUPPORTED
While, it will create a little bit of a strange compiler error about the redefined function
not existing in the LiquidCrystal class, it will prevent the code from compiling.
Depending on the sketch code, the IDE  will jump to the line with the println() showing it as an error.
(Often it positions to the wrong line because the IDE is not handling the line numbers correctly when
it converts the .pde/.ino files to .cpp files)
(This seems to have finally been fixed in IDE 1.5)

--- bill


That's right Bill. All these new line features of line wraps are handled by the arduino serial monitor. By the way, my phi-panel serial Lcd keypad panel proudly handles all these with options you mentioned, such as scroll or back to beginning etc. You are right, all those features took a whole summer to develop, plus all the other features. I would recommend arduino serial monitor to support snail escape codes.
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter


There's another way to look at all of this.  The LiquidCrystal library is essentially tied to the HD44780 controller and it's instruction set.  The displays that are driven by this type of controller are intended to display short messages, typically the status of a device such as a printer.  They are not designed to be used as a computer terminal, that is, to display large amounts of text on multiple lines.  I'm not saying that no one uses them this way, but it's not what they were intended to do.

I feel that perhaps the LiquidCrystal library itself should be limited to implementing the HD44780 instruction set, one for one, with no embellishments.  There could be a separate library or libraries designed handle other cases such as terminal emulation and similar yet different controllers such as those used by New Haven Displays.

There can be limitations imposed by the addition of some of these features to the basic instruction set.  For example, the implementation of automatic line wrapping at the end of a line on a 16x2 or 20x2 character wide display means that you can't easily take advantage of storing a long string that includes the 'hidden' character locations for later display by means of shifting.


Go Up