Routines to control an HD44780-based LCD module emulating a tty screen

by Isaac Marino Bavaresco

These routines implement the interface to text LCD modules controled by the HD44780 controller and compatibles. The display mimics a TTY screen, with automatic scroll and recognizes the standard control codes '\a', '\b', '\f', '\n', '\r', '\t' and '\v'.

I'm using this code for some years now, in various slightly different versions. Now I decided to make the 'definitive' version, to be the most flexible yet as simple to use as possible.

This incarnation is not tested yet. I'm not sure the code without the R/!W pin is OK, because I always use the R/!W pin.

I included a lot of #if... to allow for maximum flexibility and I must test every combination to make sure I didn't screwed anything.

They can be used together with the 'stdio' functions ('printf', etc.) to program for embedded systems the same way someone would do for desktop systems.

• LCDcfg.h
• LCD.c

This version was tested and works very well. It was adapted to a different board than the version above, please check the ASCII-art at line 43 of file LCDcfg-lite.h.

• LCDcfg-lite.h
• LCD-lite.c

Questions:

• James Newton of MassMind asks:

  Couple of quick notes/questions/comments:

  1. LCD_DI or Data/!Instruction is another name for R/S which is more commonly found in the documentation for the panels.

  2. It's curious that you say you always use the R/!W pin, but the LCD-lite code defaults to having that option unused.

  3. The delay functions are hard coded for a specific clock rate, but you don't seem to document that rate. Since most C compilers for PIC's have a built in delay macro (e.g. __delay_us(byte) shouldn't that be used? A good compiler shouldn't require that to be a function when stack levels are critical. Perhaps I'm wrong on that?

  James Newton of MassMind replies: Ah... I just found the "4Mhz" in the header. My bad.

  Isaac Marino Bavaresco replies: 1. Good point! 2. The project that originated this particular version was one of the few I didn't use R/!W because it was too resource constrained and also it was only required to meet human-interface sppeds, so some extra delays would not be a problem. 3. Not every C compiler's library have good delay routines (or any at all), and often they have different definitions, etc. Besides, unfortunately not every compiler can be called "good".

Comments:

• hey there
  pretty amazed with the routines! good job
  just one thing: in the "non-lite" version you never mention the used 4MHZ of your board
  now in the header file there is a "at least - 500ns" delay defined as a simple NOP operation
  assuming that someone uses a faster clock speed the whole set of delay definitions is wrong, someone might end up with wrong LCD output because of a short delay
  
  my suggestion is to add a simple comment where you advise users to add another 1-3 NOP operations at higher clock speeds, to ensure the 500ns delay is really 500ns long
  
  greetings
  vince
  
  Isaac Marino Bavaresco replies: Thanks!
  I always adapt the header file to each project I use these routines, so I always make the delays as exact as possible to not waste CPU cycles.
  For more powerful platforms (e.g. ARM) I use their own delay routines wrapped by my macros.
  Of course you can make the delays longer to suit faster CPUs and use it always that way, but you will be wasting cycles in the slower CPUs.