Enhanced LiquidCrystal

Modifications to LiquidCrystal for the Arduino

I made several modifications to the LiquidCrystal library module from Arduino17:

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.

Directions for the future
I see no purpose to retaining the 8 pin interface options. In theory, by sending 8 bits at a time, things would proceed faster. However, even in the slowest situation output to the LCD goes faster than the eye can follow. The slowest situation would be using the 40x4 LCD, doing a scrollDisplayLeft() or scrollDisplayRight() and then printing 160 characters. When the display has been scrolled, the software actually calls setCursor internally with every character sent to the LCD, so you would be communicating 480 items to the LCD in that instance. As I have tested the various interfaces with the various shapes of LCDs, I have reflected many times on the likelihood that no one else has tried the 8 bit interfaces for some time. Don Weiman argues that inclusion of both 4 and 8 bit interfaces makes the code harder to read. I am more motivated by the idea that the 8 bit interface takes up Arduino RAM and pins but contributes essentially no additional function.

Thanks
Certainly my efforts would not have been possible without the help and prior efforts of David Mellis, Limor Friede, and Donald Weiman. Don was particularly patient in guiding me through the idiosyncracies of the HD44780 based LCDs and especially in supplying an example of how the busy flag could be tested.

available at healthriskappraisal.org/LiquidCrystal440.zip

http://healthriskappraisal.org/LiquidCrystal.zip

I would like to try this out, but the .zip is not found when I click the link!

Should it be available there now?

1 Like

Nevermind, I noticed in the original post that the file is named LiquidCrystal440.zip. I was able to download that one.

http://healthriskappraisal.org/LiquidCrystal440.zip

whew. I was afraid the computer I use for a server in my basement had gone down. I'm on vacation and there would be no way to reboot for a week. It usually runs without problems for months.

The original link (in the first post) wasn't a bona fide link because of a restriction on first posts to the Arduino forums. for some reason, the first time you post you can't include a link. So lurk, ready, study and finally post when you have something to say is deprecated behavior.

It does look like the server will be down until 2/7 when I get home.

Arghh, damn, you couldn't send me the library could you? I am feeling impatient! PM me if you could.

I have just picked up a 20x4 LCD and would like to get it working.

Thanks,

Mowcius :wink:

John:

I will send him a copy.

Don

Yeah to earlier post I meant 40x4 not 20x4... :stuck_out_tongue:

Thanks. :wink:

Mowcius

Ok, I have got hold of a 40x4 LCD. It was apparently made by Nan Ya Plastics Corp (well it says that on it), but after a long google search I found nothing for any part numbers or other info.

Well I then looked around for displays that looked similar and came across this one: Lumex Inc. - An ITW Company which looks very similar if not identical. Anyway I connected up the rw, rs, en1, en2 and four data lines (pins 1-4) and using the library, defining it as 4 rows and 40 columns I got it to display something. At first I just got a load of random characters (well 1/4, 1/2, ? etc) and two flashing cursors. After removing power and resetting I just got two flashing cursors in random positions, changing each time I reset.

These pictures will explain better:

Anyone got any idea of why this is happening/anything I can try?

Mowcius

... and four data lines (pins 1-4) ...

It looks like pin 1 = D7, Pin 2 = D6, Pin 3 = D5 and Pin 4 = D4. Is that the way you interpreted (and connected) it? Are you sure? Did you doublecheck it? Did you rip all the wires out and put them back?

Don

I connected 1,2,3,4 on the display to 1,2,3,4 data on my arduino (pins 8,7,6,5 just to be confusing).

I then adjusted the code for 20x4 and set the pins to what I had connected. I will have a play around with different configurations today and I will see what I can come up with.

Mowcius

Ok, I got it sorted. Yeah I had the 4 data lines the wrong way round. It is now working like a dream!

I have however tried to connect it up to my duino644 board and it will work on one 'port' but not the one I want to use it on. I have checked (about 4 times at least) to make sure that the connections are right and the pins are not being used for anything else but I can't get it to work. The library obviously does not need PWM pins (it worked on the other port with no PWM pins) but are there any specific types of pins it requires?

Or has anyone got any other ideas? :wink:

Mowcius

The server is back up. I constructed a tiny benchmark to compare speeds of the different interfaces. I wrote 80 characters, then 80 blanks, looped through it 20 times. Of course it goes too fast to read, but here is what I measured:
8 data pins + RW 432 milliseconds
8 data pins - RW 641 milliseconds
4 data pins + RW 719 milliseconds
4 data pins - RW 1038 milliseconds
The options with RW are testing the LCD busy flag, of course, so testing the flag is about 1/3 faster. Again all of the options go faster than you can read. And if complex calculations were interspersed with sending the characters to the LCD you would see even bigger speed increases.

Yeah thanks a load for the library. My 40x4 has been a great new (free) toy!

I haven't got an immediate use for it but I am thinking of a 4 line, big number clock with email alerts and other info...

Mowcius

John:

8 data pins + RW 432 milliseconds
8 data pins - RW 641 milliseconds
4 data pins + RW 719 milliseconds
4 data pins - RW 1038 milliseconds

I don't think there should be that big a difference between the 8-bit and the 4-bit speeds for the same RW configuration. I haven't checked your code but I hope you took into account the fact that there is no delay (or busy check) required between the sending of the high nibble and the sending of the low nibble.

Don

One more option for connecting the 40x4 LCD that I realized was there--not a change to the code but just using the fact that internally the flag for the RW line not having been passed is 255.

LiquidCrystal lcd(RS,255,Enable1,Enable2, data3,data2,data1,data0);

which saves one pin in the interface. Again it runs about 1/3 slower this way.

I AM checking the busy flag between nibbles. When I change that, it does speed things up by about 1/3. I have seen a couple of odd characters on the screen though. I will run this through the complete test procedure.

I'm impressed once again at how perceptive you are about problems with interfacing these LCDs!

Thanks

Don Weiman pointed out that the benchmark was slower than it should be for the 4 data line options and correctly intuited that I was checking the busy flag between nibbles. He was exactly right. I have updated the zip file and the new benchmark data is:
8 data pins + RW 431 milliseconds
4 data pins + RW 532 milliseconds
8 data pins - RW 641 milliseconds
4 data pins - RW 687 milliseconds

The standard library routine also includes an unnecessary delay between nibbles (calling pulseEnable for each nibble includes the 100 microseconds delay there).

Thanks again to Don

Looks like your site is down again.
I'm not able to download tried yesterday and today.