I believe we are discussing how to help those new to LCDs get them to function using the Arduino IDE.
The fact is that there is no documented lcd.println() function provided by that IDE.
println() is in the Print class which comes with the IDE. It is inherited by the LiquidCrystal library.
The Print class is a bit of weird one. It is used by things like HardwareSerial, Softserial, LiquidCrystal,
yet it itself is not really documented.
In the documentation for the LiquidCrystal library the print class function println() was left
out since it wasn't supported by the supplied LiquidCrystal library.
But you will notice that it shows up in the HardwareSerial documentation.
This stems from the fact that the LCD controller itself does not inherently support the function and in fact treats the ASCII codes for <CR> and <LF> as displayable characters instead of control codes.
The LiquidCrystal library collects the information needed to implement such a function but currently doesn't use that information.
Kind of. While the LiquidCrystal library does receive the <CR> and <LF> codes, it does not have any context as to what they mean.
The Print class got a println() call. It "knows" that there is a newline sequence.
But the <CR> and <LF> codes are handed down 1 byte at time to the LiquidCrystal Library.
They might be a newline sequence or they might be a character is desirable to print.
The fact that the LiquidCrystal library inherits from Print class and thus permits the use of println() essentially makes things worse. Instead of barfing and spitting out an error message it just happily displays two unrelated characters on the screen and the uninitiated have no idea of the cause.
It isn't really an error. println() works and does call the lcd library.
The library isn't handling it as many people assume it might.
This is a more difficult thing to deal with and solve than would it would seem to be at first glance.
The problem is that you need to have both "raw" and "cooked" modes like real operating system drivers.
This allows the code to know if the characters are to be interpreted as potential commands or as literal simple characters to be
displayed. The Arduino environment never considered such needs so now things are stuck in the middle,
where the low level "driver" type libraries don't have modes but get handed these types of characters.
They can either interpret them as commands "cooked" mode (which is what the library on the Teensy site does),
or they can display them (which most do), or they could drop <CR> and <LF>.
The problem is there is no 1 single correct answer for what to do.
There are cases where any of those 3 options make sense.
i.e. sometimes you may really want to display character 0x0d on the display, an others
you may want a <CR> to wrap the location.
In my opinion the basic LiquidCrystal library should concentrate on implementing all of the capabilities of the LCD controller and no more. If people want a library that more closely emulates a CRT (or LCD) terminal that is fine, but I think it should be done in a different library.
That would be a bit limiting for most users.
Many users want to use the lcd display for displaying information, like strings and variables, etc....
The wimpy build model used in by the IDE makes it very difficult to have one library call another.
Even if the build model were done better, it would be more difficult for users to declare the needed
classes and objects to get one library to call another library or reference its objects.
As it is today and has been for several releases,
the LiquidCrystal Library (just like the HardwareSerial library) inherits the Print class.
This makes it much simpler to be able to do things like print a string or the value of a variable.
An unfortunate side effect is the newline issue on lcd displays when println() is called
because of the way the println() function is currently being handled (or not handled)
by the LiquidCrystal library.
We should concentrate or efforts in this thread on getting the basic LCD functions working.
I totally agree.
This thread should be how to get the LCD working with the LiquidCrystal library
and not try to solve the other software implementation issues.