Hi PICers,
I have a trouble. A big trouble. I want to hook a LCD module to pic16c84.
I build a schematics - it uses 8 bit interface. I get Microchip application
note AN??? (sorry can't remember the number). I port it for 16c84, program
the chip and ...nothing happens. I use 2x20 LCD with LED backlight, so I
carefully examine LCD data sheet - it says Vo (LCD driving voltage) must be
0..5V, use 10K-20K pot between 5v and ground - well evereting was OK. After
that I wrote a simple program that tests every line - evereting was OK,
but LCD still displays nothing - only the backlite is on but LCD is empty.
Here is my shematic:
Greg Marchokov wrote:
>
> Hi PICers,
> I have a trouble. A big trouble. I want to hook a LCD module to pic16c84.
> I build a schematics - it uses 8 bit interface. I get Microchip application
> note AN??? (sorry can't remember the number). I port it for 16c84, program
> the chip and ...nothing happens. I use 2x20 LCD with LED backlight, so I
> carefully examine LCD data sheet - it says Vo (LCD driving voltage) must be
> 0..5V, use 10K-20K pot between 5v and ground - well evereting was OK. After
> that I wrote a simple program that tests every line - evereting was OK,
> but LCD still displays nothing - only the backlite is on but LCD is empty.
if you can't solve the problem just by turning the pot upor down then
I guess the code must be the problem
are you sure it's working ?
put a signal on the ra.3 and try to detect it with something like a LED
if all else fails I've got a bullet proof lcd driver code and I can send
it to
you .
also I'd suggest to put your e-mail address into the next mail
so I could decide to answer it private or on the list
LCD modules can be finicky at powerup. I have a software delay
execute before I begin writing to the display to let it stabilise.
You can also try the initialisation code for the display which
usually consists of sending bytes in the list,
> LCD modules can be finicky at powerup. I have a software delay
> execute before I begin writing to the display to let it stabilise.
> You can also try the initialisation code for the display which
> usually consists of sending bytes in the list,
>
> retlw 30h ; display initialisation
> retlw 30h
> retlw 30h
> retlw 38h ; 2 lines, 5X7 chars
> retlw b'00001100' ; display = on, no cursor or blink
> retlw 1h ; clear display
> retlw 6h ; increment display
>
> I put a delay after the '30h' commands as defined in the display
> initialise instructions.
Note that if you do the four-bit initialization, things are a little bit
trickier as you cannot just send the init-stuff using your byte-output
routine, unless you always have a signifcant delay between outputting the
two halves of a byte (which is useless in all other cases). For the display
init, of a 4-bit unit, you need to send a bunch of "nybble" "2"s with a
delay after each one, and then a single nybble "3", and then everything else.
Note that if you don't have a delay between the last "2" and the "3", the "3"
may not be registered, and you send something else [even another "3"] after
the "3", if may be interpreted as the high nybble of the next command.
It took me several hours to track down this problem; anyone else using a 4-bit
display should watch for it.
Has anyone got a short piece of code that works off a 16c84 on a 16x1
LCD module?
I need to test my LCD module, since I can't seem to get it running with
the PIC.
Using code thats known to work should tell me whether the LCD or my code
is wrong.
Eric van Es wrote:
>
> Hi guys.
>
> Has anyone got a short piece of code that works off a 16c84 on a 16x1
> LCD module?
> I need to test my LCD module, since I can't seem to get it running with
> the PIC.
>
> Using code thats known to work should tell me whether the LCD or my code
> is wrong.
>
> Thanks!
> --
> Eric van Es | Cape Town, South Africa
> .....vanesKILLspam@spam@ilink.nis.za | http://www.nis.za/~vanes
> LOOKING FOR TEMPORARY / HOLIDAY ACCOMODATION?
> http://www.nis.za/~vanes/accom.htm
Hello Eric,
Try applications note AN587 of Microchip!
The title is "INTERFACING TO AN LCD MODULE".
> Hi guys.
>
> Has anyone got a short piece of code that works off a 16c84 on a 16x1
> LCD module?
> I need to test my LCD module, since I can't seem to get it running with
> the PIC.
>
> Using code thats known to work should tell me whether the LCD or my code
> is wrong.
>
Here is a piece of code that works.
It uses the LCD in 4 bit mode with D4-D7 connected to RB0-RB3, RS
connected to RB7, EN connected to RA3 and RW grounded. The delays are
calibrated for a 4MHz crystal.
C1 equ 0Ch ;General Purpose Counter - Used in Delay
C2 equ 0Dh ;General Purpose Counter - Used in Delay
Temp equ 0Eh ;General Purpose Temporary Register
Flags equ 0Fh ;Holds General bit flags
;=========================================================================
;Flag bits
;=========================================================================
LCD_RS equ 0 ;LCD RS line to use on next LCD write
;=========================================================================
;Code starts here
;=========================================================================
ORG 0
bsf STATUS, RP0 ;Bank 1
movlw 00h
movwf TRISA^80h ;Set PORTA to all outputs
movlw 070h
movwf TRISB^80h ;Set PORTB directions
movlw 077h
movwf OPTION_REG^80h ;Enable pull ups and set
prescaler
;to 1:64 TMR0
bcf STATUS, RP0 ;Back to bank 0
clrf PORTA
clrf PORTB
clrf Flags
;Clear Timer routine variables
call Init_LCD ;Initialize the LCD module
call WriteString ;Write Hello World
goto $
;=========================================================================
;Writes a string out to the LCD. The string must be terminated by 0
;=========================================================================
WriteString:
bsf Flags, LCD_RS
clrf C2
Write_Loop:
movf C2,W
call Get_Char
xorlw 0
btfsc STATUS,Z
return
call LCDWrite2
incf C2,F
goto Write_Loop
;=========================================================================
;Writes a single nibble to the LCD. Used by the Init_LCD routine.
;=========================================================================
LCDWrite1:
movwf PORTB ;Write Data nibble to PORT B
bsf LCD_EN ;Set enable line
bcf LCD_EN ;Clear enable line
return
;=========================================================================
;Writes a byte to the LCD. The byte is written upper nibble first, lower
;nibble second.
;Registers used : W, Temp
;=========================================================================
LCDWrite2:
movwf Temp ;Use Temp to hold value
swapf Temp,F
movlw 0Fh
andwf Temp,W ;Mask out upper 4 bits of Temp
btfsc Flags,LCD_RS ;Must RS line be set?
iorlw 80h ;Set RS line
movwf PORTB ;Write data Nibble to PORT B
bsf LCD_EN ;Set enable line
bcf LCD_EN ;Clear enable line
swapf Temp,F
movlw 0Fh
andwf Temp,W ;Mask out lower 4 bits of Temp
btfsc Flags,LCD_RS ;Must RS line be set?
iorlw 80h ;Set RS line
movwf PORTB ;Write data nibble to PORT B
bsf LCD_EN ;Set enable line
bcf LCD_EN ;Clear enable line
movlw 52
movwf Temp ;Delay 150us on 4MHz XTAL
LCD_Delay:
decfsz Temp,F
goto LCD_Delay
return
;=========================================================================
;This subroutine initializes the LCD module according to the procedure
;described in the Hitachi docs. The LCD is never read from, so all
;operations are spaced slightly further apart than the maximum time
;that operation can take.
;Registers used : W, C1, C2, Temp
;=========================================================================
Init_LCD:
movlw 20 ;This will delay just more than
15ms
movwf C1
call Delay
movlw 03h ;First Init Byte
call LCDWrite1
movlw 7 ;Delay at least 5ms
movwf C1
call Delay
movlw 03h ;Second Init Byte
call LCDWrite1
movlw 1 ;Delay at least 150us
movwf C1
call Delay
movlw 03h ;Third Init Byte
call LCDWrite1
movlw 1 ;Delay at least 150us
movwf C1
call Delay
movlw 02h ;Choose 4 bit interface
call LCDWrite1
movlw 1 ;Delay at least 150us
movwf C1
call Delay
bcf Flags, LCD_RS ;RS line must be low for the
following
movlw 20h ;Select 1 line 5X7
call LCDWrite2 ;Write byte as two nibbles
movlw 08h ;Display off Command
call LCDWrite2
movlw 0Fh ;Display on, Cursor On, Blink on
call LCDWrite2
movlw 06h ;Increment Curser, no shift
call LCDWrite2
movlw 01h ;Make sure display is cleared
call LCDWrite2
movlw 7 ;Delay at least 5ms, to clear
display
movwf C1
call Delay
return
> Hi,
>
> > Hi guys.
> >
> > Has anyone got a short piece of code that works off a 16c84 on a
> 16x1
> > LCD module?
> > I need to test my LCD module, since I can't seem to get it running
> with
> > the PIC.
> >
> > Using code thats known to work should tell me whether the LCD or my
> code
> > is wrong.
> >
>
> Here is a piece of code that works.
> It uses the LCD in 4 bit mode with D4-D7 connected to RB0-RB3, RS
> connected to RB7, EN connected to RA3 and RW grounded. The delays are
>
> calibrated for a 4MHz crystal.
>
> Hope this helps.
> Niki
Thank you! EXACTLY what I was looking for!
Thanks a million Niki!
On Sat, 20 Sep 1997 22:16:16 +0200 Eric van Es <EraseMEvanesspam_OUTTakeThisOuTILINK.NIS.ZA>
writes:
>N STEENKAMP [M.ING E&E] wrote:
>
>
>Thank you! EXACTLY what I was looking for!
>Thanks a million Niki!
There are 2 types of 16x1 modules out there. One type has the HD44780
chip and an LCD driver chip. It uses x8 or x11 drive for a true
16-character by one line. The characters appear sequentially in RAM.
The other type has only the HD44780 chip. The controller must be set for
x16 drive, since it is logically an 8x2 display. The LCD panel is built
so the 2 lines appear end to end rather than above each other. There is
a gap in the RAM between the two sides of the display just like the gap
in RAM between the two lines of a 2-line display.
If you're only seeing the left 8 characters on the display it is likely
the x16 type. There is no way to test with software what kind it is.
Even without any commands from the PIC, the HD44780 will reset itself
into x8 mode and clear the display RAM at power-on. So when the power is
turned on and the LCD drive voltage sufficiently high (or low, since it
is relative to Vdd), some or all of the characters should change to dim
or dark blocks. THis is a pretty good test of the LCD module. If you
can't get anything at all on the screen you may have one of the
high-temperature modules which requires more than 5V of LCD drive. In
that case the LCD drive pin needs to be pulled negative a few volts.
<<
If you're only seeing the left 8 characters on the display it is likely
the x16 type. There is no way to test with software what kind it is.
>>
There Is, send a char to RAM location 0 and the next char to RAM location
D'40' this is the start of the second 8 chars on a 16 x 1 with only one chip
if the char does not appear then it must be a proper one.
> There are 2 types of 16x1 modules out there. One type has the HD44780
>
> chip and an LCD driver chip. It uses x8 or x11 drive for a true
> 16-character by one line. The characters appear sequentially in RAM.
> The other type has only the HD44780 chip. The controller must be set
> for
> x16 drive, since it is logically an 8x2 display. The LCD panel is
> built
> so the 2 lines appear end to end rather than above each other. There
> is
> a gap in the RAM between the two sides of the display just like the
> gap
> in RAM between the two lines of a 2-line display.
>
> If you're only seeing the left 8 characters on the display it is
> likely
> the x16 type. There is no way to test with software what kind it is.
>
What I get when power it up and adjust the contrast, is 8 dark blocks
left, and 8 lighter ones to the right.
When I run Niki's program all 16 character become lighter - so I assume
it is initialised.
At this point, I can't get it to display anything else. I'll ask Niki,
since I had to change one or two things to get MPASM to assemble it.
Is it possible to destroy just the data display part of the LCD. I find
it unlikely that soldering my pins on it could destroy the bugger.
> Even without any commands from the PIC, the HD44780 will reset itself
> into x8 mode and clear the display RAM at power-on. So when the power
> is
> turned on and the LCD drive voltage sufficiently high (or low, since
> it
> is relative to Vdd), some or all of the characters should change to
> dim
> or dark blocks. THis is a pretty good test of the LCD module.
OK mine does that (allready mentioned)
> If you
> can't get anything at all on the screen you may have one of the
> high-temperature modules which requires more than 5V of LCD drive. In
>
> that case the LCD drive pin needs to be pulled negative a few volts.
But that would guarantee that a normal temp one would loose its
smoke....
>
> Mike Keitz wrote:
>
> > There are 2 types of 16x1 modules out there. One type has the
> HD44780
> >
> > chip and an LCD driver chip. It uses x8 or x11 drive for a true
> > 16-character by one line. The characters appear sequentially in
> RAM.
>
> > The other type has only the HD44780 chip. The controller must be
> set
> > for
> > x16 drive, since it is logically an 8x2 display. The LCD panel is
> > built
> > so the 2 lines appear end to end rather than above each other.
> There
> > is
> > a gap in the RAM between the two sides of the display just like the
> > gap
> > in RAM between the two lines of a 2-line display.
> >
> > If you're only seeing the left 8 characters on the display it is
> > likely
> > the x16 type. There is no way to test with software what kind it
> is.
> >
>
> What I get when power it up and adjust the contrast, is 8 dark blocks
> left, and 8 lighter ones to the right.
>
> When I run Niki's program all 16 character become lighter - so I
> assume
> it is initialised.
> At this point, I can't get it to display anything else. I'll ask Niki,
> since I had to change one or two things to get MPASM to assemble it.
>
> Is it possible to destroy just the data display part of the LCD. I
> find
> it unlikely that soldering my pins on it could destroy the bugger.
>
> > Even without any commands from the PIC, the HD44780 will reset
> itself
> > into x8 mode and clear the display RAM at power-on. So when the
> power
> > is
> > turned on and the LCD drive voltage sufficiently high (or low, since
> > it
> > is relative to Vdd), some or all of the characters should change to
> > dim
> > or dark blocks. THis is a pretty good test of the LCD module.
>
> OK mine does that (allready mentioned)
>
> > If you
> > can't get anything at all on the screen you may have one of the
> > high-temperature modules which requires more than 5V of LCD drive.
> In
> >
> > that case the LCD drive pin needs to be pulled negative a few volts.
>
> But that would guarantee that a normal temp one would loose its
> smoke....
>
> Cheers! And thanks for the help!
>
> --
> Eric van Es | Cape Town, South Africa
> @spam@vanesKILLspamilink.nis.za | http://www.nis.za/~vanes
> LOOKING FOR TEMPORARY / HOLIDAY ACCOMODATION?
> http://www.nis.za/~vanes/accom.htm
I have an optrex 16117A LCD, That is configured like that.( 16x1,
configured as 2 logical lines.
To save I/O pins, I used a serial shift register (74HCT164) to send the
data to the LCD via it's 8-bit bus. (I could not get the 4-bit thing to
work). Since I dont see any reason to read data from the controller
(the HD44780) this works for me. I have some test code that I used for
a PIC16C57 that works great.
On Sun, 21 Sep 1997 02:36:05 -0400 Steve Smith <KILLspamXYGAXKILLspamAOL.COM> writes:
>In a message dated 20/09/97 23:03:36, you write:
>
><<
> If you're only seeing the left 8 characters on the display it is
>likely
> the x16 type. There is no way to test with software what kind it is.
> >>
>There Is, send a char to RAM location 0 and the next char to RAM
>location
>D'40' this is the start of the second 8 chars on a 16 x 1 with only
>one chip
>if the char does not appear then it must be a proper one.
Of course this is a test, but it isn't purely software since it requires
the user to observe the screen. What I was talking about is writing
software that will adapt to use either type without needing the user to
set anytihing.
I shouldn't have writtne "no" because I can think of a few ways to do
that but haven't tried them. The first way would be to set the display
in x16 (2-line) mode and copy data for the last 8 characters to both
places in RAM. This won't work on an 11-row, 2-chip display because the
top parts of the second line characters will appear in the unused bottom
3 pixels of the first half of the line. Also the contrast won't be as
good as could be obtained using a 2-chip display in x8 or x11 mode.
The old Hitachi book I have says x16 units use a 160 KHz clock and x8/11
ones a 250 KHz clock. This makes the worst-case execution time shorter
on the latter displays. If the connection allows reading the busy bit,
software could determine the time a command takes and guess at the
HD44780 clock speed, which may be related to the type of display.
>
>Cheers Steve.....
>
>
>
> What I get when power it up and adjust the contrast, is 8 dark blocks
> left, and 8 lighter ones to the right.
>
> When I run Niki's program all 16 character become lighter - so I
> assume
> it is initialised.
> At this point, I can't get it to display anything else. I'll ask Niki,
> since I had to change one or two things to get MPASM to assemble it.
>
> Is it possible to destroy just the data display part of the LCD. I
> find
> it unlikely that soldering my pins on it could destroy the bugger.
>
In message <spamBeGone970921023604_-1163534516spamBeGoneemout04.mail.aol.com>>
TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU writes:
> In a message dated 20/09/97 23:03:36, you write:
>
> <<
> If you're only seeing the left 8 characters on the display it is likely
> the x16 type. There is no way to test with software what kind it is.
> >>
> There Is, send a char to RAM location 0 and the next char to RAM location
> D'40' this is the start of the second 8 chars on a 16 x 1 with only one chip
> if the char does not appear then it must be a proper one.
>
> Cheers Steve.....
>
Ok, but is there anyway to tell which display type it is without
a human seeing it? ie can the PIC know by itself and send chars
to the appropriate places?
> Hi guys.
>
> Has anyone got a short piece of code that works off a 16c84 on a 16x1
> LCD module?
> I need to test my LCD module, since I can't seem to get it running with
> the PIC.
>
> Using code thats known to work should tell me whether the LCD or my code
> is wrong.
>
Here is a piece of code that works.
It uses the LCD in 4 bit mode with D4-D7 connected to RB0-RB3, RS
connected to RB7, EN connected to RA3 and RW grounded. The delays are
calibrated for a 4MHz crystal.
C1 equ 0Ch ;General Purpose Counter - Used in Delay
C2 equ 0Dh ;General Purpose Counter - Used in Delay
Temp equ 0Eh ;General Purpose Temporary Register
Flags equ 0Fh ;Holds General bit flags
;=========================================================================
;Flag bits
;=========================================================================
LCD_RS equ 0 ;LCD RS line to use on next LCD write
;=========================================================================
;Code starts here
;=========================================================================
ORG 0
bsf STATUS, RP0 ;Bank 1
movlw 00h
movwf TRISA^80h ;Set PORTA to all outputs
movlw 070h
movwf TRISB^80h ;Set PORTB directions
movlw 077h
movwf OPTION_REG^80h ;Enable pull ups and set
prescaler
;to 1:64 TMR0
bcf STATUS, RP0 ;Back to bank 0
clrf PORTA
clrf PORTB
clrf Flags
;Clear Timer routine variables
call Init_LCD ;Initialize the LCD module
call WriteString ;Write Hello World
goto $
;=========================================================================
;Writes a string out to the LCD. The string must be terminated by 0
;=========================================================================
WriteString:
bsf Flags, LCD_RS
clrf C2
Write_Loop:
movf C2,W
call Get_Char
xorlw 0
btfsc STATUS,Z
return
call LCDWrite2
incf C2,F
goto Write_Loop
;=========================================================================
;Writes a single nibble to the LCD. Used by the Init_LCD routine.
;=========================================================================
LCDWrite1:
movwf PORTB ;Write Data nibble to PORT B
bsf LCD_EN ;Set enable line
bcf LCD_EN ;Clear enable line
return
;=========================================================================
;Writes a byte to the LCD. The byte is written upper nibble first, lower
;nibble second.
;Registers used : W, Temp
;=========================================================================
LCDWrite2:
movwf Temp ;Use Temp to hold value
swapf Temp,F
movlw 0Fh
andwf Temp,W ;Mask out upper 4 bits of Temp
btfsc Flags,LCD_RS ;Must RS line be set?
iorlw 80h ;Set RS line
movwf PORTB ;Write data Nibble to PORT B
bsf LCD_EN ;Set enable line
bcf LCD_EN ;Clear enable line
swapf Temp,F
movlw 0Fh
andwf Temp,W ;Mask out lower 4 bits of Temp
btfsc Flags,LCD_RS ;Must RS line be set?
iorlw 80h ;Set RS line
movwf PORTB ;Write data nibble to PORT B
bsf LCD_EN ;Set enable line
bcf LCD_EN ;Clear enable line
movlw 52
movwf Temp ;Delay 150us on 4MHz XTAL
LCD_Delay:
decfsz Temp,F
goto LCD_Delay
return
;=========================================================================
;This subroutine initializes the LCD module according to the procedure
;described in the Hitachi docs. The LCD is never read from, so all
;operations are spaced slightly further apart than the maximum time
;that operation can take.
;Registers used : W, C1, C2, Temp
;=========================================================================
Init_LCD:
movlw 20 ;This will delay just more than
15ms
movwf C1
call Delay
movlw 03h ;First Init Byte
call LCDWrite1
movlw 7 ;Delay at least 5ms
movwf C1
call Delay
movlw 03h ;Second Init Byte
call LCDWrite1
movlw 1 ;Delay at least 150us
movwf C1
call Delay
movlw 03h ;Third Init Byte
call LCDWrite1
movlw 1 ;Delay at least 150us
movwf C1
call Delay
movlw 02h ;Choose 4 bit interface
call LCDWrite1
movlw 1 ;Delay at least 150us
movwf C1
call Delay
bcf Flags, LCD_RS ;RS line must be low for the
following
movlw 20h ;Select 1 line 5X7
call LCDWrite2 ;Write byte as two nibbles
movlw 08h ;Display off Command
call LCDWrite2
movlw 0Fh ;Display on, Cursor On, Blink on
call LCDWrite2
movlw 06h ;Increment Curser, no shift
call LCDWrite2
movlw 01h ;Make sure display is cleared
call LCDWrite2
movlw 7 ;Delay at least 5ms, to clear
display
movwf C1
call Delay
return
In a message dated 22/09/97 12:52:01, Mike Watson wrote:
<<
Ok, but is there anyway to tell which display type it is without
a human seeing it? ie can the PIC know by itself and send chars
to the appropriate places?
Regards,>>
No. The only way to tell is to send some chars and see what comes out if its
a 16 char length and only one chip on the back its a cheat's one IE 2 x 8 in
a single line they need the second chip to be a proper 16 char unit because
else they map the chars 0-7 and 40-47 on the second line as the second line.
All the char ram is on the first chip and AFIK there is no software method of
determining the display configuration. An answer may be to use a 30 pin simm
socket to plug the display into to check its performance this would then
display chars as required without trashing the solder pads. Well its a
thaught.
By the way is everyone getting my mail twice ? If so tell me and I will try
to fix it cause I only send it once....
>> If you can't get anything at all on the screen you may have one of
>> the high-temperature modules which requires more than 5V of LCD
>> drive. In that case the LCD drive pin needs to be pulled negative a
>> few volts.
> But that would guarantee that a normal temp one would loose its
> smoke....
>Eric van Es wrote:
>
>> Mike Keitz wrote:
>
>>> If you can't get anything at all on the screen you may have one of
>>> the high-temperature modules which requires more than 5V of LCD
>>> drive. In that case the LCD drive pin needs to be pulled negative
>a
>>> few volts.
>
>> But that would guarantee that a normal temp one would loose its
>> smoke....
I don't think it would, the only difference is likely the LCD panel
itself (the chips are rated for high voltage). So all pixels in the
panel would go completely black, holding the voltage that high for a long
time may burn it. This test is only if you can't see anything at the
regular voltage anyway.
> >>> If you can't get anything at all on the screen you may have one of
> >>> the high-temperature modules which requires more than 5V of LCD
> >>> drive. In that case the LCD drive pin needs to be pulled negative
> >a
> >>> few volts.
> >
> >> But that would guarantee that a normal temp one would loose its
> >> smoke....
> I don't think it would, the only difference is likely the LCD panel
> itself (the chips are rated for high voltage). So all pixels in the
> panel would go completely black, holding the voltage that high for a long
> time may burn it. This test is only if you can't see anything at the
> regular voltage anyway.
Running a display with somewhat excessive drive voltage may cause long term
damage to the "dark" pixels, but displays are remarkably hardy when it comes
to AC voltage (a large DC voltage, on the other hand, can destroy a display
quickly and even a fairly small one can destroy it slowly). A friend of
mine told me he saw a company revitalize some custom LCD's that had some
internal shorts (the legends were so small that some of the conductive
material flaked and bridged) by connecting the displays (with the driver
chips REMOVED!) to raw AC120. The shorts were instantly burned off, leaving
the rest of the display functional. According to my friend, the batch of
displays had only about 15% yield off the factory floor, but almost all of
the "bad" displays were revitalized with this technique.
BTW, on a somewhat related note, it's important on some LCD's to be careful
of what data are used to drive them. While some LCD drivers reverse the
driving polarity on each scan line, others reverse it each frame. If a
pixel is driven dark on "even" frames and clear on "odd" frames (or vice
versa) this can then produce a DC bias that can wreak havoc on the display.
Once upon a time, I ran into this phenomenon first hand (quite a rude
shock, as it happened); I was programming a laptop computer with an active
matrix color LCD (back when the display alone on one of those things cost
more than my car) and left the display running a program that flashed much
of the display between two colors while I went to lunch (having no clue
that this would be a bad thing). When I came back from lunch (about 1/2
hour) the part of the display that had been flashing was very badly and
wierdly "fogged"; as I worked with the computer for the next few hours the
fogging largely subsided, but signs of it persisted until the next morning.
Had the display been in that state longer, I suspect it might not have rec-
overed so well.
[btw, I don't know if current laptops do anything to prevent this problem;
alternating polarity on even/odd scan lines might have helped since any
leakage between lines would help bleed off any accumulating charge]
<snip>
>
> Running a display with somewhat excessive drive voltage may cause
> long term damage to the "dark" pixels, but displays are remarkably
> hardy when it comes to AC voltage (a large DC voltage, on the other
> hand, can destroy a display quickly and even a fairly small one can
> destroy it slowly). A friend of mine told me he saw a company
> revitalize some custom LCD's that had some internal shorts (the
> legends were so small that some of the conductive material flaked
> and bridged) by connecting the displays (with the driver chips
> REMOVED!) to raw AC120. The shorts were instantly burned off,
> leaving the rest of the display functional. According to my friend,
> the batch of displays had only about 15% yield off the factory
> floor, but almost all of the "bad" displays were revitalized with
> this technique.
GAH! 15% yield and techniques like that? Quick, tell me the
company, so I never buy stuff there!!
MikeS
<mikesmith_ozNOSP*M.relaymail.net>
(remove the you know what before replying)
ilink.nis.za | http://www.nis.za/~vanes
