Searching \ for '[PIC]: LCD Contrast Variation' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/lcd/pic.htm?key=lcd
Search entire site for: 'LCD Contrast Variation'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: LCD Contrast Variation'
2002\08\15@014826 by Thomas N

picon face
Hello Everyone,

My LCD was working fine with 8-bit interface mode.  When I change it to
4-bit interface mode, the LCD contrast changes randomly each time I run
the program (I use ICD).  Sometimes, the display is clear with no dark
background, but sometimes the background is very dark and it's very hard
to read the text on the LCD.  Anyone know why it is intermittent like
this?  There is no improvement between floating the 4 un-used pins and
grounding them.  Please help!

Thank you in advance!
Thomas

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\15@042521 by sbryden

flavicon
face
How did you make the change from 8 bit to 4 bit? Was there physical moving/
disconnecting or did you just change the software? Can you go back to confirm
that it is really the 4/8 bit change that is causing the problem. Does it
change each time you run the program, as you described, or are there also
changes during the run? It sounds to me more like a bad connection somewhere,
either in your contrast circuit (pot wiper?) or even in the module itself.

For my part, I've used lots of these modules, mainly in 4-bit mode and haven't
seen this problem.

Simon.
---


 On Wed, Aug 14, 2002
at 10:37:15PM -0700, Thomas N wrote:
{Quote hidden}

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\15@153637 by Peter L. Peres

picon face
On Wed, 14 Aug 2002, Thomas N wrote:

>Hello Everyone,
>
>My LCD was working fine with 8-bit interface mode.  When I change it to
>4-bit interface mode, the LCD contrast changes randomly each time I run
>the program (I use ICD).  Sometimes, the display is clear with no dark
>background, but sometimes the background is very dark and it's very hard
>to read the text on the LCD.  Anyone know why it is intermittent like
>this?  There is no improvement between floating the 4 un-used pins and
>grounding them.  Please help!

What is connected to Vlc ?

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads


2002\08\16@013606 by 8859-9?B?1m1lciBZYWxo/Q==?=

I find that to be a programming error.  I had the similar problem,
sometimes it would work just fine, sometimes the background would be so
dark (like before init) it is hard to read the text.  I played with the
timings a bit and that solved the problem (although not completely).  It
is curious though, I never had this problem when using pure asm, I
recently swithched to C and the problems began.  I cannot get the lcd to
work with C commands, so I used assembly.

IMHO,

Ömer YALHI
spam_OUToyalhiTakeThisOuTspamteksan.com.tr
http://www.teksan.com.tr
Tel : +90 212 613 22 00
Fax: +90 212 544 70 35


{Original Message removed}

2002\08\16@072210 by Vasile Surducan

flavicon
face
I'ts an interesting effect because the contrast usual must have nothing to
do with the communication ( and I'm not talking about sharing one cursor
at two different positions where multiplexation will decrease the contrast
) If all communication timing are ok then only Vlc must modify the
contrast. Vlc may be a positive or negative voltage depends on LCD
characteristics, tipically is somewhere between +2.5 to +4V or -3 to -5V.
But in your case I think is a 4bit mode error if the 8 bit looks great.

Vasile


On Fri, 16 Aug 2002, [iso-8859-9] Ömer Yalhý wrote:

{Quote hidden}

> {Original Message removed}

2002\08\16@074719 by Jinx

face picon face
> If all communication timing are ok then only Vlc must modify
> the contrast

Two jobs ago the LCD I used had Vlc tied to 0V. I snipped the LCD
routines from a previous project (which worked fine) and included
them into the new one. The LCD contrast would not initialise until
I pressed the reset key. On power-up the background to the chars
on the LCD was very dark, and cleared only after a reset. Before I
got to figure out what was wrong I needed to change the xtal from
4MHz to 16MHz. After the init timing was amended to suit 16MHz
it worked perfectly. So the conclusion is.........s/w or h/w problem
on the original ??? A bit of both ??? The routines came from a 4MHz
program which should have not misbehaved in another 4MHz PIC

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\08\16@084001 by 8859-9?B?1m1lciBZYWxo/Q==?=

Jinx, when you say reset, do you mean ---, well, what do you mean?  What
reset key?

Omer YALHI
oyalhispamKILLspamteksan.com.tr
http://www.teksan.com.tr
Tel : +90 212 613 22 00
Fax: +90 212 544 70 35


{Original Message removed}

2002\08\16@180606 by Jinx

face picon face
> Jinx, when you say reset, do you mean ---, well, what do you
> mean?  What reset key?

Resetting the PIC. On power up the LCD, a standard 16x2, was
dark (but showing data sent to it so was working) then the PIC
was reset by a PB on MCLR. After that reset the LCD display
was the proper contrast

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\08\16@220945 by David Duffy

flavicon
face
> > Jinx, when you say reset, do you mean ---, well, what do you
> > mean?  What reset key?

Jinx wrote:
>Resetting the PIC. On power up the LCD, a standard 16x2, was
>dark (but showing data sent to it so was working) then the PIC
>was reset by a PB on MCLR. After that reset the LCD display
>was the proper contrast

Could it be you didn't wait the 100ms at power-up before initialising
the LCD? Resetting the PIC after power-up would be different from
a cold power-up if the LCD was talked to too soon. Also, do you do
the first part of the init code 3 times as recommended?
Regards...

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2002\08\17@020524 by Jinx

face picon face
> Could it be you didn't wait the 100ms at power-up before initialising
> the LCD? Resetting the PIC after power-up would be different from
> a cold power-up if the LCD was talked to too soon. Also, do you do
> the first part of the init code 3 times as recommended?

This is the LCD code I generally use, and it always has worked apart
from that one incident. It must have been something funny about that
circuit (or possibly even the PIC), although the screen did come right
when the speed was bumped up from 4MHz to 16MHz

The Hitachi handbook recommends waiting > 15ms after the LCD's
Vcc reaches 4.5V, and I've found 50ms works OK. If that problem
ever comes back perhaps I can try increasing the pu delay. Take it
as read that the msdelay routine does in fact delay 1 millisecond

;=================================================

        movlw   0xce         ;power-up delay 50ms
        movwf   temp
        call    msdelay
        incfsz  temp,f
        goto    $-2
        call     lcd_init

rest of code

;================================================
;        Initialise LCD screen
;================================================

lcd_init movlw  0x30
        movwf  portd
        bcf    rs
        bcf    rw
        bsf    en
        nop
        bcf    en
        call   msdelay      ;delay > 4.1ms
        call   msdelay
        call   msdelay
        call   msdelay
        call   msdelay

        bsf    en            ;write 0x30 again
        nop
        bcf    en
        call   msdelay       ;delay > 100us

        bsf    en            ;write 0x30 again
        nop
        bcf    en
        call   msdelay       ;delay > 100us

        movlw  0x38          ;2 lines, 5x7 font
        call   write_c
        movlw  0x0c          ;1+DCB = display on, no cursor, no blink
        call   write_c
        movlw  0x01          ;display clear
        call   write_c
        movlw  0x06          ;entry mode set, increment address
        call   write_c

        return               ;return from initialisation

;================================================
;        LCD commands
;================================================

line1    movlw  0x00          ;line 1, column 0
        call   address
        return

line2    movlw  0x40          ;line 2, column 0
        call   address
        return

address  addlw  0x80          ;set high bit of address command
        call   write_c
        return

write_c  bcf    rs            ;write command
        goto   d_out

write_d  bsf    rs            ;write data

d_out    movwf  portd
        bcf    rw
        bsf    en
        nop
        bcf    en
        call   busy
        return

busy     bsf    rw            ;set LCD RW for Read
        bcf    rs
        bank1
        movlw  b'11111111'   ;make d7 an input
        movwf  trisd
        bank0

        bsf    en
rdbusy   btfsc  bflag         ;loop until Busy Flag clear
        goto   $-1
        bcf    en
        bcf    rw

        bank1
        movlw  b'00000000'   ;d7 as output again
        movwf  trisd
        bank0

        return

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\17@093027 by David Duffy

flavicon
face
Jinx wrote:
> > Could it be you didn't wait the 100ms at power-up before initialising
> > the LCD? Resetting the PIC after power-up would be different from
> > a cold power-up if the LCD was talked to too soon. Also, do you do
> > the first part of the init code 3 times as recommended?
>
>This is the LCD code I generally use, and it always has worked apart
>from that one incident. It must have been something funny about that
>circuit (or possibly even the PIC), although the screen did come right
>when the speed was bumped up from 4MHz to 16MHz
>
>The Hitachi handbook recommends waiting > 15ms after the LCD's
>Vcc reaches 4.5V, and I've found 50ms works OK. If that problem
>ever comes back perhaps I can try increasing the pu delay. Take it
>as read that the msdelay routine does in fact delay 1 millisecond

I was thinking 100ms for some reason. You're right, the book says 15ms
although it does say 40ms after Vcc gets to 2.7V. If the PIC starts when
Vcc is still around there you might be cutting it fine. Looking back at my
code, I have anywhere from 100ms to 500ms between power-up & doing
the LCD init.

{Quote hidden}

Are rs, rw & en on the same port? Personally I like a nop between them
if so to avoid the famous RMW bug. (feature?)

>          call   msdelay      ;delay > 4.1ms
>          call   msdelay
>          call   msdelay
>          call   msdelay
>          call   msdelay
>
>          bsf    en            ;write 0x30 again
>          nop
>          bcf    en

I have a huge 500us for the strobe width & in between strobes!
Looking at the data sheet, I have no idea why!
Regards...

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\17@101222 by Jinx

face picon face
> Are rs, rw & en on the same port? Personally I like a nop between
> them if so to avoid the famous RMW bug. (feature?)

I haven't noticed a problem with adjacent bits in the same port (for
LCDs anyway) and I don't put nops between them. However I do tend
to put nops between instructions to the same bit if, as I understand
or recall it, the external circuit is slowish to respond and there might
be a rise-time delay that could mess up the r-m-w of the next instruction

Sometimes it's there just for a bit of timing

> >          bsf    en            ;write 0x30 again
> >          nop
> >          bcf    en

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\17@101648 by Fredrik Axtelius

picon face
> >lcd_init movlw  0x30
> >          movwf  portd
> >          bcf    rs
> >          bcf    rw
> >          bsf    en
> >          nop
> >          bcf    en
>
> Are rs, rw & en on the same port? Personally I like a nop between them
> if so to avoid the famous RMW bug. (feature?)

RMW bug? Please explain that to a newbie.

/frax

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\17@115756 by Herbert Graf

flavicon
face
> > Are rs, rw & en on the same port? Personally I like a nop between
> > them if so to avoid the famous RMW bug. (feature?)
>
> I haven't noticed a problem with adjacent bits in the same port (for
> LCDs anyway) and I don't put nops between them. However I do tend
> to put nops between instructions to the same bit if, as I understand
> or recall it, the external circuit is slowish to respond and there might
> be a rise-time delay that could mess up the r-m-w of the next instruction

       Actually this problem will creep up with ANY r-m-w of the same port,
doesn't have to be the same bit, or adjacent bits. Of course whether or not
you need the nops is dependant on the load your PIC pins are driving and the
speed of your PIC. TTYL

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\17@164756 by Peter L. Peres

picon face
On Fri, 16 Aug 2002, Vasile Surducan wrote:

>I'ts an interesting effect because the contrast usual must have nothing to
>do with the communication ( and I'm not talking about sharing one cursor
>at two different positions where multiplexation will decrease the contrast
>) If all communication timing are ok then only Vlc must modify the
>contrast. Vlc may be a positive or negative voltage depends on LCD
>characteristics, tipically is somewhere between +2.5 to +4V or -3 to -5V.
>But in your case I think is a 4bit mode error if the 8 bit looks great.

It's not the 'contrast' that changes, the funny codes sent probably
reprogram the display with every command sent. This could cause strange
contrast effects. What happens if you hold the MCU in reset after it
prints something ? Does the contrast become normal ?

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\17@181828 by Jinx

face picon face
> > or recall it, the external circuit is slowish to respond and there might
> > be a rise-time delay that could mess up the r-m-w of the next
instruction
>
> Actually this problem will creep up with ANY r-m-w of the same port,
> doesn't have to be the same bit, or adjacent bits. Of course whether
> or not you need the nops is dependant on the load your PIC pins are
> driving and the speed of your PIC. TTYL

I knew it was something like that. I didn't feel like dragging out my
notes at 2:30am. Normally I'd have LCDs (or any external device)
as receptive as possible, eg by using short leads. Anything that has
a frequency response of a few MHz I don't much worry about, and
that includes common semis like LEDs, RAM, other logic and so on

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\17@211120 by David Duffy

flavicon
face
I wrote:
> > Are rs, rw & en on the same port? Personally I like a nop between
> > them if so to avoid the famous RMW bug. (feature?)

Jinx replied:
>I haven't noticed a problem with adjacent bits in the same port (for
>LCDs anyway) and I don't put nops between them. However I do tend
>to put nops between instructions to the same bit if, as I understand
>or recall it, the external circuit is slowish to respond and there might
>be a rise-time delay that could mess up the r-m-w of the next instruction

If the LCD is on a length of ribbon cable, the capacitance may come into
play causing rise times on the lines being slower than the RMW action.
Putting a NOP in there usually has no real impact on performance as far
as the user is concerned. I'd rather do that than have to track down faults
caused by RMW operations later on. They're a real pain to find sometimes.
Regards...

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\17@211159 by David Duffy

flavicon
face
Jinx & I write:
> > >lcd_init movlw  0x30
> > >          movwf  portd
> > >          bcf    rs
> > >          bcf    rw
> > >          bsf    en
> > >          nop
> > >          bcf    en
> >
> > Are rs, rw & en on the same port? Personally I like a nop between them
> > if so to avoid the famous RMW bug. (feature?)

Fredrik asked:
>RMW bug? Please explain that to a newbie.

A RMW operation is when you do, say a BCF or BSF on a port pin. The PIC
actually reads the old port value in (not the output latch, but the actual
pins),
changes the specified bit, then writes the new value out to the port. Most of
the time this is fine. The problem occurs if you do consecutive BCF or BSF
operations on the same port. What happens is that the first RMW changes
a port pin's level but due to capacitance on the port pin, it takes (a
small but
finite) time to get to the new level. If it hasn't got to the correct level
before the
next RMW operation, the old (wrong) level may get read in and therefore used
as part of output value for that operation. Clear as mud?  :-)  An example:

start           ;00000000 all bits low to start with
BSF port,0      ;00000001 bit 0 starts going high but is slow due to
capacitance
BSF port,1      ;00000010 bit 1 goes high but bit 0 set low again due to RMW !

I hope this helps. I think the PIC data sheets mention about RMW operations.
Regards...

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\17@221016 by Jinx

face picon face
> I'd rather do that than have to track down faults caused by RMW
> operations later on. They're a real pain to find sometimes

You're right of course. Even if it works fine on my bench the
customers, godluvem, may get it into their heads to tinker. "Oh,
all I did was put the LCD on a longer cable and it doesn't work -
what have I broken ?"

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\08\18@021434 by David Duffy

flavicon
face
At 01:33 PM 18/08/02 +1200, you wrote:
> > I'd rather do that than have to track down faults caused by RMW
> > operations later on. They're a real pain to find sometimes
>
>You're right of course. Even if it works fine on my bench the
>customers, godluvem, may get it into their heads to tinker. "Oh,
>all I did was put the LCD on a longer cable and it doesn't work -
>what have I broken ?"

I hate it when we send a piece of custom equipment to a customer
and they can't make it work only to find that they haven't hooked it
up the way we told them to. I ask them questions and then they say
so innocently "Oh we decided to hook it up a different way" or such.
Grrrr... damn customers. Err, hang on - they pay us - oh well !  :-)
I try to make stuff "customer proof" where possible. I does pay off.
Short circuit proof, reverse polarity proof and the like.
Regards...

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2002\08\18@035403 by Russell McMahon

face
flavicon
face
> I try to make stuff "customer proof" where possible. It does pay off.
> Short circuit proof, reverse polarity proof and the like.

I make a communicator sold for disability use. "Caregivers" and others are
not known for their attention to battery recharging details. I have seen
some equipment with a fast charge capability of a few hours that then sits
there and boils its batteries. People often leave them plugged in overnight
or all weekend.

With my equipment there is a right way to charge it but the OK way is "plug
in a plug pack (aka wall wart) that has a plug end that will fit in the hole
and leave it overnight". The "correct" charger is 12v at well under 200 mA
but anything from about 6v to 20v odd is OK and it can be AC or either
polarity DC. Design charge time is, purposefully, "overnight" but you can
leave it plugged in as long as you wish without damage. 6v is a bit low but
will charge. Inside is a bridge rectifier and a constant current source set
to about battery 12 hour rate and a battery pack maximum voltage limit.
There is a LED charging monitor with brightness a function of connected
charger voltage. Batteries last as long as in any other gear I have seen
around. (Some have died early but many models over 5 years old still have
original batteries) Oldest of these is now about 7 years old and I imagine
some have original batteries. A better design would have a timer shut off or
monitor battery condition but it hasn't proved necessary.

       RM

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2002\08\18@130707 by Harold Hallikainen

picon face
Read Modify Write "bug" is not a bug, it's just the PIC doing what it's supposed to do. Reading a port actually reads the pins. If you've just written to the output port (actually the output latch), the pins may not have changed. They could be heavily loaded (perhaps shorted to ground and will never change), or have a capacitive load so it takes time for the voltage on the pin to change.

This read/modify/write problem can be avoided in several ways. One is to insert a delay between the write and the next read. Another is to keep a "port mirror" in RAM. Modify the RAM location as you wish, then copy the result to the port. This avoids reading the port itself before the pins have had a chance to change. Finally, the PIC18 series has separate addresses for PORTx and LATx. You can do read-modify-write instructions on the output latch without worrying about how slowly the pin reacts.

Harold





________________________________________________________________
GET INTERNET ACCESS FROM JUNO!
Juno offers FREE or PREMIUM Internet access for less!
Join Juno today!  For your FREE software, visit:
dl.http://www.juno.com/get/web/.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...