LCD display glitches with interrupt

[Art]

Hi Guys,
Not sure what I'm asking here, but I've found when my program writes to the LCD display,
there are sometimes glitches which I believe are being caused by interrupts.
I can update the display many times to minimise this effect, but in the end, the program has other stuff to do.

What I'd like to know is whether or not the interrupt is happening part way through LCDOUT commands
(which I suspect they would at assembler level).
I can't really turn them off because I'm using DT's elapsed timer, and turning off interrupts will cause error in the real time keeping.

Do I have to just update the display as much as possible and just live with it?

[HenrikOlsson]

Hi Art,
IF that is what is happening then here's an idea which may or may not work for you....


RefreshLCD VAR BIT
UpdatingLCD VAR BIT

Main:
If RefreshLCD THEN ' LCDOUT was interrupted
GOSUB WriteLCD ' Redo the screen
RefreshLCD = 0 ' Clear flag
ENDIF

'And all the other stuff
Goto Main

WriteToLCD:
UpdatingLCD = 1
LCDOUT.....
UpdatingLCD = 0
RETURN

ISR:
IF UpdatingLCD = 1 THEN ' LCDOUT statement was interrupted..
RefreshLCD = 1 ' Signal main routine to refresh the screen
ENDIF

' And all the other stuff
@ INT_RETURN

With that said I'm bit surprised you get garbage on the screen. I didn't think the display would notice if a command or data transaction took longer than specified in the datasheet as long as the signals aren't touched by the ISR. Are you sharing any pins that the ISR may flip?

/Henrik.

[Heckler]

What if you only updated the LCD immediatly after a timer interrupt... or if the timer INT is happening too frequently to get through one cycle of LCD update you may have to offload one of the processes to a second PIC.

This is probably evidence you are reaching the outer limits of what one PIC can do and keep all the tasks properly serviced.

How about using a small 12f683 to mark time via the elapsed timer INT and have it only bother the other Main PIC when enough tic's have passed that the main PIC needs to know about it.

something to chew on.

[Art]

Thanks Heckler, I have done something similar after Googling the problem,
but since the device is in a car, I can't test it every time I change something,
and tend to wait till I'm driving anyway.

The ISR has RB0 trigger as a possible source as well. I have tried this:



intsync = 0
LCDOUT $FE,2 'VFD cursor return home
FOR gcnt = 0 TO 39 'print data to vfd
LCDOUT vfd[gcnt] '
NEXT gcnt '
'
if intsync = 1 THEN '
intsync = 0 '
LCDOUT $FE,2 'VFD cursor return home
FOR gcnt = 0 TO 39 'print data to vfd
LCDOUT vfd[gcnt] '
NEXT gcnt '
endif '
'
if intsync = 1 THEN '
LCDOUT $FE,2 'VFD cursor return home
FOR gcnt = 0 TO 39 'print data to vfd
LCDOUT vfd[gcnt] '
NEXT gcnt '
endif '


40 char, single line display.
The ISR sets the status of intsync.
Fingers crossed ;)

[Darrel Taylor]

LCDOUT is a "Synchronous" command. Meaning that data is clocked in only when it's known to be valid on the data buss.
It is not affected by interrupts at all.

LCDOUT's in the ISR could be problematic, but I doubt you have any in there.

You are using a long cable to the display right?

[Art]

Yes Darrel, but I've since tried some other things, and am almost ready to discount interrupts as the problem.

I now think it's to do with writing custom characters to the display, or more accurately altering custom characters.
This is happening frequently with both the timer, and a tachometer bargraph.
I might just have to give up the rolling odometer effect for the elapsed timer.

[fratello]

I have three "type" of LCD display ; all are HD44780 compatible, all are Made in P.R.C. .
Two of them "react" verry slow : it's impossible to use "scroll effect" and, sometimes, glitches...
One of them (top of picture, left) it's OK ! All the informations are displaying correct and without any glitches, no matter what.
I tested them using same hardware : 16F684 - without ussing interrupts !!!
Maybe the hardware inside of LCD's it's the problem !

[Art]

It does appear to be the LCD, it's a VFD actually, but with the same controller so LCDOUT commands are used.

I am able to confirm everything is fine if I do not update any custom characters, but can use them if they are defined
at the start of the program and then not changed, so no scroll effect :(

One interesting thing I learned is that if a custom character is being displayed, and then you change it,
the display does not need to be updated, the character changes instantly on the display.