Improvements to the LiquidCrystal library [imported]

[per1234]

This is Issue 196 moved from a Google Code project. Added by 2010-02-01T16:37:19.000Z by damellis. Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Medium, Component-Core

Original description

http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1264823411

"40x4 LCDs I added support for an LCD of 4 LInes and 40 characters. I think that if 24x4, 32x4 LCDs exist, they would also work with the software as I have modified it although I have not had the opportunity to test that. The 40x4 LCD (and any HD44780 based LCD with between 81 and 160 characters) will have 2 enable lines. To use an LCD with 4 lines and 40 columns you would declare your LiquidCrystal object as: LiquidCrystal lcd(RS,RW,Enable1,Enable2, data3,data2,data1,data0); at this time I don’t support 8 data lines nor do I support eliminating the RW line in this option.Then in the setup function you would call: lcd.begin(40,4);

Linewrap When you declare the dimensions of the LCD in your begin call, the LiquidCrystal library remembers how long the lines are. Now when it reaches the end of line 1, text wraps onto line 2 (not line 3 as previously).

16x4 LCDs The begin statement also correctly positions text at the beginning of the line on 16x4 (and 40x4) LCDs, which were not correctly handled before.

setCursor In the past setCursor selected a location in the HD44780’s RAM not actually a screen location. If you use any of the commands that shift the display left or right with the previous routines, then setCursor and print, text appears in an unexpected location on the screen. With the new software, if you call either scrollDisplayLeft() or scrollDisplayRight(), the LiquidCrystal package keeps track of the relationship between RAM and the LCD so that setCursor coordinates are pegged to a specific spot on the screen, rather than a spot in RAM. The sotware does not handle autoScroll, however. Call home() after autoScroll to restore the expected relationship between setCursor and the LCD screen.

Testing the LCD Busy Flag Previous versions of LiquidCrystal always used timed delays on the Arduino side of the interface to give the LCD module enough time to complete its operation. This version still does that if you tie the RW pin to ground and do not tell LiquidCrystal what that pin number is. If you do specify RW now, however, the software will poll the busy flag on the LCD module. Arduino operations may thus overlap LCD operations and potentially things may go a little faster.

Crazy 8 Addressing 16x1 LCDs often have an unusual address layout; these modules often have two 8 character halves and work best with this software if you declare them as lcd.begin(8,2); if you do that, then you can print(“abcdefghilklmno”); and have all the characters appear as you would like across the screen. If you use any of the scrolling commands, the bizarre addressing of these modules will manifest itself. For details follow the LCD Addressing link at web.alfredstate.edu/weimandn

Disadvantages The two real disadvantages I can see to the changes I have made are:

The code is longer than before. Much of the increase is in checkLcdBusyFlag() and this could be fairly easily replaced with delayMicroseconds(100);

1. The possibility that someone with a little 16x2 LCD is using the scrollDisplayLeft() or scrollDisplayRight() instructions to move data across the screen, but wants to write the data 40 characters at a time with a print statement. This version really does not let the user write data to the HD44780 DDRAM which is not visible. To accomplish a scrolling display with 40 characters per line, you would now need to write 16 characters, scroll the display, write a little more and so on.

There are going to be some incompatibilities between code that assumed that line 1 wrapped onto line 3, etc."

[per1234]

From "Helpful Horse" on 2010-07-08:

There are several versions that are available at http://code.google.com/p/liquidcrystal440/downloads/list My recommendation for -19 is the last version ('4bit'). It fixes one bug that I think is in the others (Paul Stoffregen found it reading the code, it only shows up when the 2nd enable line on the 40x4 LCDs is attached to pin 0). It has longer delays that support (rare) LCDs that work slower than the vast majority. I think that is desirable to avoid problems for the few who end up using those slower LCDs.

The places that might be controversial (vis a vis -19) it seems to me are: in LiquidCrystal.h there is a one line inline fcn overriding (); that supports the syntax lcd(15,1) to mean the same as lcd.setCursor(15,1) and is intended to complement use of Mikal Hart's Streaming library. It is 'weightless'--there is no additional code generated to support it.

The userbusy versions of the API. These are complex to use and explain. They add a little performance advantage which might be worthwhile in certain time-critical situations. It is very lightweight--the code to support it is almost all written by the user, in the user sketch, but not 'weightless'; there are 2 versions of the initial call to instatiate the LiquidCrystal object and a few lines of code to call the userbusy routine.

[per1234]

From damellis on 2010-07-08:

Any chance you can split out these improvements into separate patches and issues? For example, using the R/W pin (if supplied) to lower wait times would be a good, straightforward change, and the auto-wrapping of text could be nice too. Also, supporting 16x1 LCDs in a more intuitive way would be good. 40x4 LCDs don't seem that common (at least, SparkFun doesn't sell any), so maybe it's not needed in the core library?

[per1234]

From "Helpful Horse" on 2010-07-17:

http://www.nkcelectronics.com/character-lcd-module-40x4-yellowgr404.html

I will try to get a version that does not support the 40x4 and 27x4 displays tested and posted in the next 48-72 hrs.

[per1234]

From "Helpful Horse" on 2010-07-18:

I posted a version that eliminates 40x4 LCD support and the UserBusy test on the google code link above. I hope this works for you. It certainly simplifies parts of the code.

I do know that I wasn't the first to implement 40x4 support, but it had been done with much earlier versions of the code base that did not work nearly so well.

The code needs appropriate copyright notices added. Please do that.

I put comments in both the .cpp and .h file around lines I think should be eliminated when the name changes to LCD in 1.0

[per1234]

From damellis on 2012-06-02:

Yet another solution for 40x4 displays. Use inheritance to support 40x4 displays instead of a big "can do everything" library. The following patch enables inheritance on the lcd library: https://github.com/arduino/Arduino/pull/87 and https://github.com/manfredjonsson/LiquidCrystalAddons shows possible usages including 40x4 support.

[per1234]

NOTES:

The original forum post that was copied by damellis to create Google Code issue 196 is archived here: https://web.archive.org/web/20111118040932/http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1264823411

It looks like the "healthriskappraisal" website of the original code link has since been taken over by a third party using it for spam or malware (or the forum account was compromised?), so I recommend against visiting that link. It sounds like the code was later made available at http://code.google.com/p/liquidcrystal440/downloads/list

[per1234]

Linewrap When you declare the dimensions of the LCD in your begin call, the LiquidCrystal library remembers how long the lines are. Now when it reaches the end of line 1, text wraps onto line 2 (not line 3 as previously).

We now have a dedicated feature request for this: https://github.com/arduino-libraries/LiquidCrystal/issues/64

[buddywhitman]

Is someone working on this issue or can I start working on it?'