4 Bit LCD issue with interrupts

[sougata]

Hi,

I just encountered a problem with 4 Bit (No RW) LCD interface on a 16x2.


I am running DT's inst int on a PIC18@40MHz. There are numerous interrupt sources, INT0, CCP1, ADC. 1mS timebase interrupt driven. Only asm (rather than the actual ASM/PBP Int structure I used in my prog) did not help.

The LCD starts putting out garbage when the interrupts are enabled. Especially LCD system commands are noticed to be creating most of the trouble. Increasing command delay upto 5000uS did not help.

Re-Init (Flags = 0) would help occasionally. But then the LCD gets stuck displaying only the first line. The peculiarity is the contrast on line 1 is increased with the blocks getting visible.

I normally use LCDs either in 8BIT or serial. Would try this with DT's any pin.

Any pointers ???

[Darrel Taylor]

Hi Sougata,

The LCD interface is Synchronous, so it should not be affected by interrupts at all, just like I2C or SPI.

The only thing I can think of is that some variables are getting overwritten.
You say you did it in ASM ???

Banking issues??
<br>

[sougata]

Hi,

Thanks Darrel for responding fast. I don't think there are banking issues. I use "CHK?RP", Banksel or sometimes and manually take care mpst of the times.

I remembered have done this (4 bit) before on a 16F676 and used button scanning on the same bus as LCD. RBIF driven, didn't have any problem. It was on a 16F676 internal osc.

Anything else ?

[mackrackit]

Are the interrupt routines accessing or driving something that could be causing interference?

[sougata]

Hi Mackrackit,

Thanks for replying. In real life there would be EMI upsets (Contactors) but right now it is just on my desk. So interference rules out.

Any asm LCD test routine out there, just to check if it is getting messed in the PBP routine. Since I am not using the R/W pin I believe PBP is putting preset delays rather than polling that pin. Is there a possibility that it gets messed there. Also strange things happen. Half display.

Change the LCD too.

[mackrackit]

Is the R/W pin connected to the zero rail?

[sougata]

Hi,


Yes, I am frustrated.

[Melanie]

If enabling Interrupts is causing the LCD to misbehave then...

Is outputing to the LCD actually causing an interrupt?... ie have you connected the LCD to a pin that might itself be triggering an interrupt, and check your PIC that your LCD connections have not been bridged across to an adjacent pin that might be triggering an interrupt.

Try to enable interrupts one by one to see which one (or which ones) are causing the problem. This might give you a clue where to look further.

[Darrel Taylor]

... I use "CHK?RP", Banksel or sometimes and manually take care mpst of the times.
Oooooo, that sounds scary.

Do you use all 3 in the same program?
That'll cause some banking problems if you do.

Can you post or email me the ASM handlers?
<br>

[sougata]

Hi all,

Thanks Mel for looking. LCD is on PORTD.4 - PORTD.7 (MSSP turned OFF) RS/EN on PORTC 4, 5. So no sources of interrupt from there. Also as Darrel mentioned that LCD is a synchronous interface it should not matter much.

If I am using some of your routines or macro or I2 (I.square a.k.a Instant Interrupt) and find that it is using the PBP macro for checking page or resetting to page zero then I use that. If I am using my own ISR I use banksel. Is this wrong ??

Darrel I have never bothered how the data is actually transported to the LCD. I am studying now. Can there be issues if the timing between two nibbles get spoiled for the program doing too much in Interrupt.

I am re-structuring the code and would post it here. Also I would use LCDs from different brands and see if this cheap Chinese LCD (In fact all that are available are Chinese) is a culprit.

BTW I noticed that PBP sets the PINs as output every time LCDOUT is used. Was my observation correct. Can this be safely removed as I have manually set it as output and never use the LCDIN command in my prog.

[sougata]

Oooooo, that sounds scary.

Do you use all 3 in the same program?
That'll cause some banking problems if you do.

<br>

Although it is not the case for this prog, but I need to know. Can you please.... explain a more as I do not know much about PBP internals.

Edit: BTW I found that using 8 bit is okay. That is why I named the thread 4 BIT LCD Prob.

[Darrel Taylor]

Although it is not the case for this prog, but I need to know. Can you please.... explain a more as I do not know much about PBP internals.
I can try ...

I guess the biggest problem is with CHK?RP and RST?RP.

Each time they're used, it saves it's result to an ASM variable called PREV_BANK.
And the next time one's used, CHK?RP uses that PREV_BANK value to figure out if it needs to change the bank ... and if so ... which bits need to be set to use the least amount of code space.

Using BANKSEL or setting the bank manually does not update the PREV_BANK variable, so PBP can get lost from not knowing which bank it's really in.

Even GOTO's within an area of code that only uses CHK?RP can be problems.
For instance with this code ...

MyVar0 VAR BYTE BANK0
MyVar1 VAR BYTE BANK1
ASM
CHK?RP _MyVar1 ; 1 - this will select BANK1
movlw 12
xorwf _MyVar1,W
btfss STATUS,Z
goto Bypass

CHK?RP _MyVar0 ; 2 - this selects BANK0
btfss _MyVar0,5
goto ExitRoutine

Bypass
CHK?RP _MyVar0 ; 3 - This statement does nothing. Although the intent
movlw 34 ; was to change to BANK0, the PREV_BANK from the
movwf _MyVar0 ; last CHK?RP at step 2 says we're already in BANK0.
goto AnotherPlace ; But if we got here from the goto Bypass in step 1 ...
; then BANK1 is still selected, and it will overwrite
; the wrong RAM location in BANK1.
ExitRoutine
ENDASM

PREV_BANK works line by line from the top of the program.
GOTO's can bypass that logic.

There are many different variations of the same problem, and BANKSEL or manually setting STATUS or BSR bits will only make it worse.

Once you know how it works ... of course ... it's a piece of cake.

Some of the ways around the problems are to use the LABEL?L, L?GOTO and L?CALL macros.
<br>

Clear as MUD.

[sougata]

Using BANKSEL or setting the bank manually does not update the PREV_BANK variable, so PBP can get lost from not knowing which bank it's really in.
Clear as MUD.

Thanks for the explanation.

Using CHK?RP messes with the PREV_BANK variable. So if I use Banksel in my ASM routine (not within the main body of the program but ISR) would there be any problem ? If yes, then why ? Context is being restored automatically either through the shadow registers for High Priority or through your program if LP is used.

[Darrel Taylor]

... So if I use Banksel in my ASM routine (not within the main body of the program but ISR) would there be any problem ? If yes, then why ? Context is being restored automatically either through the shadow registers for High Priority or through your program if LP is used.

Context/Shadow registers will ensure that when it returns from the interrupt ... those 3 register sets will have the same contents in them.

But if values get written to the wrong BANK somewhere within the ISR, shadow registers can't help.

It's especially important to maintain the proper PREV_BANK when using ASM in the Main program, since there are no Shadow registers to get everything back to normal when it's finished.

And ALL ASM routines in the Main program that use any PBP macros like CHK?RP, RST?RP, MOVE?xx with other bank switching methods, should end with ...

; for 16F's ...
clrf STATUS
PREV_BANK = 0

; for 18F's
clrf BSR
PREV_BANK = 0
Which resets PBP's banking system in preparation for the next statement.
<br>

[mackrackit]

Sougata,
Just curious, are you using PBP 2.6 ?

[sougata]

Hi,

No not yet.