Hi

Can i check the busy flag of the display while continously keeping the
Enable high or should i pulse the enable ?

Johan

Sagaert Johan wrote:

> Can i check the busy flag of the display while continously keeping the
> Enable high or should i pulse the enable ?
>
> Johan

Not a direct answer to your question, but I found it easier to just
ignore the busy flag, and use a timer to wait for the display. That way
you can have the CPU do something useful instead of wasting time
waiting for the display.

Using a timer also simplifies the code (no need to toggle I/O direction
bits), and you won't need the R/W signal, saving an I/O pin.

Sagaert Johan wrote:

> Hi
>
> Can i check the busy flag of the display while continously keeping the
> Enable high or should i pulse the enable ?
>
> Johan

You need to strobe the enable. Someone else has mentioned that you dont
need to use it if you use a timer, this is fine for small displays (up
to 16 chars for a 2mS timer) or if you can accept a short delay in
updating. If you need a fast update on a larger display, say if you
were editing text or monitoring real time data, you need to reduce the
timer to 50uS and use the busy flag with a character buffer.

c...@aol.com wrote:
> Sagaert Johan wrote:
>
> > Hi
> >
> > Can i check the busy flag of the display while continously keeping the
> > Enable high or should i pulse the enable ?
> >
> > Johan
>
> You need to strobe the enable. Someone else has mentioned that you dont
> need to use it if you use a timer, this is fine for small displays (up
> to 16 chars for a 2mS timer) or if you can accept a short delay in
> updating. If you need a fast update on a larger display, say if you
> were editing text or monitoring real time data, you need to reduce the
> timer to 50uS and use the busy flag with a character buffer.

Strobing the enable isn't such a big deal anyway, if you intend to busy
wait. No need to optimize a delay loop :)

I agree that a timer based solution is best suited to smaller displays,
although with a suitably fast processor, bigger sized displays can be
handled fine. Right now, I'm working with a 4x20 character display.
Using a 2kHz timer interrupt, I get 25 screen updates/second, which is
plenty for the slow LCD. Interrupt overhead is about 2
usecs/character,resulting in 0.4% CPU utilization.

Arlet wrote:

> c...@aol.com wrote:
> > Sagaert Johan wrote:
> >
> > > Hi
> > >
> > > Can i check the busy flag of the display while continously keeping the
> > > Enable high or should i pulse the enable ?
> > >
> > > Johan
> >
> > You need to strobe the enable. Someone else has mentioned that you dont
> > need to use it if you use a timer, this is fine for small displays (up
> > to 16 chars for a 2mS timer) or if you can accept a short delay in
> > updating. If you need a fast update on a larger display, say if you
> > were editing text or monitoring real time data, you need to reduce the
> > timer to 50uS and use the busy flag with a character buffer.
>
> Strobing the enable isn't such a big deal anyway, if you intend to busy
> wait. No need to optimize a delay loop :)
>
> I agree that a timer based solution is best suited to smaller displays,
> although with a suitably fast processor, bigger sized displays can be
> handled fine. Right now, I'm working with a 4x20 character display.
> Using a 2kHz timer interrupt, I get 25 screen updates/second, which is
> plenty for the slow LCD. Interrupt overhead is about 2
> usecs/character,resulting in 0.4% CPU utilization.

Why would you want to busy wait? If busy just exit, try again on next
timer interrupt. You should use the busy flag at 2kHz since some
intructions take 1.6mS. 25 screen updates is fine I have found that 10
per second is fine as well, its just noticable when editing or
scrolling through a menu.

c...@aol.com wrote:
> Arlet wrote:
>
> > c...@aol.com wrote:
> > > Sagaert Johan wrote:
> > >
> > > > Hi
> > > >
> > > > Can i check the busy flag of the display while continously keeping the
> > > > Enable high or should i pulse the enable ?
> > > >
> > > > Johan
> > >
> > > You need to strobe the enable. Someone else has mentioned that you dont
> > > need to use it if you use a timer, this is fine for small displays (up
> > > to 16 chars for a 2mS timer) or if you can accept a short delay in
> > > updating. If you need a fast update on a larger display, say if you
> > > were editing text or monitoring real time data, you need to reduce the
> > > timer to 50uS and use the busy flag with a character buffer.
> >
> > Strobing the enable isn't such a big deal anyway, if you intend to busy
> > wait. No need to optimize a delay loop :)
> >
> > I agree that a timer based solution is best suited to smaller displays,
> > although with a suitably fast processor, bigger sized displays can be
> > handled fine. Right now, I'm working with a 4x20 character display.
> > Using a 2kHz timer interrupt, I get 25 screen updates/second, which is
> > plenty for the slow LCD. Interrupt overhead is about 2
> > usecs/character,resulting in 0.4% CPU utilization.
>
> Why would you want to busy wait? If busy just exit, try again on next
> timer interrupt. You should use the busy flag at 2kHz since some
> intructions take 1.6mS. 25 screen updates is fine I have found that 10
> per second is fine as well, its just noticable when editing or
> scrolling through a menu.

I was talking about two different things. The busy wait solution is
apparently what the OP is trying to use, and in that case, it doesn't
really matter how optimized the wait loop is.

The module I'm using has a worst case time of 43 usecs for writing
character data, and 1.53 ms only for clear display/cursor home. I only
use the 'clear display' command once during initialization, with timer
disabled, and using fixed long delays. After the display has been
initialized, the timer is enabled, and only the fast commands are used.
The fast commands are all guaranteed to finish before the next timer
tick.

Using a timer also allows easy implementation of blinking text, by
temporarily replacing it by spaces after so many timer interrupts.

>
>Using a timer also simplifies the code (no need to toggle I/O direction
>bits), and you won't need the R/W signal, saving an I/O pin.
>
>
You guys have not hit any display freeze problems yet. Remember the
controller is a micro and can also go "nuts" for any of the reasons that
any micro can. If you treat this as a write only memory, you have
absolutley no indication whether your data is being written to the display
or not. Using the busy bit provides you with a little more confidence that
the system is working. If the display fails to go ready within a
pre-determined time period, you can try to reset the display through
software by re-initializing, and failing that (provided you have enough
foresight to include it in the hardware design), by cycling the power to
the display since it does not have a reset line.
-Aubrey

antedeluvian wrote:

> >Using a timer also simplifies the code (no need to toggle I/O direction
> >bits), and you won't need the R/W signal, saving an I/O pin.
> >
> >
> You guys have not hit any display freeze problems yet. Remember the
> controller is a micro and can also go "nuts" for any of the reasons that
> any micro can. If you treat this as a write only memory, you have
> absolutley no indication whether your data is being written to the display
> or not. Using the busy bit provides you with a little more confidence that
> the system is working. If the display fails to go ready within a
> pre-determined time period, you can try to reset the display through
> software by re-initializing, and failing that (provided you have enough
> foresight to include it in the hardware design), by cycling the power to
> the display since it does not have a reset line.

That's a good point. I haven't had problems yet, but some LCD display
hardware may be more vulnerable than others. The display I'm using for
my next project does have a real reset line, so I'll connect the R/W
line just in case. For maximum efficiency, the timer interrupt can
check the busy bit only every screen refresh, rather than for every
character.

Hi,

I need to use a 4x20 lcd but it's my first time to use suce a device. Can
you suggest any online material that I can read so that I can implement the
LCD display on my project? I'm using a zilog mcu and I have enough pins for
all the pins of the lcd.
Thanks!

"sani_figs" <a...@yahoo.com> wrote in
news:d...@giganews.com: 

> Hi,
> 
> I need to use a 4x20 lcd but it's my first time to use suce a device.
> Can you suggest any online material that I can read so that I can
> implement the LCD display on my project? I'm using a zilog mcu and I
> have enough pins for all the pins of the lcd.
> Thanks!
> 

You have to read the datasheet of the lcd controller.

Bye Jack
-- 
Eroi non si nasce, ti incastrano
- Jim Belushi