Pages: [1]   Go Down
Author Topic: Reliable LCD Operation - finally?  (Read 1176 times)
0 Members and 1 Guest are viewing this topic.
Western New York, USA
Online Online
Faraday Member
**
Karma: 36
Posts: 4304
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

There have been many forum posts concerning LCD programs that either do not work at all or that do not work reliably.  A search on the Internet will show that this problem is not confined to the Arduino community.  You would think that with all the information available via the Internet that the problem would have been resolved years ago.  The fact is that almost all of the manufacturer's data sheets that I have found appear to be derived from the same source, with differences due mainly to editorial or typographical errors.  Also, almost all of the information that has been put together by individuals is just a rehash of the same data sheet information.

I have looked at dozens of programming examples on the internet and, in my opinion, virtually all of them fail to interpret the data sheet information correctly.  This includes the LCD libraries available on the 'playground' and it includes the official LiquidCrystal library.  The authors of the LCD libraries are NOT to blame.  Much of the information on the data sheets is ambiguous and some of it is wrong.  I am in the process of preparing an explanation of how I interpret the data sheet information and why I feel my interpretation is correct.  I'll get that up on the playground as soon as it is in usable form.  

Meanwhile, and the real reason for this thread, is that I have come up with a replacement for LiquidCrystal.cpp that I would like to make available to see if my reasoning is correct.  This is not a new library, it is just a rework of some of the existing code.  It uses the same constructors, variables, and functions.  There's nothing new in it, just some code additions that better implement the various data sheets as I interpret them.  You shouldn't have to change any existing program code that uses the LiquidCrystal library, and LiquidCrystal.h doesn't have to be changed either.

I know that I can chop my program up into pieces and put it into a thread, but there must be a better way.  I see that there is a 'code library' as part of the playground.  Is this the appropriate place for relatively untested code, and if so, would someone please outline how I go about utilizing it.  I hope my contribution will prove useful.

floresta
Logged

0
Offline Offline
Full Member
***
Karma: 0
Posts: 102
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

VERY interested!!!!
Logged

Bristol, UK
Offline Offline
Edison Member
*
Karma: 1
Posts: 1197
Exhibitor at UK Maker Faire
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I have a one-line LCD with an actual HD44780 chip (not a clone or an upgraded part).  I'd be interested in testing your code.
Logged

Western New York, USA
Online Online
Faraday Member
**
Karma: 36
Posts: 4304
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I didn't get any replies when I asked about how to post my code in the playground so I guess that isn't an appropriate place to put untested code.

The college from which I retired has graciously provided me with some space on their server.  They just finished making some adjustments to provide access for me since that privilege is usually reserved for current students and faculty.  I will have the code up there later today.  The link is: http://web.alfredstate.edu/weimandn/  

floresta
« Last Edit: April 14, 2009, 01:47:44 pm by floresta » Logged

Western New York, USA
Online Online
Faraday Member
**
Karma: 36
Posts: 4304
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Anachrocomputer:

There are one-line LCDs as envisioned by the manufacturers of the controller (Hitachi in your case) and there are one-line LCDs as envisioned by the manufacturer of the display itself.  Unless your pc board has another chip on it (an Hitachi HD44100 or equivalent) it is, as far as the controller is concerned, a two-line display.  The first line consists of eight characters starting at DDRAM address 0x00 and the second line consists of eight characters starting at DDRAM address 0x40.  Since your display manufacturer has configured it as 16x1 the two "lines" are placed next to one another to appear as one line.  That's the reason for the crazy addressing scheme.

By the way (I'm not bashing the unattributed author of liquidCrystal - just reporting what I see) the original liquidCrystal code has the following two commands, the first in the 8-bit constructor and the second in the 4-bit constructor.

Code:
 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.  

My version of liquidCrystal.cpp is now available at the location mentioned in my previous post.  

floresta
Logged

New Zealand
Offline Offline
God Member
*****
Karma: 0
Posts: 999
Arduino pebbles
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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.
Funnily enough I've just been trying to get a LCD display working and noted the same issue with the comment, thanks for bringing it up.

It might be worth sending a "patch" for the comment to the developer list.

--Phil.
Logged

New Zealand
Offline Offline
God Member
*****
Karma: 0
Posts: 999
Arduino pebbles
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Hi,

I've just tried out your modified code with a 1 x 16 LCD module from a fax machine with success.

It did seem to reset noticeably more reliably with the modified code.

My main suggestion would be to 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.

Works for me. :-)

--Phil.

Logged

New Zealand
Offline Offline
God Member
*****
Karma: 0
Posts: 999
Arduino pebbles
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Incidentally, because the module thinks it's driving a 2 x 8 device I needed to write a wrapper routine to make it print a longer than 8 character string correctly. I wonder if we should add an option for autohandling that too?

--Phil.
Logged

Western New York, USA
Online Online
Faraday Member
**
Karma: 36
Posts: 4304
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Phil:

Quote
modify the case of the file so it matches the original name: LiquidCrystal.cpp
Somewhere in my aging brain the first letter got changed to lower case and I have been writing it that way lately.  I see that the case is correct on the file that I have available for download.

Quote
I suspect that the comments might need to be reduced in order to be accepted into the core
I have learned virtually all of my programming by analyzing other peoples programs.  In the process I add comments where they are (usually) missing and reword them when they are (rarely) present.  

I find that comments are invaluable when trying to reuse code, especially when changing hardware.  My non-library Arduino LCD code and my assembly language LCD programs for the Arduino (actually a Bare Bones Board) are adapted from assembly language programs I wrote years ago for the 68HC11.  Those 68HC11 programs were adopted from 8085 versions that go back even further.  I couldn't have done it without the comments.

I'm not all that familiar with library implementation but 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.  If that is the case then perhaps the library could contain two versions of the source code, one with comments (for reference) and one without (for use).  I do that with some of the style sheets for my web pages.  I have a "verbose" version that I use while designing the page.

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.

floresta
Logged

London
Offline Offline
Tesla Member
***
Karma: 10
Posts: 6255
Have fun!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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.
It does not affect the runtime size. I think follower is suggesting that for code to be included in a core library you should follow the style of commenting used for other core libraries.
Logged

New Zealand
Offline Offline
God Member
*****
Karma: 0
Posts: 999
Arduino pebbles
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I see that the case is correct on the file that I have available for download.
I've discovered you do indeed have a file with the correct case available but that is not the file that is linked from your web page. (I also discovered that thanks to the wonders of a case-insensitive web server the file LiQuidCrystaL.cpp is also available. smiley-grin)

As mem pointed out, my suggestion regarding comments was to match the style used in the rest of the core. (Which would include removing commented out code.) I don't suggest you remove all the comments--the detail you provide in most cases is necessary.

In terms of style I also wonder if we should take the opportunity to refactor the duplicated code in the two different constructors.

Quote
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.
You mean the display shift functions? If so, I discovered today that they (would) scroll within the "imaginary" layout of the display which leads to odd results in the case of a display like the one I'm using where the physical layout doesn't match.

Thanks again for your work on this code, I appreciate having a reliable display operation now. :-) I look forward to your work being integrated into the core.

--Phil.
« Last Edit: April 22, 2009, 10:22:40 am by follower » Logged

Western New York, USA
Online Online
Faraday Member
**
Karma: 36
Posts: 4304
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Phil

I think I have changed ALL references to any versions of the word liquidcrystal to LiquidCrystal.  Please let me know if I missed any and if I broke any links in the process.

Quote
wonders of a case-insensitive web server
The college had a site license for Microsoft products when I was there and I suppose they still do.  I found that when I FTP a new copy of FileName.ext to replace an old copy of fIlEnAmE.ExT the new file contents gets transferred but (due to the wonders of Microsoft) the filename remains unchanged.  I guess because DOS thought they were the same the current Microsoft servers do as well and they don't update the directory listing.  I had to go through and do it manually.

Quote
refactor the duplicated code in the two different constructors
Could you rephrase this?  Perhaps in English.

Could someone answer this question for me.  What is the reason for having one LCD program for both the 4-bit and the 8-bit interfaces?  It isn't likely that a specific project would use both methods at the same time so separate libraries would make more sense to me.  Each library would be smaller, the code in each would be easier to follow, and the code would probably run faster.

I have lots more LCD info to put up on my website but it takes a while to get it updated (it's really old) and transferred into legible HTML.  I'll try to work on the addressing and "imaginary layout" part soon.

floresta
Logged

London
Offline Offline
Tesla Member
***
Karma: 10
Posts: 6255
Have fun!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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. The difference in size and performance compared to dedicated libraries for that code would be negligible.

I expect the 8 bit version is supported for backwards compatibility with old applications, but I do wonder if anyone would really care.
« Last Edit: April 22, 2009, 04:18:04 pm by mem » Logged

Western New York, USA
Online Online
Faraday Member
**
Karma: 36
Posts: 4304
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

mem:

Code:
It's much less effort to maintain a single code base for the two variants.
I would argue that this statement would be true only for the original author of the code.  For anyone else, working through all the if/else combinations is no picnic.  The more straightforward the code the easier it is for others to track obscure bugs and to make improvements.

Quote
I expect the 8 bit version is supported for backwards compatibility with old applications, but I do wonder if anyone would really care.
All the more reason to divide the two.  The only reason I can think of to use the 8-bit interface (assuming someone else is writing the library code) is for some miniscule increase in speed.  Why muddy up the library for the sake of backward compatibility?  Everyone complains about Microsoft - why follow their (DOS --> Windows) example?

It seems to me that the 4-bit code would work for someone with an 8-bit interface and they would never know the difference, providing they didn't try to access the LCD module other than via the library.  Just a thought -  I'm not advocating this approach!

floresta


Logged

Pages: [1]   Go Up
Jump to: