Modern Device Forum

I just got done modifying the original LiquidCrystal() library that comes with the Arduino IDE to use only 4 data lines, enable and rs. I thought the LCD4Bit library was great but didn't like having to recompile the library every time I needed to change pins for the LCD. This way any pins can be used for communication with the LCD.

I did my work using the latest Arduino IDE (16) and a BBB

This is my first library (well modification) I've ever done, so please let me know if I should include anything else in the readme.txt file or if I need additional comments, etc.

I've attached the library (NewLCD) to this post.
I'd appreciate any feedback.

teedeeus

teedeeus:

I agree with what you are trying to do with the LCD library - here are some comments, both pro and con, on what you have done so far. I hope you can use them to refine your project.

In my opinion removing the 8-bit stuff from the library is a good idea. I can't see any reason to try to accommodate both configurations in one library. I can't think of any situation where one might want to switch back and forth during the execution of a program. When I questioned this approach on an Arduino forum the answer was that it is easier to maintain one library rather than two. My response was that it was easier for the original author to maintain, but harder for anyone else, hardly what you want in an open source environment. I got no further response to that statement.

There are some serious problems with the LCD initialization routines in the LiquidCrystal library which I have been attempting to get the Arduino team to correct. They were on the to-do list for v16 but didn't make it in. I have written them up and posted them at http://web.alfredstate.edu/weimandn. Follow the link to 'An improved LiquidCrystal library'. You should also look at the 'LCD Initialization' link before you remove any more of the time delays. They are absolutely necessary if you expect every LCD to work every time, especially as processor speeds increase.

Finally, what are you going to call your next version of the revised library? How about ReallyNewLCD? (sorry Paul, I couldn't resist that)

Don

floresta wrote:teedeeus:

I agree with what you are trying to do with the LCD library - here are some comments, both pro and con, on what you have done so far. I hope you can use them to refine your project.

In my opinion removing the 8-bit stuff from the library is a good idea. I can't see any reason to try to accommodate both configurations in one library. I can't think of any situation where one might want to switch back and forth during the execution of a program. When I questioned this approach on an Arduino forum the answer was that it is easier to maintain one library rather than two. My response was that it was easier for the original author to maintain, but harder for anyone else, hardly what you want in an open source environment. I got no further response to that statement.

There are some serious problems with the LCD initialization routines in the LiquidCrystal library which I have been attempting to get the Arduino team to correct. They were on the to-do list for v16 but didn't make it in. I have written them up and posted them at http://web.alfredstate.edu/weimandn. Follow the link to 'An improved LiquidCrystal library'. You should also look at the 'LCD Initialization' link before you remove any more of the time delays. They are absolutely necessary if you expect every LCD to work every time, especially as processor speeds increase.

Finally, what are you going to call your next version of the revised library? How about ReallyNewLCD? (sorry Paul, I couldn't resist that)

Don

I am reading the information you have on your site. I wish I found this before I started making the changes to the library
I am going to implement your recommendations, because I want this to work every time. I'm going to keep the name of the library as NewLCD - I'll just put a revision number in the comments.

Thanks alot!!
-teedeeus

OK - I have new library code - I'm calling it version 0.1 - please don't use the previous code. I hope the delays are implemented correctly as they seem to be working fine with my LCD.

Please send me your comments and experience with the new version of this library.

-teedeeus

Don,

Sorry to hear your improvements didn't make it into the Arduino 16. If DM would lighten up over there and stop trying to do everything himself, more would get done. I'll cut the rants here - you probably already know my views.

Anyway I'll post a link to your improvements on the Arduino library page and maybe that will get their attention.

Paul

I do wish I'd known about your improved library when I started my Allen organ project.

In any case, I wound up working out the whole initialization sequence by myself - including the bit about tying DB3 to logic high - without having any of that stuff in the HD44180 data sheet that I had. http://dftscript.blogspot.com/2009/08/a ... hello.html shows the reasoning that I went through - which winds up explaining all the strange bit patterns and timings that turn up in the initial sequence sent to the device. The 4-bit display people might be interested.

ke9tv:

I'll look at yours if you'll look at mine.

Follow the LCD Initialization and LCD Addressing links at http://web.alfredstate.edu/weimandn.

73, Don

Kevin:

Well I looked at your blog and found some errors, at least one of which is obviously a typo.

The typo is right at the beginning - the display uses an HD44780 chip, not an HD44180.

There are several places where you state that a 0x3n instruction will put the device in the 4-bit mode when in fact it puts the device in the 8-bit mode. You need 0x2n to get to the 4-bit mode.

I can't figure out the business about wiring DB3 to +5 instead of ground. Neither I nor anyone else to my knowledge has ever found this necessary. I have always left DB0 - DB3 either floating or grounded when using the 4-bit mode.

What you may have missed is the fact that there must be a delay after the third 0x30 instruction. This does not show up in either of the data sheet flowcharts, probably due to an editing or translation error. I use 100uS, just like the previous delay.

Don