Searching \ for 'LCD BUSY FLAG CHECK PROBLEM' 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/lcds.htm?key=lcd
Search entire site for: 'LCD BUSY FLAG CHECK PROBLEM'.

Truncated match.
PICList Thread
'LCD BUSY FLAG CHECK PROBLEM'
1999\10\25@221047 by John Considine

flavicon
face
I am having a problem when I try to check the busy flag coming from the
LCD display (BUSY_FLAG? subroutine shown below).  It is always busy but
if I remove the busy flag check it runs fine, as long as I use a slow
clock (therefore the display must not be busy).   Any suggestions why
this bit would be remaining high.   the power supply is a 7805 (5+)
being supplied by a 1 amp 12v power supply (120V wall plug in).  I have
a .1uf capacitor from +5 to ground and a .57uf cap from 12V to ground
(for decoupling so I think).  All of this is on a breadboard along with
the PIC 16C84 and Noritake LCD display 4X20 display with selectable 4 or
8 bit transfer.
Thanks.

;October 25, 1999
;


LIST P=16C84, F=INHX8M, R=DEC
include <p16c84.inc>
  __CONFIG _CP_OFF & _WDT_OFF & _RC_OSC

DISP_ON   EQU  b'00001101'
CLR_DISP  EQU  b'00000001'
ENTRY_INC  EQU  b'00000110'
MSD   EQU  H'0C'
LSD   EQU  H'0D'
TEMP   EQU  H'0E'
TEMP1   EQU  H'0F'
CHAR   EQU  H'10'
RESET_V   EQU  0
LCD_DELAY_SET  EQU  H'FF'
DD_RAM_ADD  EQU  H'80'
E   EQU  4  ; LCD Enable control line
RW   EQU  3  ; LCD Read/Write control line
RS   EQU  2
;interupt routine varibles
INT_W  EQU  H'11'
INT_S  EQU  H'12'

  org 0
RESET   goto    START
  org 4     ; RESET vector location

Int
movwf INT_W
movf STATUS, 0
movwf  INT_S

START
;pic 16c84 setup for initial state
movlw b'00000000'
movwf STATUS   ;Clear Status
clrf INTCON   ;Initialize INTCON Disable all interupts
; bsf INTCON, 3  ;Makes interupt if RB<7:4> change state
bsf STATUS,RP0
movlw b'11000111'
movwf OPTION_REG  ;Set Option Register
bcf STATUS,RP0

clrf PORTA
clrf PORTB
bsf STATUS,RP0
CLRF TRISA
CLRF TRISB
bcf STATUS,RP0

;display initialize

movlw H'20'   ;four bit transfer =h'20' 8 = h'38'
movwf PORTB
bsf PORTA,E
bcf PORTA,E

movlw DISP_ON

nop
nop
nop
nop
nop
movwf PORTB
call CMD_SEND

; movlw CLR_DISP
; call CMD_SEND

;send characters
movlw 'F'
call CHAR_REC
movlw 'I'
call CHAR_REC
movlw 'N'
call CHAR_REC
movlw 'A'
call CHAR_REC
movlw 'L'
call CHAR_REC

goto $



CMD_SEND
 movwf   CHAR            ; Command to be sent is in W
      call    BUSY_FLAG?      ; Wait for LCD to be ready
       movf    CHAR, 0
      movwf   PORTB         ; Send data to LCD
       bcf     PORTA, RW  ; Set LCD in read mode
       bcf     PORTA, RS ; Set LCD in command mode
       bsf     PORTA, E      ; toggle E for LCD
       bcf     PORTA, E
   ;send lower nibble
swapf CHAR, 0
movwf   PORTB
bsf PORTA, E
bcf PORTA, E
       RETURN

CHAR_REC
 movwf   CHAR            ; Command to be sent is in W
      call    BUSY_FLAG?      ; Wait for LCD to be ready
       movf    CHAR, 0
      movwf   PORTB         ; Send data to LCD
       bcf     PORTA, RW  ; Set LCD in read mode
       bsf     PORTA, RS ; Set LCD in command mode
       bsf     PORTA, E      ; toggle E for LCD
       bcf     PORTA, E
   ;low nibble transfer
swapf CHAR,0
movwf PORTB
bsf PORTA, E
bcf PORTA, E
       RETURN
;
BUSY_FLAG?

 bsf     STATUS,RP0       ; Select Register page 1
       movlw   0xF0             ; Set port_B for input
       movwf   TRISB
       bcf     STATUS, RP0      ; Select Register page 0
       bcf     PORTA, RS     ; Set LCD for command mode
       bsf     PORTA, RW    ; Setup to read busy flag
       bsf     PORTA, E      ; Set E high
       bcf     PORTA, E      ; Set E low
       movf    PORTB, 0      ; Read busy flag, DDram address
andlw 0xF0
movwf TEMP
bsf PORTA, E
bcf PORTA, E
swapf PORTB, 0
andlw 0x0F
iorwf TEMP
btfsc TEMP,7
; goto BUSY_FLAG?
nop
bsf STATUS, RP0
movlw 0x00
movwf TRISB
bcf STATUS, RP0
RETURN

; movwf
;       movwf   TEMP
;        btfsc   TEMP, 7
;           ; Check busy flag, high=busy
;        goto    BUSY_FLAG?
;        bcf     PORTA, RW
;        bsf     STATUS, RP0      ; Select Register page 1
;        movlw   H'00'
;        movwf   TRISB      ; Set port_B for output
;        bcf     STATUS, RP0      ; Select Register page 0
;        RETURN

end

1999\10\25@231019 by Wesley Moore

flavicon
picon face
I would suggest you visit the following page. It has truck loads of info
related to LCD's as well as source for the various aspects of LCD control
including the busy flag.

http://www.iaehv.nl/users/pouweha/lcd2.htm

___________________________________________
Wesley Moore
RMIT - BEng/BApp.Sc. 1st Year

spam_OUTwmooreTakeThisOuTspamcs.rmit.edu.au
http://wmoore.tsx.org/

On Mon, 25 Oct 1999, John Considine wrote:

{Quote hidden}

1999\10\25@232649 by Mike Keitz

picon face
On Mon, 25 Oct 1999 22:08:22 -0400 John Considine <.....jconsiKILLspamspam@spam@MAGICNET.NET>
writes:
> I am having a problem when I try to check the busy flag coming from
> the
> LCD display (BUSY_FLAG? subroutine shown below).  It is always busy

The PIC must read the data from the LCD while E is high.  The LCD returns
the data pins to tri-state as soon as E goes low.  Your program just
pulses E, the data has gone way by the time it reads it.  Rearrange to
something like:

       bsf     PORTA,E
       movfw   PORTB
       bcf     PORTB,E

Not that you're doing it here, but another common mistake is to hold E
high and read the data repeatedly.  The LCD will not change the data
output while E is high.  To find out when it becomes not busy you need to
pulse E for each read.
___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: dl.http://www.juno.com/dynoget/tagj.

1999\10\25@233441 by John Considine

flavicon
face
Thanks,  that site is very helpful.

Wesley Moore wrote:

{Quote hidden}

1999\10\26@004455 by John Considine

flavicon
face
Mike:

I did as you suggested but still the display will not light.  All that I do
is remove the goto BUSY_FLAG? and it works.  I must have looked over this
code 100 times, run it through the simulator 50 times and it still won't
cooperate.

I do appreciate your suggestions and I will leave the code as you explained.
I looked at the display timing diagram and it confirms it.

Thanks

Mike Keitz wrote:

{Quote hidden}

1999\10\26@165120 by Agnes en Henk Tobbe

flavicon
face
part 0 6095 bytes
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META content='"MSHTML 4.72.3110.7"' name=GENERATOR>
</HEAD>
<BODY>
<DIV>
<DIV><FONT color=#000000 face=Courier size=3>Hello John,</FONT></DIV>
<DIV><FONT color=#000000 face=Courier size=3>I noticed that you do a swap on
PORTB. IMHO that would not be possible.</FONT></DIV>
<DIV><FONT color=#000000 face=Courier size=3>Here is snippet of code that works
fine in several applications I have.</FONT></DIV>
<DIV><FONT color=#000000 face=Courier size=3></FONT>&nbsp;<FONT color=#000000
face=Courier size=2></FONT>
<DIV><FONT color=#000000 face=Courier size=2>; Before writing tot the LCD check
if busy<BR>; This routine returns only when LCD BUSY flag is clear<BR>; and has
the current DD-RAM address in TEMP.<BR>; (for 4 MC XTAL; E should be active for
min 480 nsec is less than 1 cycle)</FONT></DIV></DIV>
<DIV><FONT color=#000000 face=Courier size=3>;<BR></FONT></DIV></DIV>
<DIV><FONT color=#000000 face=Courier
size=2>CheckLCDBusy<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bcf&nbsp;&nbsp;&nbsp;&nbsp; PORTA, LCD_RS_BIT&nbsp;&nbsp;&nbsp; ; command mode
so RS bit 0<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bsf&nbsp;&nbsp;&nbsp;&nbsp; PORTA, LCD_RW_BIT&nbsp;&nbsp;&nbsp; ; we are going
to Read so RW bit 1
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
movlw&nbsp;&nbsp;
b'11111111'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ; set PORTB
for input<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
tris&nbsp;&nbsp;&nbsp;
PORTB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
; the quick an dirty way<BR>Read_Busy&nbsp;
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bsf&nbsp;&nbsp;&nbsp;&nbsp; PORTA, LCD_E_BIT&nbsp;&nbsp;&nbsp;&nbsp; ; switch
the Enable bit on
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
movf&nbsp;&nbsp;&nbsp; PORTB,
W&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ; read
the port with leaving a working copy in
W<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
movwf&nbsp;&nbsp;
TEMP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
; save LCD data addresd in
TEMP<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bcf&nbsp;&nbsp;&nbsp;&nbsp; PORTA, LCD_E_BIT&nbsp;&nbsp;&nbsp;&nbsp; ; switch
E-bit off<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
andlw&nbsp;&nbsp;
b'10000000'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ; is bit 7
(busyflag set?)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
skpz&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
; if busy flag is cleared then
skip<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
goto&nbsp;&nbsp;&nbsp;
Read_Busy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ;
keep reading till
cleared<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bcf&nbsp;&nbsp;&nbsp;&nbsp; PORTA, LCD_RS_BIT&nbsp;&nbsp;&nbsp; ; exit command
mode = clear RS<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
movlw&nbsp;&nbsp;
b'00000000'&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ; and make
PORTB<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
tris&nbsp;&nbsp;&nbsp;
PORTB&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
; an output port
again<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bcf&nbsp;&nbsp;&nbsp;&nbsp; PORTA, LCD_RW_BIT&nbsp;&nbsp;&nbsp; ; reading done,
back to write<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
return&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
; with DD-RAM address in TEMP (note: BUSY Fl. cleared)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#000000 face=Courier size=2>Henk Tobbe -
VK2GWK</FONT></DIV></BODY></HTML>

</x-html>

1999\10\26@175135 by paulb

flavicon
face
John Considine wrote:

> Thanks,  that site is very helpful.
>> http://www.iaehv.nl/users/pouweha/lcd2.htm

 Indeed it is.  Only complaint I have is that the "Misc. Examples"
example by Marc Simons is unnecessarily complex (has transistor
inverter/ time delay circuit that just isn't needed) and he doesn't seem
to understand why.  Oh well!

 But not on topic - said example *definitely* doesn't use Busy flag.

 I'm sure there is a trap in reading the busy flag in 4-bit mode.  You
must read the data twice every time (which means you must keep things in
synch).  I'll bet you are missing out on this or looking at the wrong
nibble for the flag bit.  Just a guess, haven't sat and analysed the
code.
--
 Cheers,
       Paul B.

1999\10\26@190804 by John Considine

flavicon
face
I will admit the 4bit does make it look more difficult but I pulled the code
from an Application Note from Microchip originally.  I have since change the
code to reflect the suggestions made by everyone.  Ironically, everyone's
suggestions have been very similar leading me to believe that I am on the
correct path.  However, I still have the problem where the LCD display will
not print the letters unless I comment out the goto BUSY_FLAG? as shown
below.  It must be something simple, but I can't catch it.

Thanks for everyone's input, I hopefully will lick this soon.


; Read busy flag, DDram address
andlw 0xF0
movwf TEMP
bsf PORTA, E
movf PORTB, 0
movwf TEMP1
bcf PORTA, E
      swapf TEMP1,0
andlw 0x0F
iorwf TEMP,0
andlw 0x80
btfss STATUS, Z
; goto BUSY_FLAG?
nop
bsf STATUS, RP0
movlw 0x00
movwf TRISB
bcf STATUS, RP0
RETURN

"Paul B. Webster VK2BZC" wrote:

{Quote hidden}

1999\10\26@194530 by Wagner Lipnharski

picon face
Everything is relative. Instead to send a byte for data and another for
instruction, the LCD controller could receive a 12 bits word containing
instruction AND data at the same time. It could be also in serial mode.
But, to save some bus width problems and turn it compatible with most of
the microprocessors, including the ones that don't have any serial
communication capability, they made the way it is, and it is easy,
isn't?  Everything looks difficult at the first view, but remember that
"difficulty" can be translated to "lack of knowledge".  I am pretty sure
that 4 bits comm to LCD is not difficult anymore for you, right?

About the BUSY flag...

1) are you sure you are setting RS "low" level when trying to read the
busy bit?
2) busy flag is read (bit 7) at the first nibble read in 4 bits mode.
3) you can not check busy flag at the first initialization
instructions... it needs pure time delays, so if your READ BUSY FLAG
routine is checking the busy flag even for the very first initialization
instructions, it will not work and will hang up waiting the busy bit
that will never come.

for further reading take a look at some initialization routines at:
http://www.ustr.net/lcd001.shtml
Wagner.

John Considine wrote:
>
> I will admit the 4bit does make it look more difficult but I pulled the code
> from an Application Note from Microchip originally.  I have since change the
> code to reflect the suggestions made by everyone.  Ironically, everyone's
> suggestions have been very similar leading me to believe that I am on the
> correct path.  However, I still have the problem where the LCD display will
> not print the letters unless I comment out the goto BUSY_FLAG? as shown
> below.  It must be something simple, but I can't catch it.

1999\10\26@194918 by Rob Gamlin

flavicon
face
Caught this half way through, may have missed some.

For what its worth I deal with 4 BIT lcd using a single 4094 on a common Data/Clock bus, therefore outputs only. As long as you issue the Busy Read command, unless the command is a Clear LCD or Clear Ram then you will have to be clocking Vfast to overrun the output. After issuing a Clear command I enforce a delay in some way to ensure the completion. LCD docs will tell you the command timings.

Hope this helps,


Rob.

1999\10\26@212523 by Dwayne Reid

flavicon
face
Hello.

I enclose a copy of a message archived almost 2 years ago - it seems to have
some bearing on the problem.  I hope this helps.

dwayne


Archived copy follows:


Regarding the good old fashioned LCD modules:

Well I thought I knew all about the standard dot matrix LCD modules,
I've been using them for long enough. But in sorting out a problem today
I had a few surprises which may be of interest.

A client had decided to update an existing PIC-powered product by
replacing the LCD with a vacuum fluorescent module (Itron CU20025),
supposedly a drop-in replacement. Ha Ha! Anyway it didn't work, so it
came to me to be "fixed".

The product drives the LCD in 4-bit mode, and tests the BUSY flag. It
soon became clear it was hanging because the nibble order was somehow
getting out of sync - hence it was testing bit 3 of the LCD data, not
bit 7. Since the lower bits are a readback of the DD address, as soon as
the address hit the right value, it all ground to a halt. But why - the
LCD version was fine?

To make a long story slightly less long, it seems (empirically) that
when the VF module is polled for busy, in 4 bit mode, the normal
requirement to always complete the twin cycle by polling for the second
nibble does not apply - every poll returns the upper nibble only. That's
UNTIL the busy flag drops, when you need to then read the other nibble
before returning. So the standard code had a 50% chance of exiting in
the wrong nibble phase.

Modified the code to loop on the first nibble only. Works fine.

Tried another tack, now I just take E high and poll D7, keeping E high
instead of cycling it. When D7 drops, read the other nibble and off we
go. This works fine too, strange but actually nicer than pumping E all
the time!

But this will mean different code for the LCD version? Oh no it doesn't,
the LCD still works with the new code! Wrote some test code to look at
it on the 'scope and sure enough, 2 mSec after the CLEAR command, D7
just drops with no other action.

Well the Hitachi book seems to say you have to clock E continuously
while testing busy, I've always done it that way, all the code I've ever
looked at does it that way, but the clean and simple static method seems
to work fine. The Hitachi book seems geared to direct CPU bus
attachments where there is not usually the option to "stall" the cycle
as one can with a port connection, so maybe the diagram showing the
continous E cycles is misleading here?

Sorry if this is old news to everybody, it certainly surprised me and
seems to contradict the usual way of doing things. Does anybody else
drive their modules like this?

And does anybody lose any sleep about getting their 4 bit interface out
of sync due to noise or whatever? I suppose that detecting a stuck
"busy" bit would be a way to pick this up and reset the module.


Regards to all,
--
Alan Hall, Ipswich, UK
(01473) 652301



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

Celebrating 15 years of Engineering Innovation (1984 - 1999)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Do NOT send unsolicited commercial email to this email address.
My posting messages to Usenet neither grants consent to receive
unsolicited commercial email nor is intended to solicit commercial
email.

1999\10\26@213754 by John Considine

flavicon
face
Yes, I followed your lead and it worked.  I placed nop after the clear display a
nd nop after bsf  PORTA, E.  I looked at the timing diagram and it requires a mi
nimum of 300ns.  The pic is running at 1us per clock cycle so I did not think th
at the timing would be a problem.  However, I do not have an oscilloscope to che
ck the timing.

One more problem.  When I go from a RC oscillator to a HS (tried both 2Mhz and 1
0Mhz) oscillator the pic keeps resetting.  I have tried a .1uf capacitor between
+5 and Ground and 1uf between +5 and Ground with no change in resetting.  Any s
uggestions.

Rob Gamlin wrote:

> Caught this half way through, may have missed some.
>
> For what its worth I deal with 4 BIT lcd using a single 4094 on a common Data/
Clock bus, therefore outputs only. As long as you issue the Busy Read command, u
nless the command is a Clear LCD or Clear Ram then you will have to be clocking
Vfast to overrun the output. After issuing a Clear command I enforce a delay in
some way to ensure the completion. LCD docs will tell you the command timings.
>
> Hope this helps,
>
> Rob.

1999\10\26@223827 by Wagner Lipnharski

picon face
Rob Gamlin wrote:
>
> Caught this half way through, may have missed some.
>
> For what its worth I deal with 4 BIT lcd using a single 4094 on a common Data/
Clock bus, therefore outputs only. As long as you issue the Busy Read command, u
nless the command is a Clear LCD or Clear Ram then you will have to be clocking
Vfast to overrun the output. After issuing a Clear command I enforce a delay in
some way to ensure the completion. LCD docs will tell you the command timings.
>
> Hope this helps,
>
> Rob.


The 1/8 duty (LCD's) or 1/11 duty models have an internal oscillator of
250kHz, what does an average instruction execution of 40 microseconds,
while Clear takes from 82us to 1.64ms, Return Home from 40us to 1.6ms.

The 1/16 duty models have an internal oscillator of 160kHz, so average
instruction is 120us, clear 120us-4.9ms, return home 120us-4.8ms.

In both cases, the Read Busy Flag takes only 1us.

Experience with an 8051 running at 16MHz, it takes about 14us per
routine loop (per character) to read a  message from the code memory and
write to to the LCD, so faster than what the LCD can deal, obviously
needing to check the busy flag.

If the uC uses a lower clock or time delays were implemented, it works
without reading the busy flag, but never will be at LCD's top speed.

By the way, there is no command Clear Ram. The command Clear Display
clears Ram and returns cursor to home position.

--------------------------------------------------------
Wagner Lipnharski - UST Research Inc. - Orlando, Florida
Forum and microcontroller web site:  http://www.ustr.net
Microcontrollers Survey:  http://www.ustr.net/tellme.htm

1999\10\27@003311 by Wagner Lipnharski

picon face
Alan Hall wrote:
[snip]
> To make a long story slightly less long, it seems (empirically) that
> when the VF module is polled for busy, in 4 bit mode, the normal
> requirement to always complete the twin cycle by polling for the second
> nibble does not apply - every poll returns the upper nibble only. That's
> UNTIL the busy flag drops, when you need to then read the other nibble
> before returning. So the standard code had a 50% chance of exiting in
> the wrong nibble phase.

Now *THAT* is something new, I need to check it out sometime. What Alan
said (long ago), was that LCD modules never supply the lower 4 bits of
the AC (Address Counter) while BUSYFLAG is up (controller unavailable).

Hitachi documentation says that the Enable (E) line is not internally
executed while BUSYFLAG is up, *EXCEPT* during reading the BUSYFLAG &
ACC Address. They are not specific if during reading the BUSYFLAG (and
if it is up) the ACC is invalid or should be discarded, because you can
not read the second nibble, thus the last 4 bits, or  otherwise.

Hitachi says literally:
"When interface data is 4 bits long, data is transferred using only 4
buses of DB4~DB7, and DB0~DB3 are not used. Data transfer between the
HD44780 and the MPU completes when 4-bit data is transferred *twice*.
Data of the higher order 4 bits (contents of DB4~DB7, when interface
data is 8 bits long) is transferred first and then lower order 4 bits
(contents DB0~DB3 when interface data is 8 bits long)."  There is no
text saying; "except when reading the busyflag that only high order 4
bits are transferred while BUSYFLAG is up..."

Until I test it I can not assume nothing, except that if something is
not documented, anything is possible, including differences from one
manufacturer to another.  There are different LCD controllers around,
not only the Hitachi HD44780, there is the Sansung KS065, the OKI M5259
and others,  Each one obeys the same commands of the HD44780, but *only*
what is documented of course.  Things not described at the "book" can be
done differently in each one, so one of them can "gate" only the
BUSYFLAG when it is up and forget the rest, since the user will keep
polling until it is down, no one would consider relevant the second
reading for the lower AC bits, so, they trick the customer, but since
the customer will be reading it twice, will never notice the problem,
and they save few gates inside the controller.

So, until tests clear this up, I would continue issuing two [E] pulses
in 4 bits mode to read the BUSYFLAG, the first to get the BUSYFLAG and
the second do skip the lower AC bits, just for precaution.

--------------------------------------------------------
Wagner Lipnharski - UST Research Inc. - Orlando, Florida
Forum and microcontroller web site:  http://www.ustr.net
Microcontrollers Survey:  http://www.ustr.net/tellme.htm

1999\10\27@010721 by Wagner Lipnharski

picon face
Just complementing,
Hitachi Japan documentation, top of page 33 of the following PDF file
tells exactly:
Interfacing to a 4-bit MPU. The HD44780U can be connected to the I/O
port of a 4-bit MPU. [snip]... Note that two cycles are needed for the
busy flag check as well as for the data transfer.... [snip].
http://www.hitachi.co.jp/Sicd/English/Products/senyou/lcd/eHD44780U.pdf

--------------------------------------------------------
Wagner Lipnharski - UST Research Inc. - Orlando, Florida
Forum and microcontroller web site:  http://www.ustr.net
Microcontrollers Survey:  http://www.ustr.net/tellme.htm

1999\10\27@060613 by Alan Hall

flavicon
picon face
In article <38167DCE.5D2B89C4spamspam_OUTearthlink.net>, Wagner Lipnharski
<@spam@wagnerlKILLspamspamEARTHLINK.NET> writes

Gosh! Somebody bookmarked my post. Fame at last. Hope I got it right!

Wagner, I agree with everything you say, especially about non-documented
features, but I think you missed my logical flow. Initially I HAD to
adopt a non-standard procedure because the ITROM VF displays just would
not work using the 2-cycle poll. My analysis was that these displays
(non-44780 controller) did not internally execute the 2-phase cycles
when BUSY was high. Every time you pulsed E you got the same result
(bits 4-7). The BUSY flag could drop on ANY polling cycle. Then you had
to do one more cycle (returning bits 0-3) to get back to the rest state.
In other words, there could be an odd number of polling cycles involved.

So if you use the "official" method, and if the internal BUSY flag
happened to drop after what you thought was the 2nd cycle, then the next
E cycle, which YOU would be expecting to return bits 4-7, would actually
be returning bits 0-3, and returning the LCD to the rest state. Now you
are out of sync and up the creek.

It was this which then led me to try static polling of the D7 bit, and
then to see if it would also work on the HD44780 controller. You are
probably correct in saying I should maintain 2 versions of the code, but
so far it seems to work fine on both these chips.

I need to so some maintenance on this product shortly, if anybody is
interested I can do some more tests.

Here's the (trimmed) snippet, note the static polling of bit 7.

;*******************************************************************
; Wait, testing busy flag, until LCD free. Need to complete the
; double nybble cycle even though we only need bit 7.

lcd_wbusy       bcf     LCD_RS
               bsf     LCD_RW
               bsf     LCD_E           ; Clock out MSD
               nop                     ; Make sure it's stable

lwbtst          btfsc   LCD_BUSY        ; Just wait for BUSY
               goto    lwbtst          ; to drop

               bcf     LCD_E
               bsf     LCD_E           ; Clock out LSD
               bcf     LCD_E
               return

--
Alan Hall, Ipswich, UK

1999\10\27@072828 by Rob Gamlin

flavicon
face
Intention was to show that if you allow the LCD not to overrun it is possible to issue the Read Busy command without checking the bit, but you must still call the Busy Flag command, that was all.

Rob Gamlin

1999\10\27@120431 by Andy Kunz

flavicon
face
>  I'm sure there is a trap in reading the busy flag in 4-bit mode.  You
>must read the data twice every time (which means you must keep things in

This is true.  It isn't hard, just be careful and it works fine.

When I was working on this for my C library to sell, I made it work by
providing low-level routines which always returned the full 8 bits, whether
working on 8-bit or 4-bit mode.

Andy

==================================================================
Eternity is only a heartbeat away - are you ready?  Ask me how!
------------------------------------------------------------------
KILLspamandyKILLspamspamrc-hydros.com      http://www.rc-hydros.com     - Race Boats
RemoveMEandyTakeThisOuTspammontanadesign.com  http://www.montanadesign.com - Electronics
==================================================================

1999\10\28@172320 by ShadeDemon

picon face
John Considine wrote:
> correct path.  However, I still have the problem where the LCD display will
> not print the letters unless I comment out the goto BUSY_FLAG? as shown
> below.  It must be something simple, but I can't catch it.
>
> Thanks for everyone's input, I hopefully will lick this soon.
>

 May not be your problem, but I have some surplus LCDs that
wouldn't work at all, then magically started working when I
switched to timing only, no busy check.  I first thought it
was my code, or that I'd blown up the flags trying to get
them to work.
 I later ran across some data sheets though that indicated
that the busy flag was not implemented, don't remember which
manufacturer they were.  But apparently some low end
manufacturer(s) either saved $.002 somehow by not putting in
read back on this register, or more likely made some bugged
parts but still felt like making some money that year, and
changed the data sheets to reflect the non-feature..  So if
you can't get them to work reliably in some way that makes
sense, whether it's reading every enable or every other
enable, it's also a possibility that it may simply not be
reliable.  And I vaguely recalled having had a MPJA catalog
(or someone with similar layout) that listed a LCD with NO
BUSY FLAG or some such in the description, so they are out
there.  Too bad it took a few days worth of work before I
remembered that bit of info..

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