# lcd interfacing with pic 18f4550

#### dhruv1128

Joined Jun 28, 2014
6
Hello all,

I am interfacing p18f4550 with LCD. I am using Mplab with c18 compiler and i am interfacing 16x2 lcd with it in 4-bit mode. Is the xlcd.h library provided with it correct ? I am not able to work with it properly. Please help me how to use it, so that I can interface LCD with it properly.

#### Brownout

Joined Jan 10, 2012
2,390
It should be correct, but I've never tried it before. Make sure you call the 4-bit routines and connect the same I/O's as the libraries have. My LCD libraries are based on what was provided with the software, and they work.

#### ErnieM

Joined Apr 24, 2011
8,196
I use that library, or rather I started with that library and made numerous updates and corrections to it over the years. It is not that shabby, but does some things not to my taste.

The only true flaw is the delay routines inside it were fixed for a certain processor running at a certain speed. When using the C18 compiler I included the time delay (TimeDelay.c and TimeDelay.h) routines into my project, and add the following to xlcd.h:

Rich (BB code):
#include "p18cxxx.h"
#include "TimeDelay.h"
#include "HardwareProfile.h"

// DelayXLCD() provides at least 5ms delay
#define DelayXLCD() DelayMs(5)

// DelayPORXLCD() provides at least 15ms delay
#define DelayPORXLCD()  DelayMs(15)

// Delay500nS() provides a 500nS delay
//   note 500nS = 2,000,000 Hz

#define _LCD_DELAY_OPS GetInstructionClock() / 2000000

#if _LCD_DELAY_OPS == 0
#define Delay500nS() Nop()
#endif
#if _LCD_DELAY_OPS == 1
#define Delay500nS() Nop()
#endif
#if _LCD_DELAY_OPS == 2
#define Delay500nS() Nop();Nop()
#endif
#if _LCD_DELAY_OPS == 3
#define Delay500nS() Nop();Nop();Nop()
#endif
#if _LCD_DELAY_OPS == 4
#define Delay500nS() Nop();Nop();Nop();Nop()
#endif
#if _LCD_DELAY_OPS == 5
#define Delay500nS() Nop();Nop();Nop();Nop();Nop()
#endif
#if _LCD_DELAY_OPS == 6
#define Delay500nS() Nop();Nop();Nop();Nop();Nop();\
Nop()
#endif
#ifndef Delay500nS()
#define Delay500nS() #error "Delay500nS() macro needs more steps!"
#endif
That will work with up to a 48 MHz clock.

Since it can be confusing as to *which* xlcd.h file is being used I copy all the xlcd source files into my project, usually using a sub folder. This way there is no confusion over which xlcd.h gets used a it also defines some hardware things (so needs to be custom to each project).

#### LewisMF

Joined Nov 15, 2014
100
The XLCD library seems to work fine, the only problem I have experienced with this is that when interfacing a PIC18F MCU the LCD 'goes crazy' when resetting the PIC driving low the MCLR pin. With 'going crazy' I mean that it displays aleatory characters instead of displaying whats it should. The reset button has to be pressed numerous times before the LCD works correctly.

This is problem I have only experienced with the PIC18F family of controllers.

After investigating a little bit I have heard it is problems due to timing with delays or something like that in the XLCD library, but I dont know...

Has anyone had any similar experience with this or know why this happens??

#### ErnieM

Joined Apr 24, 2011
8,196
This is problem I have only experienced with the PIC18F family of controllers.

After investigating a little bit I have heard it is problems due to timing with delays or something like that in the XLCD library, but I dont know...

Has anyone had any similar experience with this or know why this happens??
I can say I've never seen that problem, and I use these displays with PIC18 devices for the main part.

As I mentioned before the delays inside this library need help: they are hard coded for a specific clock on the test hardware it was developed for. That is why I use the above code (which is specific for the PIC18's as it is).

BTW, calling XLCD a "library" is a bit outside the traditional definition of a library. It is not a pre-compiled set of functions. They should be recompiled with every project they are used for.

Edit: "pre-compiled" not "per-compiled"

Last edited:

#### LewisMF

Joined Nov 15, 2014
100
I can say I've never seen that problem, and I use these displays with PIC18 devices for the main part.

As I mentioned before the delays inside this library need help: they are hard coded for a specific clock on the test hardware it was developed for. That is why I use the above code (which is specific for the PIC18's as it is).

BTW, calling XLCD a "library" is a bit outside the traditional definition of a library. It is not a per-compiled set of functions. They should be recompiled with every project they are used for.
Hi EarnieM,

Cheers, I'll give it a shot and see if it solves the problem!

PS: I'll think twice next time before calling something 'library'.

#### JohnInTX

Joined Jun 26, 2012
4,597
In addition to what the others have said, be sure you have the E line on the LCD pulled down so that when the IO goes tri-state during RESET, you don't send gibberish to the LCD.

You'll also want to consider what happens if you get the RESET during a write - while E is high and/or in the middle of a two-nibble data write. That can cause the re-init after RESET to be out of sync with the display. I usually send the first init word to the display a few extra times (the 44780 wants 3 - send a few more) to flush out any partial writes from an unexpected hard RESET. Finally, if the RESET comes right after a display instruction that takes a long time to complete e.g. Clear Screen, your init may be ignored since the display is busy. Adding an initial delay before init gives the display to power up from cold and complete any in-progress instructions during a warm restart.

EDIT: BTW, the same kind of procedures should be in place for any other peripherals that might be affected by an interrupted data transmission - I2C, SPI etc. can get 'lost' if a data transaction is stopped in the middle. The system reset / init routines should take that into account and execute recovery procedures as necessary without having to cycle the power.

Last edited:

#### ErnieM

Joined Apr 24, 2011
8,196
EDIT: BTW, the same kind of procedures should be in place for any other peripherals that might be affected by an interrupted data transmission - I2C, SPI etc. can get 'lost' if a data transaction is stopped in the middle. The system reset / init routines should take that into account and execute recovery procedures as necessary without having to cycle the power.
Agree. I've struggled with the I2C while debugging that same interface's code: the dang thing would get stuck mid-transaction when I would reset for something. Let to several days of insanity till I realized I was introducing the ghosts in the machine I was almost seeing.

My fix was to either use a power on clear (100% effective but disturbs to debugger) or to just insert 9 SCL clock pulses to complete any and all transactions. (9 may be overkill but always works.)

I've not worked enough with SPI to have comments there.