lcd interfacing with pic 18f4550

Discussion in 'General Electronics Chat' started by dhruv1128, Aug 10, 2014.

  1. dhruv1128

    Thread Starter New Member

    Jun 28, 2014
    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.

    Thanking you in advance
  2. Brownout

    Well-Known Member

    Jan 10, 2012
    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.
  3. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    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:

    Code ( (Unknown Language)):
    2. #include "p18cxxx.h"
    3. #include "TimeDelay.h"
    4. #include "HardwareProfile.h"
    6. // DelayXLCD() provides at least 5ms delay
    7. #define DelayXLCD() DelayMs(5)
    9. // DelayPORXLCD() provides at least 15ms delay
    10. #define DelayPORXLCD()  DelayMs(15)
    12. // Delay500nS() provides a 500nS delay
    13. //   note 500nS = 2,000,000 Hz
    15. #define _LCD_DELAY_OPS GetInstructionClock() / 2000000
    17. #if _LCD_DELAY_OPS == 0  
    18.   #define Delay500nS() Nop()
    19. #endif
    20. #if _LCD_DELAY_OPS == 1  
    21.   #define Delay500nS() Nop()
    22. #endif
    23. #if _LCD_DELAY_OPS == 2  
    24.   #define Delay500nS() Nop();Nop()
    25. #endif
    26. #if _LCD_DELAY_OPS == 3  
    27.   #define Delay500nS() Nop();Nop();Nop()
    28. #endif
    29. #if _LCD_DELAY_OPS == 4
    30.   #define Delay500nS() Nop();Nop();Nop();Nop()
    31. #endif
    32. #if _LCD_DELAY_OPS == 5
    33.   #define Delay500nS() Nop();Nop();Nop();Nop();Nop()
    34. #endif
    35. #if _LCD_DELAY_OPS == 6
    36.   #define Delay500nS() Nop();Nop();Nop();Nop();Nop();\
    37.                        Nop()
    38. #endif
    39. #ifndef Delay500nS()
    40.   #define Delay500nS() #error "Delay500nS() macro needs more steps!"
    41. #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).
    Hypatia's Protege and dhruv1128 like this.
  4. LewisMF


    Nov 15, 2014
    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??
  5. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    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: Jun 14, 2015
    Hypatia's Protege likes this.
  6. LewisMF


    Nov 15, 2014
    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'.
  7. JohnInTX


    Jun 26, 2012
    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: Jun 14, 2015
  8. ErnieM

    AAC Fanatic!

    Apr 24, 2011
    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.