Re: Problem with PIC & LCD display
- From: allanhvii@xxxxxxxxx
- Date: Sat, 3 May 2008 22:57:23 -0700 (PDT)
On May 1, 12:51 pm, Steve H <ste...@xxxxxxxxxxxxxxxx> wrote:
I'm having a problem with a fairly simple project incorporating a
16F877A PIC and a 4x20 alphanumeric display module. The circuit
interfaces with other logic ICs, though these can be removed from the
circuit to isolate the problem.
The circuit is fed, under test conditions, from a linear 12v power
supply. The 5v regulator on the circuit board is decoupled using 100nf
ceramic capacitors. There is similar decoupling on the PIC itself, and
at other places e.g. decoupling the 5v supply on the connector to the
LCD display. I have also fitted a 100uH coil in the supply to the 5v
regulator to reduce any effects from spurious noise on the supply line.
The problem I'm having difficulty solving is that the display will
intermittently go blank. It will go blank, seemingly when the display is
written to by the PIC, either (a) due to a spike/noise on the mains
supply (this can be intermittently reproduced by repeatedly turning on
and off a piece of mains powered equipment on the same circuit), or (b)
when the 0v rail (not even necessarily close to the LCD display) is
touched by for example a multimeter probe. This is the most consistent
way of producing the fault. The multimeter can be turned off and the
other probe not connected to anything for this to happen. The PIC
doesn't appear to be affected by any of this as it can be shown to still
be operating as expected.
I've experienced similar issues before in my limited experience of
building small projects with PICs. I had issues with a 16F84A resetting
itself when the 0v rail close to the IC was touched with a screwdriver.
Can anybody suggest what vital consideration for circuit design I'm
missing. I'm at a bit of a loss as to what I'm doing wrong.
Thanks.
--
Steve H
Steve:
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
.
- Follow-Ups:
- Re: Problem with PIC & LCD display
- From: Steve H
- Re: Problem with PIC & LCD display
- From: JosephKK
- Re: Problem with PIC & LCD display
- From: Steve H
- Re: Problem with PIC & LCD display
- References:
- Problem with PIC & LCD display
- From: Steve H
- Problem with PIC & LCD display
- Prev by Date: Global Free Calling
- Next by Date: Re: OT Dual core CPUs versus faster single core CPUs?
- Previous by thread: Re: Problem with PIC & LCD display
- Next by thread: Re: Problem with PIC & LCD display
- Index(es):
Relevant Pages
|
Loading
