Re: Problem with PIC & LCD display
- From: Steve H <steveu@xxxxxxxxxxxxxxxx>
- Date: Sun, 4 May 2008 12:45:17 +0100
In message <59da1fb5-677b-4c5b-8ba0-4559e7304426@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, allanhvii@xxxxxxxxx writes
I finally made some actual progress. Please let me know if this helps.
First, don't expect to have a system immune to all noise. The noise
will effect the signals to the LCD, and it will cause problems for the
LCD unit. So the questions are (1) how to best reduce the noise and
(2) how to handle the LCD errors.
Background (As we all know...):
In 4-bit mode, the LCD is expecting 8 bit commands as pairs of 4 bits.
At reset, the LCD is in 8-bit mode until you send it a command to put
it in 4-bit mode. This command is actually in 8-bit mode itself, so
you only need to send 1 nibble since the other half of the bus is not
connected. Once this command is accepted, all the commands which
follow must be in pairs of nibbles. If the LCD ever gets out-of-sync
with the software sending the nibble pairs, we're in trouble! This
explains why the LCD often looks okay until new data is sent to it;
it's out of sync, or maybe even back into 8-bit mode.
If any noise is interpreted by the LCD as either E-Clock, power down,
or reset, the module will get confused because it will be expecting a
nibble, not a nibble pair. At this point, the LCD must be
reinitialized for 4-bit mode (again).
Solution Options:
1. Reduce noise causing E-Clock by adding filtering (eg R-C) close to
the LCD module.
2. Reduce noise causing power down / reset by adding caps, filters,
etc. close to the LCD module.
3. Change the software initialization routine to re-initialize the LCD
for 4-bit mode "often".
4. Monitor the busy signal from the LCD to determine when it "thinks"
it has a nibble pair and reset it if out of sync.
5. Run the LCD in 8-bit mode.
I'd consider #3 mandatory, and the others optional.
I've started using the following sequence since the sequence specified
in my LCD's manual couldn't recover the module after ESD. This must be
sent every so often to the LCD in case it gets locked up, but can be
sent to a working LCD as well. For testing, I've used very long time
delays (shown here) and probably an overly complicated sequence. I'm
going to try to shorten the times and the sequence tomorrow, but this
works:
1. Wait 150 ms
2. Send 0x3 and wait 150 ms (will stay in 8-bit mode if already there)
3. Send 0x3 and wait 150 ms (will go to 8-bit mode if was in 4-bit
without any garbage nibble)
4. Send 0x3 and wait 250 ms (will go to 8-bit mode even if garbage
nibble was previously received)
5. Send 0x2 and wait 200 ms (should go to 4-bit mode now)
6. Send 0x2, 0x2 (ie byte = 0x22) and wait 200 ms (really should be in
4-bit mode by now - probably excessive!)
7. Send LCD setup sequence (eg 0x2, 0x8 (=0x28), 0x0, 0x8 (=0x08),
etc.)
By the way, in 8-bit mode these issues would be less likely to show up
for a few reasons:
1. The spurious (ESD) writes to the LCD may cause a garbage character,
but a refresh will clean it up.
2. The LCD won't get out of sync the way it does with the nibble
pairs, which is what really messes up 4-bit mode.
3. I suspect 8-bit mode is typically used with the LCD on the
processor's bus, in which case the processor would crash and reset
when seeing this much noise.
Just one more note. The spec for the LCD I'm using indicates the
unused data pins DB0-DB3 should be pulled low, but other related specs
indicated otherwise. I'm experimenting with pulling them such that 8-
bit command to go to 4-bit mode will also setup my LCD for 2-line
operation, to help avoid the flicker caused by this reset sequence.
Allan Vaitses
This is very interesting. It provides a seemingly highly plausible explanation for why the display crashes only on a write operation.
I wonder how common it is for 4-wire mode to be used with these display modules rather than 8-wire. If it does turn out to be the aggravating factor causing such problems, it could explain - if 8-wire is the norm - why I seem to be in a tiny minority in having difficulties.
I used 4-wire because (a) it ties up fewer pins on the PIC, (b) it made the PCB layout a little easier and (c) because it's programmed using a Basic compiler, there's no additional effort required to cater for the 4-wire write operation. That, and the fact that there's no theoretical reason to use the display in this mode, it's designed for it after all.
As it happens, to convert from 4-wire to 8-wire as it stands will be straightforward. It's certainly now top of the to-do list.
The display I'm using is a Powertip device. I don't know what chip it uses as it can't be determined from looking at the module (http://www.spho.demon.co.uk/mux/IMG_0098.jpg). I've ordered a Batron alternative to try, more in hope than expectation that it'll cure the problem. Regardless of whether switching to 8-wire fixes it, I'll try the new display in 4-wire to test it out.
I'll let you know what the results are - won't be until Tuesday or Wednesday.
--
Steve H
.
- Follow-Ups:
- Re: Problem with PIC & LCD display
- From: Jan Panteltje
- Re: Problem with PIC & LCD display
- References:
- Problem with PIC & LCD display
- From: Steve H
- Re: Problem with PIC & LCD display
- From: allanhvii
- Problem with PIC & LCD display
- Prev by Date: Re: OT. How the Dutch view our Election
- Next by Date: Re: OT. How the Dutch view our Election
- Previous by thread: Re: Problem with PIC & LCD display
- Next by thread: Re: Problem with PIC & LCD display
- Index(es):
Relevant Pages
|
