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

Exact match. Not showing close matches.
PICList Thread
'[PIC] refreshing LCD displayed values'
2006\07\10@125521 by Bob J.

picon face
I have twelve slowly changing values that I am displaying on a 16x4 display,
and am writing the values out to the display once every 10ms in my main code
loop.  I'm looking for some thoughts or ideas on how to eliminate the
flicker of the values being updated.  I've thought about using old value
registers, and coming up with a scheme to subtract each digit of the value
I'm updating from the corresponding digit of the old value, then only
updating the displayed digit if the value is not zero.  I have quite a few
variables that will be displayed so I am wondering if another scheme of
which I would read the corresponding value directly from cgram on the
display and doing something similar (not keeping a local old value
register.)

Regards,
Bob

2006\07\10@132011 by Wouter van Ooijen

face picon face
> I'm looking for some thoughts or ideas on how to eliminate the
> flicker of the values being updated.

Flicker == you see the clear / write cycle, even when the value does not
change, or
flicker == rapid changes of the lower digit(s)?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\07\10@141614 by Bob J.

picon face
Right now I'm updating everything on the screen, including static text,
that's when I see the flicker.  I'm not clearing the screen before I write
to it.

Regards,
Bob

On 7/10/06, Wouter van Ooijen <spam_OUTwouterTakeThisOuTspamvoti.nl> wrote:
{Quote hidden}

> -

2006\07\10@142233 by Maarten Hofman

face picon face
Rochester, 10 juli 2006.

Dear Bob,

You might want to give a little bit more information about your problem, but
I can see if I can clarify things here...

>From the 16*4 I assume that you are using an HD44760 compatible LCD (correct
me if I am wrong). I have never seen a HD44760 LCD display that had a
refresh rate slow enough to be noticed, so I also assume the "flicker" is
not related to that. From your suggested solution I deduce that you are
sending your digit string to the display regardless of whether the digits
need updating or not, and that the resulting digit string on the display
keeps blinking.

Now if I write a digit string over any existing digit string on any of my
HD44760 compatible LCD displays, I never see blinking, not even if it is the
same string. So the first thing I am wondering is: are you sending a clear
screen before printing the digit string, or are you overwriting the digit
string with spaces before printing the digit string? If so: don't do this,
and the flicker should stop.

If you are not doing this, and there is still flicker, then there is
something odd going on. However, let me assume that the display indeed
blanks a character before putting a new one in place. As you said, an option
would be to remember what was there and overwrite only changed digits. If
you use an 8-bit interface (it might work with a 4-bit interface too, but I
don't know how), and have the R/W bit connected to the PICmicro, you can
indeed use this interface to read which character is on a particular
location on the display, as you suggested. This scheme has the added
advantage that you can also send strings much faster to the display, as you
can poll whether the LCD is busy or not, and write immediately after it
isn't busy, instead of waiting a fixed amount of time.

Of course, this will increase the amount of lines tremendously. An
alternative is to just allocate a chunk of your RAM (e.g. 64 bytes) as your
display buffer, and use that to verify whether a particular value is going
to change, and only write the changed values to the display. I actually
wanted to use this scheme for screen updates on my 4*20 display once: just
allocate 80 bytes for the display, and have an interrupt routine send a byte
each 160us. This way I wouldn't have to worry about the display routines:
just change the memory location, and the interrupt routine would refresh the
display automatically.

Anyway, please let me know more details, especially which of my
assumptions/deductions are right, and which are wrong.

Greetings,
Maarten Hofman.



2006/7/10, Bob J. <.....rocketbobKILLspamspam@spam@gmail.com>:
{Quote hidden}

> -

2006\07\10@144324 by Mark Scoville

flavicon
face
Hi Bob, have you tried turning off the cursor in your initialization? If
not, try and see what happens.

-- Mark

{Quote hidden}

2006\07\10@144336 by Wouter van Ooijen

face picon face
> > Flicker == you see the clear / write cycle, even when the
> value does not
> > change, or
> > flicker == rapid changes of the lower digit(s)?

> Right now I'm updating everything on the screen, including
> static text,
> that's when I see the flicker.  I'm not clearing the screen
> before I write
> to it.

You (carefully?) don't answer my question, so I assume that you see
flicker even when the values-to-be-displayed do not change? That would
be weird. Or do you have a visible cursor? If so, disable it. I never
see flicker when I update everyting without clearing. In your place I
would, as a debugging try, slow the LCD operation down to one
command/data every 500ms, so you can realy see what is done to the LCD
(which might not be what you think/hope is done).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\07\10@144400 by Vasile Surducan

face picon face
On 7/10/06, Bob J. <EraseMErocketbobspam_OUTspamTakeThisOuTgmail.com> wrote:
> I have twelve slowly changing values that I am displaying on a 16x4 display,
> and am writing the values out to the display once every 10ms in my main code
> loop.  I'm looking for some thoughts or ideas on how to eliminate the
> flicker of the values being updated.

value = old value, do not update
value = new value , update with a rate of 3 readings/sec

or

change anyway the measured value with max 3 readings/sec

usualy on LCD you're not clearing the whole display, just the changing one.

Vasile

2006\07\10@151227 by Bob J.

picon face
On 7/10/06, Maarten Hofman <cashimorspamspam_OUTgmail.com> wrote:
>
> Rochester, 10 juli 2006.
>
> Dear Bob,
>
> You might want to give a little bit more information about your problem,
> but
> I can see if I can clarify things here...
>
> >From the 16*4 I assume that you are using an HD44760 compatible LCD
> (correct
> me if I am wrong). I have never seen a HD44760 LCD display that had a
> refresh rate slow enough to be noticed, so I also assume the "flicker" is
> not related to that. From your suggested solution I deduce that you are
> sending your digit string to the display regardless of whether the digits
> need updating or not, and that the resulting digit string on the display
> keeps blinking.


Correct.  I am always writing the values to the screen, regardless of
needing an update.

Now if I write a digit string over any existing digit string on any of my
> HD44760 compatible LCD displays, I never see blinking, not even if it is
> the
> same string. So the first thing I am wondering is: are you sending a clear
> screen before printing the digit string, or are you overwriting the digit
> string with spaces before printing the digit string? If so: don't do this,
> and the flicker should stop.

If you are not doing this, and there is still flicker, then there is
{Quote hidden}

No clear screen or initialization commands being sent between updates.  I do
see a little bit of flicker.  I have taken my display code out of the main
loop and the flicker stops.  The controller in the lcd is a KS0066 which is
a 44780 clone.  It appears each digit is blanking the character out prior to
it being rewritten.

Of course, this will increase the amount of lines tremendously. An
{Quote hidden}

2006\07\10@151540 by Bob J.

picon face
My apologies for not answering your response/question Vasile, but yes I do
see the flicker when the values are written to the screen even though the
value has not changed.  So I am seeing the clear/write cycle even though I
am not explicitly doing it in my code.

Regards,
Bob

On 7/10/06, Vasile Surducan <@spam@piclist9KILLspamspamgmail.com> wrote:
{Quote hidden}

> -

2006\07\10@151658 by Bob J.

picon face
On 7/10/06, Mark Scoville <RemoveMEmscovilleTakeThisOuTspamunicontrolinc.com> wrote:
>
> Hi Bob, have you tried turning off the cursor in your initialization? If
> not, try and see what happens.
>
> -- Mark


Hi Mark, no cursor.

Regards,
Bob

2006\07\10@152124 by Maarten Hofman

face picon face
>
>
> No clear screen or initialization commands being sent between updates.  I
> do
> see a little bit of flicker.  I have taken my display code out of the main
> loop and the flicker stops.  The controller in the lcd is a KS0066 which
> is
> a 44780 clone.  It appears each digit is blanking the character out prior
> to
> it being rewritten.


I have several clones as well, and none of them flicker. I always disable
the cursor though, and from other posts I deduced that the cursor might be
causing this problem. It might be good if you posted the full initialisation
code you use.

2006\07\10@154024 by Bob J.

picon face
LCDstr  db      0x33,0x32,0x28,0x01,0x0c,0x06,0x00  ;Initialization string
for LCD

0x00 the EOS terminator.

Regards,
Bob

On 7/10/06, Maarten Hofman <spamBeGonecashimorspamBeGonespamgmail.com> wrote:
{Quote hidden}

> -

2006\07\10@164000 by Mark Scoville

flavicon
face
Hi Bob, are you using the watchdog? Maybe the watchdog is tripping causing
the initialization string to be re-sent periodically and clearing the
display. This might be causing the flicker - kinda crazy, but worth checking
I suppose. I do notice that your init string has the clear display command.
I don't use the clear display command in my init string (and can't remember
why not).

I do not see flicker with any of my LCD/VFD routines. I have a section of
the PIC RAM set aside as my LCD_RAM. I have an interrupt driven routine that
writes one character to the LCD every 2mS - this is on a 2x20 display.
Basically I have an interrupt set a flag every 2mS. Then when the mainline
notices the flag is set it reads the next PIC RAM location and writes it to
the LCD. The LCD is constantly being refreshed. The mainline just pokes
values into the PIC LCD_RAM locations and the background code is responsible
for getting out to the display. It takes about 84mS to refresh the entire
display. Your initialization string is *almost* identical to what I have
been using. Mine is... 0x33, 0x32, 0x28, 0x06, 0x0C, 0x02, 0x00 (I also use
the 0x00 for EOS). I've not had any flicker problems.

Maybe try changing the init string - I don't think it will help, but what
the heck!

And maybe look at the watchdog.

Do you have another display to try? Preferably another manufacturers. Maybe
you just have a flaky display.

-- Mark

{Quote hidden}

2006\07\10@173254 by Bob Axtell

face picon face
Mark Scoville wrote:
> Hi Bob, are you using the watchdog? Maybe the watchdog is tripping causing
> the initialization string to be re-sent periodically and clearing the
> display. This might be causing the flicker - kinda crazy, but worth checking
> I suppose. I do notice that your init string has the clear display command.
> I don't use the clear display command in my init string (and can't remember
> why not).
>
>  
Just studied mine. No flicker, either.

--Bob

2006\07\10@212824 by Bob J.

picon face
Gents I switched to a different brand LCD and the problem went away.

Regards,
Bob

2006\07\11@005111 by Ravi Pailoor

flavicon
face
Bob,

> and am writing the values out to the display once every 10ms in my main code

Each character write to the LCD module needs a 2 mS delay before another
write or you will have to check for the busy status. To write 16
characters, it will take at least 30 mS. May be you are writing too
fast. Hope this helps

--
Best wishes and regards

Ravi Pailoor
Managing Director

e-CHIP INFOTEK (P) LTD.
Member - Microchip Consultant Program
GOLD LEVEL
Microchip Design House - http://www.microchip.com
Web : http://www.echip.co.in
No. 60/1, 2nd Floor, Above ICICI ATM,
Opp. St. Pius Church,
Kammanahalli Main Road,
Bangalore-560 084.
INDIA

Email : echipEraseMEspam.....vsnl.net
BSNL : +91-80-25446315

This e-mail and any attachment may contain confidential and privileged
material intended for the addressee only. If you are not the addressee,
you are notified that no part of the e-mail or any attachment may be
disclosed, copied or distributed, and that any other action related to
this e-mail or attachment is strictly prohibited, and may be unlawful.

If you have received this e-mail by error, please notify the sender
immediately by return e-mail, and delete this message. e-CHIP, its
subsidiaries and/or its employees shall not be liable for the
incorrect or incomplete transmission of this e-mail or any attachments,
nor responsible for any delay in receipt.

2006\07\11@083446 by Maarten Hofman

face picon face
>
> Each character write to the LCD module needs a 2 mS delay before another


According to Myke Predko the official specification states 160us between
characters, and 4.1ms for certain commands. I used those numbers with a
number of displays, and never ran into trouble. This doesn't mean there
aren't displays out there that will be slower (I now learned there are
displays that will blink if you overwrite a character, which was new to me
too), however, these displays are not adhering to the original
specification, and I would recommend avoiding them for that reason: if they
don't adhere to one part of the specification, they might have faults in
others as well.

Greetings,
Maarten Hofman.

2006\07\11@132709 by Matt Pobursky

flavicon
face
This is closer to the real times, but still not right...

When in doubt, go to the source -- the datasheet!

For those that are interested, I've posted the instruction timings for
the 44780 LCD controller here:

http://www.mps-design.com/misc/HD44780%20Instruction%20Times.pdf

I've also posted the entire HD44780 datasheet too as It's sometimes
hard to find online:

http://www.mps-design.com/misc/HD44780.pdf

Of course you might be (likely are) using a 44780 clone of some flavor.
Most that I've actually found datasheets for follow the timing of the
HD44780 closely. The few exceptions I've seen execute commands and R/W
operations slightly quicker. I've always had success following the
HD44780 datasheet as a reference. I also always read the RDY flag which
will guarantee you can read/write to the LCD controller as fast as it
will allow and not guess on the timing.

Matt Pobursky
Maximum Performance Systems


On Tue, 11 Jul 2006 08:34:43 -0400, Maarten Hofman wrote:
{Quote hidden}

2006\07\11@133956 by Maarten Hofman

face picon face
2006/7/11, Matt Pobursky <EraseMEpiclistspammps-design.com>:
>
> This is closer to the real times, but still not right...


You are right... I myself already had noticed I could go much faster than
160us, but I always thought that was because I was using a clone, and that
the original might be limited to that speed. Note that it does depend on
fosc, though, so a bit slower than the listed 41us might be wise.

Greetings,
Maarten Hofman.

2006\07\11@141259 by Matt Pobursky

flavicon
face
On Tue, 11 Jul 2006 13:39:55 -0400, Maarten Hofman wrote:
> 2006/7/11, Matt Pobursky <RemoveMEpiclistEraseMEspamEraseMEmps-design.com>:
>
> > This is closer to the real times, but still not right...
> >
>
> You are right... I myself already had noticed I could go much faster
> than 160us, but I always thought that was because I was using a
> clone, and that the original might be limited to that speed. Note
> that it does depend on fosc, though, so a bit slower than the listed
> 41us might be wise.

I've always found the oscillator speed to be reasonably close to the
nominal 270KHz, but since it's an RC oscillator will drift due to
voltage, temperature, moon phase, what kind of dead fish you are
waving, etc.

That's the main reason I like reading the RDY flag, as it works
regardless of the oscillator speed. If you get an abnormally fast or
slow display it will still work and to me seems the safest bet. The
only part of my driver code that relies on delays for timing is the
power-on reset initialization and that's only because you can't read
the RDY line until the LCD controller is initialized.

Matt Pobursky
Maximum Performance Systems

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