command(0x38); // function set: 8 bits, 1 line, 5x8 dots command(0x28); // function set: 4 bits, 1 line, 5x8 dots
The comments both indicate 1 line but the actual instructions fortunately set up the 2 line configuration which is almost always correct, not only for most 16x1 displays as mentioned above but also for both of the 20x4 displays that I have and most likely for all of the rest of them as well.
modify the case of the file so it matches the original name: LiquidCrystal.cpp
I suspect that the comments might need to be reduced in order to be accepted into the core
"I wonder if we should add an option for autohandling that too?"
this implies that the extra size of the .cpp program (due to the comments) has an effect on the size of the final program that gets loaded into the processor.
I see that the case is correct on the file that I have available for download.
Quote"I wonder if we should add an option for autohandling that too?"This gets into a whole different area that probably deserves it's own thread. If you look at LiquidCrystal.h you will see that two options were removed from (or never implemented in) LiquidCrystal.cpp. We probably ought to find out about that first.
wonders of a case-insensitive web server
refactor the duplicated code in the two different constructors
What is the reason for having one LCD program for both the 4-bit and the 8-bit interfaces?
It's much less effort to maintain a single code base for the two variants.
I expect the 8 bit version is supported for backwards compatibility with old applications, but I do wonder if anyone would really care.