LCD display problems - black boxes

[ahydra]

Hi all,

After some recommendations from people here I got an LCD display and tried to program it. My program (attached below) is designed to write "Hello World!" to the top left corner of the display. It works in a simulator but not in real life -my 2x16 LCD display displays just one line (top) of black boxes, while the bottom line remains completely blank.

This is with the contrast voltage (pin 3) connected to 0V. I also tried a potential divider (as I don't own a variable resistor) with the two resistors equal (contrast voltage 2.85V, supply is 5V) but the entire display stays blank in this case.

The datasheet for the LCD display is **broken link removed**.

On power-on, the top line of the display fills "slowly" with boxes (it takes about 0.5sec - the boxes "fade in"), then nothing else happens. As part of the testing I increased the delay in the "artificial_delay" procedure (from 20 to 250, so up to about 375ms) to see if the display needed more time to switch on, but this doesn't seem to do anything.

I'd be grateful for any help, even if it is "your display is broken"

ahydra

 

[ericgibbs]

Hi all,

After some recommendations from people here I got an LCD display and tried to program it. My program (attached below) is designed to write "Hello World!" to the top left corner of the display. It works in a simulator but not in real life -my 2x16 LCD display displays just one line (top) of black boxes, while the bottom line remains completely blank.

This is with the contrast voltage (pin 3) connected to 0V. I also tried a potential divider (as I don't own a variable resistor) with the two resistors equal (contrast voltage 2.85V, supply is 5V) but the entire display stays blank in this case.

The datasheet for the LCD display is **broken link removed**.


On power-on, the top line of the display fills "slowly" with boxes (it takes about 0.5sec - the boxes "fade in"), then nothing else happens. As part of the testing I increased the delay in the "artificial_delay" procedure (from 20 to 250, so up to about 375ms) to see if the display needed more time to switch on, but this doesn't seem to do anything.

I'd be grateful for any help, even if it is "your display is broken"

ahydra

hi,
I have run your asm on my Oshonsoft simulator OK.
Assuming you have the PIC to LED wired correctly, the most common cause of not initialising correctly are the delays.
I see that you have PWR up timer off, I would recommend that you set PWR up timer to enabled, the LCD can be slow after power up.
Your artificial delay is about 32mS.
The Enable pulse is at the minimum period, for testing lengthen this with say 2 or 3 nops.

Problem is most simulators dont showup these timing problems.

 

[AtomSoft]

for contrast try placing a resistor of 100ohm from VO to GND or is it VCC i dont remember but it shouldnt kill the lcd to try both

Um... Can you post the simulation file? Or a picture on how you are wiring it or if you can make a schematic would be great.

 

[blueroomelectronics]

You really need a variable resistor as temperature can affect contrast. Also some very old LCDs required a negative contrast voltage.

 

[ahydra]

I programmed the display manually to make sure it works - which it did. I then re-attached the chip and inserted a bunch of NOPs in the program after each change of state of the Enable line. However, I still get the same thing.

I even slowed the oscillator down and re-introduced the very long artificial delay, but no luck.

However, I got it working by using the artificial delay of 15ms after switching on the Enable line and again after switching it off:

lcd_sendcommand_nobusycheck
; sends a command to the LCD but doesn't check for busy status (used at initialisation)
; in: W = command
  BCF STATUS, RP0
  BCF STATUS, RP1
  
  BCF D_LCDPORT, D_RS		; instruction input
  BCF D_LCDPORT, D_RW		; write mode

  MOVWF D_DATAPORT		; send data  
  BSF D_LCDPORT, D_EN		; prepare write command
  CALL artificial_delay
  BCF D_LCDPORT, D_EN		; execute write command
  CALL artificial_delay
  RETURN

It puzzles me that the commands take this long (a quick loop which executed 100 NOPs, not to mention DECFSZ etc, wasn't even enough) but the characters enter fine with just 4 NOPs after each change in the Enable line state. I'll edit this post in a bit with the results of experimenting with the artificial delay time to see what the smallest value is that will work. (Edit: I managed to get the delay down to d'1' in place of the original d'20', i.e. about 1.5ms - so required time is somewhere between about 15us and 3ms, which isn't very helpful)

From the above I can only assume that the "checkbusy" routine isn't working, despite me reprogramming it slightly (see attachment) - can anyone find the bug?

Many thanks for your help.

ahydra

 

[ericgibbs]

hi,
Look at this image. Sorry about the quality, its a copy from my notes
Check the phase sense of the signals. RW.????

 

[ahydra]

hi,
Look at this image. Sorry about the quality, its a copy from my notes
Check the phase sense of the signals. RW.????

Sorry, not sure what you're trying to get at here. Can you explain the bottom right of your notes - it says to make the enable go up and then down, and "data high until RW drops". Does this mean I need to do this:

clear RS
-loop start-
set RW
wait a bit
set EN
wait a bit
clear EN
clear RW
read DB7
if DB7 set, go back to start of loop, else display is ready for another command

This doesn't seem to match what's in the data sheet, which suggests that you can read the data a short while after raising EN but without having to lower it first. Also you don't have to fiddle with RW during the procedure.

I based my code on the example on **broken link removed**, though I didn't do the "set all pins to FF" bit because it seems pointless if you're reading from them.

ahydra

 

[ericgibbs]

hi,
The table I posted is from the Hitachi manual for the HD44780.

It says the RW line must be high when the Enable pulse is used to read the BUSY [D7] . You have in that section of code, RW low.

The hand written notes are from waveforms observed on a scope..

I'll look for some other documentation that may help.

EDIT:
Check the state of the BUSY before you Write to the LCD

 

[ahydra]

The code in my post above is my "send command" code, not my "check busy" code. The "check busy" code has RW high (check the ASM).

I'll try checking the busy status before and after, see if that makes any difference.

ahydra

 

[ericgibbs]

The code in my post above is my "send command" code, not my "check busy" code. The "check busy" code has RW high (check the ASM).

I'll try checking the busy status before and after, see if that makes any difference.

ahydra

Hi,
To prove the PIC/LCD connections/etc are as you expect, can you paste in this copy of Nigel's tutorial for the LCD.
Change the PIC type..
Lets know how it goes.

 

[atferrari]

Maybe not enough

... and inserted a bunch of NOPs in the program after each change of state of the Enable line. However, I still get the same thing..........ahydra

Even a bunch could mean almost nothing in terms of the time needed, mostly miliseconds, as delays, during inizilization.

A bunch, a lot, are vague terms. Most, if not all, datasheets have some sequence where there are delays more or less well defined, consisting of XX msec and not a bunch of.

 

[coder7]

hello to every one
well i problem with my code for lcd. i am using pic to drive the lcd
and using flash ram of pic to hold the data and the reading the ram and sending data
to lcd now the problem is that it is only displaying 'a' and 'b' for other char. lcd display is
blank.
so pls help me.....

 

[3v0]

hello to every one
well i problem with my code for lcd. i am using pic to drive the lcd
and using flash ram of pic to hold the data and the reading the ram and sending data
to lcd now the problem is that it is only displaying 'a' and 'b' for other char. lcd display is
blank.
so pls help me.....

Post you code between

and we may be able to help. The code tags keep the code from getting unformatted.

 

[coder7]

lcd dispaly problem

sorry for delay
i am attchng the code
let me remind my problem
i am using pic16f877a
for drivng lcd
but the problem is that it is not displayng if buffer size increase 6 char
and no displyng 'c'
so help me

 

[3v0]

It is in assembler. I will give someone else first shot at looking at it.

 

[ericgibbs]

sorry for delay
i am attchng the code
let me remind my problem
i am using pic16f877a
for drivng lcd
but the problem is that it is not displayng if buffer size increase 6 char
and no displyng 'c'
so help me

hi,
The delay subs are missing from your post. Errors in assembly,

Error[113]   C:\00000000.ASM 99 : Symbol not previously defined (DELAY5MSEC)
Error[113]   C:\00000000.ASM 103 : Symbol not previously defined (DELAY1MSEC)

Why have you chopped up such a short listing into INCLUDES.????

 

[ericgibbs]

hi,
Look at this composite1.asm [main and incl],added a dummy 5mSec delay.
It now displays the 'C' in the Oshonsoft Simulator,,, check the LCD delays!

You cannot just write a 'DE "C" in the middle of the code in that way, the program crashes.

Ive moved it to the END, but it should point to a EEPROM location with a ORG.

OK.

 

[coder7]

display prblm

hi,
That dealy subroutine is not creating the prblm thats why i have not attach it so if u find any pblm in code so pls let me know

 

[ericgibbs]

hi,
That dealy subroutine is not creating the prblm thats why i have not attach it so if u find any pblm in code so pls let me know

It causes a problem when trying to assemble the source code, because the assembler cannot find the 'delay routine' !,
so it stops assembly and shows an error.

Have you tried the listing I posted.???

 

[ahydra]

Edit: argh, lots of people posted help while I was writing this!! Take a look anyway.

You hijacked my thread Nonetheless I will try to help you. I had a look at your program and I can't really see why it would display "a" and "b" but not "c". To be honest the program looks OK except for three things:

first, where is your RW line control? This should be low if writing to the display and high if reading from it. I guess since you're not checking the busy flag, you could always keep it low in hardware here.

second, in the lcd_int procedure:

movlw	clr_dis
	call sendcmd
	movlw	ram_addr
	call sendcmd

I think you missed out a "call delay1msec" here. (almost definitely needed, the LCD is much slower than the PIC)

finally this can't be right at all in buffer.asm:

inc:
	incf	fsr,f						;increment fsr add.
	incf	test						;increment test reg. value 
	incf  	highram,f					;increment highram value						
	incf	lowram,f					; increment lowram value 
	goto 	dis_string

Incrementing highram like that will point to the wrong place completely. For example if the address was 0x1047, after running the inc procedure it will now be 0x1148 not 0x1048. You need to do something like

incf lowram, f
btfsc status, c
incf highram, f

to only increment highram if lowram overflows.

However even though this is definitely a bug, it shouldn't affect the program as it stands because you're only displaying one character...

I can't really follow what's going on with buffer_ptr and buffer_data. You may well need to change your code if you try to display an entire string, but for now I'll just see if we can get your "c" working. See if any of the above helps and get back to me. ^^

ps. at the start of "sendchar" you have:
movwf char1
movf char1,w

The second line of this isn't necessary - after a MOVWF the data is still in W.

ahydra