There used to be no such thing as LCD.println before Arduino 1.0 (or around that version). In Arduino 1.0 (or around that version), the LiquidCrystal library was modified with this line:
class LiquidCrystal : public Print
This is incorrect. I just went back and looked. The LiquidCrystal library was added in IDE 0012 (Sept of 2008)
and from its very beginning until today's 1.0.1,
the Print class was always inherited. (I just looked at every single IDE release since 0012)
The issue is that the LiquidCrystal library inherited the Print class but failed to implement everything that the
Print class supports and can attempt to use. As a result, things like lcd.println() don't provide the expected/desired behavior.
Don, with C++ inheritance, if you choose to inherit a class *ALL* the public
functions and members in that class get dragged in.
Think of it like pulling in a gigantic set of Assembler macros.
The way the Print class works, the layer below it really does not know anything about println() or that
println() is being called by the sketch. The lower layer, LiquidCrystal in this case, only sees calls to write()
as that is the interface between Print and LiquidCrystal.
Print implements println() and then converts it to a series of write() calls.
So from LiquidCrystal's point of view, it cannot tell the difference between a sketch doing:
Because in both cases LiquidCrystal only sees the calls to write().
Rather than write the needed code in LiquidCrystal to fully support all the inherited functions in the Print class,
(which meant writing code to handle newline processing and line wrapping)
the developers took the easy way out and chose to simply say that println() isn't supported.
They also took a short cut by simply not documenting println().
What they should have done instead is to explicitly document that LiquidCrystal supports all the functions in the Print class (with a reference to the Print class documentation) but, state that println() is not implemented in LiquidCrystal and therefore
is not supported and if used will create undesired results.
When they chose to not write the additional code to support println() (new line processing), they could have added
a tiny amount of code to swallow the <CR> and <LF> characters to at least avoid the junk characters
but then there would never be a way to send 0x0d and 0x0a to the display, which might be desirable in
There are some Arduino hd44780 libraries out there like this one:http://www.pjrc.com/teensy/td_libs_LiquidCrystal.html
that have the code to support newline processing and line wrapping.
When using those libraries that support newline processing, println() will work as expected.