Searching \ for '[PIC]:HD44780 LCD init' 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: 'HD44780 LCD init'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]:HD44780 LCD init'
2002\05\09@084848 by Cuneyt Bakan

picon face
Hi all,
i am trying to init a HD44780 based LCD with 16F877 and using this wait
routine for being sure 44780 is not in busy state.

//RD[0..7] = Data bus of LCD

void wait(void)
{
       TRISD = 0XFF;           //set portd as input
       LCD_REG_SEL = 0;              //select instruction register
       LCD_R_W = 1;            //read signal
       LCD_EN = 1;                   //enable LCD
       while(RD7==1)
       {
               continue;             //check busy flag, loop if 1
       }
       TRISD = 0X00;
       LCD_R_W = 0;
       LCD_EN = 0;
       return;
}

it doesn't work. But when i replace above routine with fixed time delay
functions, i manage to init LCD.
i guess there is a timing problem but i could not solve.
thanks in advance
Cuneyt


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx

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


2002\05\09@104317 by Bob Barr

flavicon
face
On Thu, 9 May 2002 15:37:14 +0300, Cuneyt Bakan wrote:

{Quote hidden}

You may want to take a look at the assembly code being generated.

The LCD module can take a bit of time (in the nanoseconds range) to
respond to the "LCD_EN = 1" operation.
If the "while (RD7 == 1)" test is occurring on the very next machine
cycle, it can be doing its first read of the line almost
instantaneously (while the busy line is still coming up to its high
level).

If the first test sees the busy line as a low, the code will proceed
without waiting for the busy condition to clear.
The fact that the code works with a fixed delay indicates that this
sort of problem may be occurring. You could either wait with a "while
(RD7 == 0)" loop or insert a short fixed delay (a single instruction
cycle may be sufficient) before you start testing for the busy line
going low.



Regards, Bob

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


2002\05\09@122412 by Jason Harper

picon face
> //RD[0..7] = Data bus of LCD
>
> void wait(void)
> {
>         TRISD = 0XFF;           //set portd as input
>         LCD_REG_SEL = 0;              //select instruction register
>         LCD_R_W = 1;            //read signal
>         LCD_EN = 1;                   //enable LCD
>         while(RD7==1)
>         {

The 'continue' statement you had here did absolutely nothing, although I
don't think it actually hurt anything.

>         }

It can't be doing your LCD module any good for you to change your data bus
to outputs while the module is still enabled for reading!  Also, it's
invalid to change the R/W bit while E is asserted.  Use this order of
operations:

>         LCD_EN = 0;
>         LCD_R_W = 0;
>         TRISD = 0X00;
>         return;
> }

However, I think you'll still need to use fixed delays for initializing the
module: if the module has gotten into an odd state (for example, 4-bit
interface mode), then this code for checking the busy flag will not
necessarily work.
       Jason Harper

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


2002\05\09@123620 by Nick Veys

flavicon
face
> However, I think you'll still need to use fixed delays for
> initializing the
> module: if the module has gotten into an odd state (for
> example, 4-bit interface mode), then this code for checking
> the busy flag will not necessarily work.

I agree, in my experience, the busy flag is absolutely worthless.  I had
code set up w/o fixed delays and based solely on polling it.  The
performance was absolutely horrible, super slow response time with that
flag.  I switch to a hair over the maximum delay for each given
operation, fast as lightning updating.

I highly recommend ditching the busy flag and using delays.

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


2002\05\09@132343 by Andrew Warren

flavicon
face
Nick Veys <spam_OUTPICLISTTakeThisOuTspammitvma.mit.edu> wrote:

> in my experience, the [44780's] busy flag is absolutely worthless.
> I had code set up w/o fixed delays and based solely on polling it.
> The performance was absolutely horrible, super slow response time
> with that flag.  I switch to a hair over the maximum delay for
> each given operation, fast as lightning updating.

Nick:

You must have been doing something wrong; busy-flag polling is always
faster than using fixed delays.

-Andy

=== Andrew Warren -- .....aiwKILLspamspam@spam@cypress.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 PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2002\05\09@132353 by Jeff Berosik

flavicon
face
I have successfully used the busy flag with asm, no delays for a 4 MHz
clock.
Were you just continuously reading data from the first time the enable bit
went High?
I am cycling Enable High, test bit 7, enable low. Keep looping until BF is
clear.
My C is very rusty, so some adjusting of the proper looping and BF testing
is probably in order.

Also note that delays are recommended for the first half of initialization
of these displays.
My optrex which uses a HD44780 recommends 15 ms delay before anything,
write  command 0x30,  4.1ms delay, write command 0x30, 100us delay, write
command 0x30.  Now BF can be read for all future commands/ writes
I am using delays for all of my initialization, then BF for all of the rest
of the code.

I hope this helps,

Jeff Berosik

>void wait(void)
>{
>        TRISD = 0XFF;           //set portd as input
>        LCD_REG_SEL = 0;              //select instruction register
>        LCD_R_W = 1;            //read signal
>
>        while()
>        {
>                LCD_EN = 1;                   //enable LCD
>                RD7==1            ; how to appropriately test in loop.
                 LCD_EN = 0;
         }
>        TRISD = 0X00;
>        LCD_R_W = 0;
>
>        return;
>}

Bob Barr wrote:

{Quote hidden}

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


2002\05\09@132549 by Andrew Warren

flavicon
face
I just wrote:

> busy-flag polling is always faster than using fixed delays.

   Just realized that there might be some confusion, especially
   given the title of this thread.  I assert that busy-flag polling
   is best for normal operation of the LCD, but I agree that fixed,
   LONG time delays are necessary during the HD44870's
   initialization sequence.

   -Andy

=== Andrew Warren -- aiwspamKILLspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation

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


2002\05\09@132832 by Nick Veys

flavicon
face
> Nick Veys <.....PICLISTKILLspamspam.....mitvma.mit.edu> wrote:
>
> > in my experience, the [44780's] busy flag is absolutely
> worthless. I
> > had code set up w/o fixed delays and based solely on
> polling it. The
> > performance was absolutely horrible, super slow response time with
> > that flag.  I switch to a hair over the maximum delay for
> each given
> > operation, fast as lightning updating.
>
> Nick:
>
> You must have been doing something wrong; busy-flag polling
> is always faster than using fixed delays.
>
> -Andy

Thought that too, I'm guessing it was maybe a bad display or
something...

btfsc LCD,BUSY
 goto $-1

is about as simple as it gets. :)

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


2002\05\09@174215 by michael brown

flavicon
face
> Thought that too, I'm guessing it was maybe a bad display or
> something...
>
> btfsc LCD,BUSY
>   goto $-1
>
> is about as simple as it gets. :)

Nick,

I believe that's the problem right there, the same as the other guy is
having.  You guys have things a little too simple.  You need to assert the
enable signal, read the busy flag, then de-assert the enable, within the
loop.  The same rules as reading any other data from the display.

michael brown

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


2002\05\09@202233 by Nick Veys

flavicon
face
> > Thought that too, I'm guessing it was maybe a bad display or
> > something...
> >
> > btfsc LCD,BUSY
> >   goto $-1
> >
> > is about as simple as it gets. :)
>
> Nick,
>
> I believe that's the problem right there, the same as the
> other guy is having.  You guys have things a little too
> simple.  You need to assert the enable signal, read the busy
> flag, then de-assert the enable, within the loop.  The same
> rules as reading any other data from the display.
>
> michael brown

(Not that this is a problem anymore or anything, but I'm curious
nonetheless.)

So the busy flag is only valid when the enable line is selected?  Sadly
that makes sense and I am pretty sure I didn't try that when I was
playing w/it...  Hmmmmm...

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


2002\05\09@202846 by Bob Ammerman

picon face
As mentioned before, it takes the LCD a finite amount of time to bring busy
active after performing an operation. In some cases you can end up polling
it before it has managed to pull busy up.

The simple solution here is to always make sure you include a short delay
BEFORE checking for busy.

Bob Ammerman
RAm Systems

{Original Message removed}

2002\05\10@034641 by Alan B. Pearce

face picon face
>I believe that's the problem right there, the same
>as the other guy is having.  You guys have things
>a little too simple.  You need to assert the enable
>signal, read the busy flag, then de-assert the enable,
>within the loop.  The same rules as reading any
>other data from the display.

Are you saying the status register is clocked by the enable flag to refresh
it's state? I have not had occasion to use LCD's yet, but have some ideas
about doing so, so am looking for "gotcha's" before I start.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body


2002\05\10@040357 by Jinx

face picon face
> So the busy flag is only valid when the enable line is selected?
> Sadly that makes sense and I am pretty sure I didn't try that
> when I was playing w/it...  Hmmmmm...

This a snippet of code I use in all my LCD routines - not had
a problem with it yet. PortD is the 8 LCD data lines, R/W EN
and RS are on PortB. This routine is called after a command
or data is sent to the screen

busy
        bsf    portb,rw      ;set LCD RW for Read
        bank1
        movlw  b'10000000'   ;make b7 an input
        movwf  trisd
        bank0

        bsf    portb,en
rdbusy
        btfsc  portd,bflag   ;loop until Busy Flag clear
        goto   rdbusy
        bcf    portb,en
        bcf    portb,rw

        bank1
        movlw  b'00000000'   ;b7 as output again
        movwf  trisd
        bank0

        return

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2002\05\10@040756 by Jinx

face picon face
crap......always the way ain't it ? b7 should read d7

>          movlw  b'10000000'   ;make b7 an input
>          movlw  b'00000000'   ;b7 as output again

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2002\05\10@045044 by michael brown

flavicon
face
> >I believe that's the problem right there, the same
> >as the other guy is having.  You guys have things
> >a little too simple.  You need to assert the enable
> >signal, read the busy flag, then de-assert the enable,
> >within the loop.  The same rules as reading any
> >other data from the display.
>
> Are you saying the status register is clocked by the enable flag to
refresh
> it's state? I have not had occasion to use LCD's yet, but have some ideas
> about doing so, so am looking for "gotcha's" before I start.

I was saying that, but now I'm having second thoughts.  Jinx says you don't
have to, and I tend to believe what he says.  ;-)  Several people say the
key is in giving busy enough time to go high before the first check.  This
may be it.  I have always done it as though I was "clocking" the status out,
and it's worked great for me.  (it's very much faster than just doing the
time delays)  It does make sense that it would not need to be "clocked"
repeatedly.  However, that still leaves the mystery of why the busy flag
doesn't work until after the first three initialization commands have been
sent to the display controller.

michael brown

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body


2002\05\10@051159 by Jason Harper

picon face
Jinx <RemoveMEjoecolquittTakeThisOuTspamCLEAR.NET.NZ> wrote:
> busy
>          bsf    portb,rw      ;set LCD RW for Read
>          bank1
>          movlw  b'10000000'   ;make b7 an input
>          movwf  trisd
>          bank0
>
>          bsf    portb,en

When the LCD module is in read mode, ALL its data bits are outputs.  You're
fighting it on all but the high bit: at the very least this is going to
waste a lot of power, and I wouldn't be surprised if this eventually fried
the 44780's data pins.

I don't see any reference to the RS bit in your busy-wait routine.  Unless
this is being handled by the caller, I don't think this routine does quite
what you think it does if it follows a character write rather than a LCD
command.
       Jason Harper

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body


2002\05\10@061611 by Jinx

face picon face
> When the LCD module is in read mode, ALL its data bits
> are outputs.  You're fighting it on all but the high bit:

Hmm, I see your point, guess I've just been lucky. Although
the clash is typically for a few tens of microseconds, not that
that's any excuse to keep doing it, and I shall amend the port
code - thanks, you never know - that could have saved the life
of an LCD

> I don't see any reference to the RS bit in your busy-wait routine.
> Unless this is being handled by the caller, I don't think this
> routine does quite what you think it does if it follows a
> character write rather than a LCD command.

RS=0 is set before the call. In an action which sent a command
or read the LCD, RS is already 0 before calling the busy
routine. If the previous action was to send data then RS=0
is done in the write_data routine before the call

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


2002\05\10@144437 by Andrew Warren

flavicon
face
Bob Ammerman <RemoveMEPICLISTspamTakeThisOuTmitvma.mit.edu> wrote:

> As mentioned before, it takes the LCD a finite amount of time to
> bring busy active after performing an operation. In some cases you
> can end up polling it before it has managed to pull busy up.
>
> The simple solution here is to always make sure you include a
> short delay BEFORE checking for busy.

   A good way to introduce the delay is to check the busy flag
   BEFORE every LCD operation, rather than after.

   This has the side-effect of making everything run faster, too.

   -Andy

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

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspammitvma.mit.edu with SET PICList DIGEST in the body


2002\05\10@152213 by mark

flavicon
face
On 10 May 2002 at 11:44, Andrew Warren wrote:

>     A good way to introduce the delay is to check the busy flag
>     BEFORE every LCD operation, rather than after.
>
>     This has the side-effect of making everything run faster, too.
>
>     -Andy
>

That's the way I allways did it. Nice and easy.

---
Marcelo Puhl
Mensa Brasil member
http://www.mensa.com.br

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body


2002\05\10@172451 by Jinx

face picon face
>     A good way to introduce the delay is to check the busy flag
>     BEFORE every LCD operation, rather than after.
>
>     This has the side-effect of making everything run faster, too.
>
>     -Andy

Good tip, will try that

btw, I dug out the paperwork last night. I found the reason
why I'd made a blue with the port settings when reading
the busy flag. It all goes back years to a Motorola TP for the
HC11 which said that it is necessary to change the data
direction for the only the D7 port pin. This was the reference
for my first LCD code and it worked, so that's the way it
stayed. As of yesterday I humbly know better

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


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