Searching \ for '[PIC:] LCD Sometimes Displaying Unwanted Character' 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 Sometimes Displaying Unwanted Character'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] LCD Sometimes Displaying Unwanted Character'
2004\05\12@035850 by Lucian

flavicon
face
Hello again with another question on a different topic...

I have an LCD 2x16 module driven by a PIC16F648A in 4 bit mode. It
initialises ok, displays normally, but sometimes it displays the
characters at unwanted screen locations or displays unwanted characters.
I had a clock with blinking ":" displayed, but sometimes the time was
displayed at the first row instead of the second.
I have a menu displayed but sometimes it displays unwanted characters
instead of the correct ones, I observed that often with one character
ahead, e.g. "MEMU" instead of "MENU".
I searched all the web, but only found a post for PIC Basic (I am using
Hi-Tech PIC C) that was saying that it might be the interrupt service
routine which doesn't save all the context before jumping to the
interrupt so that sometimes the LCD routines are interrupted and don't
execute correctly. I cannot disable the interrupts in the LCD routines
as I have some timers and serial communication.
I am sure that you know more than me on this issue. Could you please
help ?

Lucian

{Original Message removed}

2004\05\12@113937 by Robert Ussery

flavicon
face
Ummm... Have pull-down resistors on data lines, Register select, and enable
line?
I got bitten by this a few times. If the MCU sleeps or resets, the pins
float, and may shift in spurious data.

- Robert

>{Original Message removed}

2004\05\12@121848 by Brian Clewer

flavicon
face
Lucian wrote:

>Hello again with another question on a different topic...
>
>I have an LCD 2x16 module driven by a PIC16F648A in 4 bit mode. It
>initialises ok, displays normally, but sometimes it displays the
>characters at unwanted screen locations or displays unwanted characters.
>I had a clock with blinking ":" displayed, but sometimes the time was
>displayed at the first row instead of the second.

Yes I have often seen this.  My guess is that you are using a ribbon cable
to go from the PIC to the display.  This is OK, but keep the run length as
short as possible.  Try it at 2-3 inches and see if the fault goes away.
You should also put a 100nf cap accross the power pins on the LCD and
*always* on the board as close to the PIC as possible.  This problem is not
due to an interrupt (unless the state of the ports change in the service
routine) because the LCD is not time dependant.  You should even be able to
fix up a bank of switches and clock in the '0's and '1's yourself...
although this would take a while :o).

Brian.

Quality Electronic Designs.
http://www.qualityelectronicdesigns.com

--
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

2004\05\12@122717 by Lucian

flavicon
face
I do not have pull-down resistors tied to the data lines and control
lines, in the next schematic I will try this solution. The LCD is
connected through a 14-pin header, so I guess there is no problem with
the length. I have a 100nf capacitor close to the PIC, but no capacitor
at the LCD.
I do not change the state of the ports in the interrupt routine. The
problem is very intermittent, and now it is very rare, but still... I
will try with the pull-down resistors, thank you !

Lucian
{Original Message removed}

2004\05\12@123550 by Bob Blick

face picon face
Perhaps a timing issue? If you aren't reading the busy flag, are your
delays long enough?

Cheers,

Bob



>>I have an LCD 2x16 module driven by a PIC16F648A in 4 bit mode. It
>>initialises ok, displays normally, but sometimes it displays the
>>characters at unwanted screen locations or displays unwanted
> characters.
>>I had a clock with blinking ":" displayed, but sometimes the time was
>>displayed at the first row instead of the second.

--
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

2004\05\12@123756 by Mike Hawkshaw

flavicon
face
Lucian,

I have seen the problem myself when I started using an LCD to display the
time.
Basically, the ISR was doing too much. It updated the time registers and
then displyed the time on the LCD. In other parts of the programme, other
parts of the LCD were being written to with other data. If the ISR fired
when data was being written elsewhere, then the time would be written where
it was supposed to be, but on return, the other bit of the programme would
write data to the next character after the time, or perhaps somewhere
random, depending upon how far it had got with setting the cursor position.

I don't know if you have this sort of problem or not, but I fixed it by
setting a flag in the ISR to say that the time needed updating, and then
checking this in the other bit of the program to see if the time display
needed updating.

Hope this helps......Mike.

----- Original Message -----
From: "Lucian" <spam_OUTlucifferTakeThisOuTspamHOME.RO>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Wednesday, May 12, 2004 8:59 AM
Subject: [PIC:] LCD Sometimes Displaying Unwanted Characters


{Quote hidden}

> {Original Message removed}

2004\05\12@123759 by Robert Ussery

flavicon
face
>-----Original Message-----
>From: pic microcontroller discussion list [PICLISTspamKILLspamMITVMA.MIT.EDU]
>On Behalf Of Lucian


>I do not have pull-down resistors tied to the data lines and control
>lines, in the next schematic I will try this solution. The LCD is
>connected through a 14-pin header, so I guess there is no problem with
>the length. I have a 100nf capacitor close to the PIC, but no capacitor
>at the LCD.
>I do not change the state of the ports in the interrupt routine. The
>problem is very intermittent, and now it is very rare, but still... I
>will try with the pull-down resistors, thank you !
>
>Lucian

Hopefully, that'll fix it for you. I've run into this problem on several
occasions, usually in low power projects where the MCU sleeps a lot. When
the MCU goes to sleep, its pins float and all kinds of crazy crap comes out
on the LCD.

As Brian mentioned, ribbon cables often exacerbate the problem by serving as
antennas for EMI, and causing the pins to fluctuate even more wildly.

BTW, you may be able to get away with just a resistor on the Enable pin.
This keeps any spurious data on the data lines from being shifted in.
Haven't tried this, but I think it should work.

- Robert

--
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

2004\05\12@130957 by Lucian

flavicon
face
Bob: I inspired myself from your LCDTERM project, so I guess the timing
is not the problem here ;) The delays are of 120 uSecs after a character
or command write.
Mike: Unfortunately, in the ISR I am not writing to the LCD, I am just
updating the variables and setting a flag for modifying the LCD in the
main program.
Robert: I haven't yet tried your solution, but I hope it will work.

Thank you all for your answers.

At this moment I am not sure whether it is a hardware or a software
problem. It is strange that it displays the character before the correct
one.

Lucian

{Original Message removed}

2004\05\12@132930 by Scott Dattalo

face
flavicon
face
Lucian,

Another debugging option is to use gpsim's LCD module. Recent enhancements
to gpsim and the LCD module have yielded a very accurate simulation
environment. Since you're using Outlook as your email client, I assume
that you're using Windows. At the moment, gpsim doesn't work with the LCD
module under Windows. It only works with Linux, BSD, and other Unix based
OSes. The good news to you (and the other 98% of the PicList members) is
that gpsim almost completely works under Windows (thanks to Borut Razem).
I estimate that before the end of June a new release of gpsim will be made
and Windows will be fully supported. Meanwhile, you can take a look at:

http://www.dattalo.com/gnupic/gpsim.html
http://www.dattalo.com/gnupic/lcd.html

Scott

--
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

2004\05\12@145008 by Bob Ammerman

picon face
> At this moment I am not sure whether it is a hardware or a software
> problem. It is strange that it displays the character before the correct
> one.
>
> Lucian

Is there anything else tied to the LSBit of the data bus that could be
pulling it low somehow?

Bob Ammerman
RAm Systems

--
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

2004\05\12@151737 by Matt Pobursky

flavicon
face
I was thinking the same thing, Bob. Or perhaps an intermittent
connection on the D0 line (since 44780-type controllers typically have
pull down resistors internally on their data lines)?

Matt Pobursky
Maximum Performance Systems

On Wed, 12 May 2004 14:47:25 -0400, Bob Ammerman wrote:
> > At this moment I am not sure whether it is a hardware or a software
> > problem. It is strange that it displays the character before the correct
> > one.
> >
> > Lucian
>
> Is there anything else tied to the LSBit of the data bus that could be
> pulling it low somehow?

--
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

2004\05\12@155356 by Lucian

flavicon
face
Looking at the schematic, I see now that all the data lines have
pull-down resistors, as they are shared with the columns of a 4 x 5
keypad. What is weird is that the LCD sometimes displayed the clock in a
wrong position although there was no key activity, so I am inclined to
think that the problem does not come from here.

Lucian
{Original Message removed}

2004\05\12@160436 by Jinx

face picon face
> Have pull-down resistors on data lines, Register select, and enable

AFAIK, the only important connection is Enable. No new data gets
written to the display if Enable isn't flicked high. Data lines, RS and
R/W have MOS pull-ups and will not float. Even if they did, without
activity on Enable their status is irrelevant. Enable must have a pull-
down if the micro is tri-stating that line. There may be a problem
with Enable or Busy timing, or possibly the length of the cable. Without
seeing the code it's difficult to say whether the bad data is coming
from s/w or h/w

--
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

2004\05\12@160437 by Sergio Masci

picon face
----- Original Message -----
From: Bob Ammerman <.....rammermanKILLspamspam.....VERIZON.NET>
To: <EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU>
Sent: Wednesday, May 12, 2004 7:47 PM
Subject: Re: [PIC:] LCD Sometimes Displaying Unwanted Characters


{Quote hidden}

The OP described the word "MENU" being corrupted to "MEMU"

M = hex 4D
N = hex 4E

This is not a single bit error.

The OP also said this LCD is running in 4 bit mode. My money is on a software
error, timing maybe, or using other bits in the same port incorrectly.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler

--
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

2004\05\12@161512 by Lucian

flavicon
face
The problem might be elsewhere, but the fact is that this error appears
mostly when I'm displaying long strings (max 12 characters) read from
the EEPROM. I have a menu that I receive serially and I store it in
EEPROM and then I read the 2 lines I need to display. The code to
display the lines is:

       //menustart is the coordinate of the first line to display from
the menu
       //lung is the length of the first line to display
       for (aux=0;aux<lung;aux++)
               lcd_putch(eeprom_read(LIST_DATA+(16*menu_start)+aux));
       lcd_goto(0x40);
       //lung = the length of the second line to display
       for (aux=0;aux<lung;aux++)

lcd_putch(eeprom_read(LIST_DATA+(16*(menu_start+1))+aux));

I don't see anything wrong in this code. Do you ?

Lucian
{Original Message removed}

2004\05\12@162133 by Lucian

flavicon
face
I suspect that the issue is in the lcd_puts procedure combined with my
ISR routine:

void lcd_puts(const unsigned char * s) {
       while(*s)
               lcd_putch(*s++);
}

In the ISR I only increase some counters and have some serial procedures
run. Could it be that the compiler (PICC) isn't saving some info vital
for the LCD procedure ?

Lucian

{Original Message removed}

2004\05\12@162547 by David Schmidt

flavicon
face
I suspect timing too.
In 4 bit mode, you cannot query the busy bit and must wait a predetermined
time.  Commands and characters have different timing durations.
Throw in a few NOP's in your code after changing port pins, plus increase
your canned delays and see if the problem goes away.

Are you changing port direction too?  Could be a port pin that isn't
changing direction due to you using BSF and BCF commands.

Dave

--
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

2004\05\12@163212 by Lucian

flavicon
face
The procedures for writing a character and a command are as follows:

void lcd_putcmd(unsigned char c) {

       LCD_RS = 0;

       PORTB &= 0x0F;
       PORTB |= c & 0xF0;
       LCD_STROBE;                             // se activeaza datele
       PORTB &= 0x0F;
       PORTB |= c << 4;
       LCD_STROBE;                             // se activeaza datele

       BKLIGHT = 0;
       if (blight_on)
               BKLIGHT = 1;

       delaycount = T_120_US;  // asteapta 120 us
       while(delaycount);
}
void lcd_putch(unsigned char c) {

       LCD_RS = 1;

       PORTB &= 0x0F;
       PORTB |= c & 0xF0;
       LCD_STROBE;                             // se activeaza datele
       PORTB &= 0x0F;
       PORTB |= c << 4;
       LCD_STROBE;                             // se activeaza datele

       BKLIGHT = 0;
       if (blight_on)
               BKLIGHT = 1;

       delaycount = T_120_US;  // asteapta 120 us
       while(delaycount);
}

I am not changing the direction of the PORTB pins and LCD_RS is RB0.

Lucian

{Original Message removed}

2004\05\12@163624 by Dwayne Reid

flavicon
face
At 01:54 PM 5/12/2004, Lucian wrote:
>Looking at the schematic, I see now that all the data lines have
>pull-down resistors, as they are shared with the columns of a 4 x 5
>keypad. What is weird is that the LCD sometimes displayed the clock in a
>wrong position although there was no key activity, so I am inclined to
>think that the problem does not come from here.

Any chance that the *pull-up* resistors in the LCD are fighting the
pull-down resistors you mention above and causing problems?  Just idly
musing - I haven't had a chance to look at the schematic and I could be way
off base.

dwayne

--
Dwayne Reid   <dwaynerspamspam_OUTplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 20 years of Engineering Innovation (1984 - 2004)
 .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
    `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
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

2004\05\12@163831 by Andrew Warren

flavicon
face
David Schmidt <@spam@PICLISTKILLspamspammitvma.mit.edu> wrote:

> In 4 bit mode, you cannot query the busy bit and must wait a
> predetermined time.

   Untrue.

   -Andy

=== Andrew Warren -- KILLspamaiwKILLspamspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
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

2004\05\12@164040 by Lucian

flavicon
face
It could be possible, I didn't knew that the LCD's have internal
pull-ups for those lines.

Lucian

{Original Message removed}

2004\05\12@164907 by Paul James E.

picon face
" In 4 bit mode, you cannot query the busy bit" ...
 ------------------------------------------------

Don't tell my display this.  It doesn't know.  It's been checking
the busy bit in 4 bit mode now for over 4 years.






{Quote hidden}

--
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

2004\05\12@165325 by Wouter van Ooijen

face picon face
>         PORTB &= 0x0F;
>         PORTB |= c & 0xF0;

Looks like potential read-modify-write problems to me, or does the
compiler buffer port use in some way?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
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

2004\05\12@165529 by Matt Pobursky

flavicon
face
OOPS, should have said "pull-UP" resistors (and taken a quick look at
the datasheet before I posted). Ah well, at least my old tired brain
remembered the 44780 doesn't have floating inputs...

Matt

On Wed, 12 May 2004 14:17:37 -0500, Matt Pobursky wrote:
> I was thinking the same thing, Bob. Or perhaps an intermittent
> connection on the D0 line (since 44780-type controllers typically have
> pull down resistors internally on their data lines)?
>
> Matt Pobursky
> Maximum Performance Systems

--
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

2004\05\12@195712 by David Schmidt

flavicon
face
Sorry, goofed, brain fade.
I've been saving IO pins by tying the R/W pin low AND using 4 bit mode.
Kind of rolled the two together and confused them in my brain.

Dave
(going back to sleep now)

----- Original Message -----
> " In 4 bit mode, you cannot query the busy bit" ...
>  Don't tell my display this.  It doesn't know.  It's been checking
>  the busy bit in 4 bit mode now for over 4 years.

--
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

2004\05\13@024226 by hael Rigby-Jones

picon face
>-----Original Message-----
>From: Paul James E. [RemoveMEjamespTakeThisOuTspamINTERTEX.NET]
>Sent: 12 May 2004 11:49
>To: spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU
>Subject: Re: [PIC:] LCD Sometimes Displaying Unwanted Characters
>
>
>" In 4 bit mode, you cannot query the busy bit" ...
>  ------------------------------------------------
>
> Don't tell my display this.  It doesn't know.  It's been
>checking  the busy bit in 4 bit mode now for over 4 years.
>

I think you are going to have to accept your display is broken.  LCD's are
slow, but I'm fairly sure none of the operations take as long as 4 years...
:o)

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
TakeThisOuTpostmasterEraseMEspamspam_OUTbookham.com.

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

2004\05\13@085351 by M. Adam Davis

flavicon
face
Michael Rigby-Jones wrote:

>>" In 4 bit mode, you cannot query the busy bit" ...
>> ------------------------------------------------
>>
>>Don't tell my display this.  It doesn't know.  It's been
>>checking  the busy bit in 4 bit mode now for over 4 years.
>>
>>
>>
>
>I think you are going to have to accept your display is broken.  LCD's are
>slow, but I'm fairly sure none of the operations take as long as 4 years...
>:o)
>
>
>
The guy one bench over from him is probably still laughing about
replacing the LCD's oscillator with a 1 femto hertz unit.

-Adam

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

2004\05\13@113541 by Paul James E.

picon face
All,

You got me on that one.  I had to laugh at myself.  Upon rereading my
post, I realize that the way I wroded it was a little misleading.
So I guess I'll put a new LCD in the machine and go on.

                                           Later Ya'll,

                                               Jim


{Quote hidden}

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

2004\05\13@180651 by Sergio Masci

picon face
Lucian,
Can you disable interrupts at the start of your fucntions (lcd_putcmd and
lcd_putch) and re-enable them at the end. This would help you determin if your
problem is interrupt related.

I guess from your delay
>         delaycount = T_120_US;  // asteapta 120 us
>         while(delaycount);

that you are using the interrupt handler to decrement "delaycount", try changing
this to a local int and delay by counting down

e.g.
       int    my_delay;
       my_delay = 640;
       while(--my_delay);

Is it possible that your "delaycount" is being cleared or set somewhere else in
your interrupt handler and killing your original delay?


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler


{Original Message removed}

2004\05\14@032905 by Lucian

flavicon
face
I will try this also, but I inspired in my LCD routines from Bob Blick
and I guess he is more experimented than me and he hadn't had this sort
of problem. The most probable cause are the pull-down resistors tied
with the internal LCD pull-ups. After that, I will try to change the
delay from the interrupt locally to the LCd routine and disable the
interrupts while displaying something.
Thank you for your suggestion !

Lucian
{Original Message removed}

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