Post by thread:LCD BUSY FLAG CHECK PROBLEM

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

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_OUTwmooreTakeThisOuTcs.rmit.edu.au http://wmoore.tsx.org/ On Mon, 25 Oct 1999, John Considine wrote: {Quote hidden}> 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 >

On Mon, 25 Oct 1999 22:08:22 -0400 John Considine <.....jconsiKILLspam@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.

Thanks, that site is very helpful. Wesley Moore wrote: {Quote hidden}> 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 > > wmooreKILLspamcs.rmit.edu.au > http://wmoore.tsx.org/ > > On Mon, 25 Oct 1999, John Considine wrote: > > > 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 > >

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}> On Mon, 25 Oct 1999 22:08:22 -0400 John Considine <.....jconsiKILLspam.....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.

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> <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>           bcf     PORTA, LCD_RS_BIT    ; command mode so RS bit 0<BR>           bsf     PORTA, LCD_RW_BIT    ; we are going to Read so RW bit 1 <BR>           movlw   b'11111111'          ; set PORTB for input<BR>           tris    PORTB                ; the quick an dirty way<BR>Read_Busy  <BR>           bsf     PORTA, LCD_E_BIT     ; switch the Enable bit on <BR>           movf    PORTB, W             ; read the port with leaving a working copy in W<BR>           movwf   TEMP                 ; save LCD data addresd in TEMP<BR>           bcf     PORTA, LCD_E_BIT     ; switch E-bit off<BR>           andlw   b'10000000'          ; is bit 7 (busyflag set?)<BR>           skpz                         ; if busy flag is cleared then skip<BR>           goto    Read_Busy            ; keep reading till cleared<BR>           bcf     PORTA, LCD_RS_BIT    ; exit command mode = clear RS<BR>           movlw   b'00000000'          ; and make PORTB<BR>           tris    PORTB                ; an output port again<BR>           bcf     PORTA, LCD_RW_BIT    ; reading done, back to write<BR>           return                       ; with DD-RAM address in TEMP (note: BUSY Fl. cleared)</FONT></DIV> <DIV> </DIV> <DIV><FONT color=#000000 face=Courier size=2>Henk Tobbe - VK2GWK</FONT></DIV></BODY></HTML> </x-html>

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

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.

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

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.

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

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

In article <38167DCE.5D2B89C4spam_OUTearthlink.net>, Wagner Lipnharski <@spam@wagnerlKILLspamEARTHLINK.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

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