LCD init code ...safety

Printable View

- 11th January 2011, 22:37
jorge

LCD init code ...safety

Hi everyone,

I ve been using ( for some years) the "standard" init /define routines for the classic 16x2 LCD , now i really could use some help from the hardware/software pros :o
( Melanie, Darrel ... ? )

The problem is that due to electric noise ( i guess) sometimes i get garbage chars on the LCD and it becomes useless until i reset the system again and it is initialized.

I ve all the classic 100nf capacitors across the power and coms lines and so on, but the problem time to time arises again on some units and “literally kills my controller” ( since no one is able to see what he is doing ). This may happen like once a year or so ...but we are talking about critical hardware control.

I suppose that if I could by software initialize it again, it would maybe “reset” the Hitachi controller it has inside and all the garbage would go away, without needing the classic unplug-plug again procedure for the all system.

Is it possible to initialize and config all the defines and Ports on the run without compromise the reliability of the all system?

Have you people had similar problems with noise or sporadic garbage on the LCD ?
Any advice & info would be great.

Thanks!
- 12th January 2011, 09:33
Acetronics2

Hi, Jorge

I'm curious to see your design scheme, especially the supply section ...@ 99.999% your problem is there.;)

let's add a 500-750 ms pause @ startup of the LCD, before sending a command, to let it initialize correctly ... and you get 100% ...

Alain
- 12th January 2011, 13:35
Jerson

Quote:

Originally Posted by jorge

The problem is that due to electric noise ( i guess) sometimes i get garbage chars on the LCD and it becomes useless until i reset the system again and it is initialized.

When you say electrical noise, I assume you talk about sparking / contactor / switching noise. Yes, if the power supply is not upto the mark, or if there is EM coupling into your circuit, you can face this problem.

Typically, you will want to check if you are writing to the LCD continuously. If that is the case, try slowing down the writes; it may help.

If you describe the electrical environment of your circuit, it may help understanding the causes of your described problem.

I've seen this kind of issue with another CPU in a HV breakdown tester. The moment the spark occurs due to breakdown, the CPU gets disturbed. Suppression at the source is your best defense for this kind of setup.
- 13th January 2011, 17:16
Darrel Taylor

Quote:

Originally Posted by jorge

Is it possible to initialize and config all the defines and Ports on the run without compromise the reliability of the all system?

One thing that can cause garbage characters like that is when a 4-bit interface gets out of sync, and it gets the low nibble from the last byte with the high nibble of the next byte.

Sometimes you can toggle the E line once to get it back in sync, but to detect when to do that you need to have the R/W line connected to the PIC so you can see the busy flag. If it's not busy for 1.6mS after giving it a clear screen command ($FE,1) then it's probably out of sync.

With an 8-bit interface that error can't happen.

You can also re-initialize the LCD by clearing PBP's FLAGS system variable.
On the next LCDOUT statement it will start from scratch as if power was turned on.

Code:

FLAGS = 0 LCDOUT $FE,1

In some cases, an LCD cannot be reset from software. It takes a power down sequence.
If the LCD is powered from a PIC pin, you can cycle power to the LCD, then clear the FLAGS variable.
- 4th February 2011, 05:00
mosajii

I would request him to let us know what he means by electrical noise. I assume that he is referring to sparking noise. I am of the view that sparking noise is caused by problems in your circuit. You will have to get the circuit repaired to solve the issue. It is not in any way related to the software part. :rolleyes:
- 24th February 2011, 13:53
jorge

Re: LCD init code ...safety

Quote:

Originally Posted by Darrel Taylor

One thing that can cause garbage characters like that is when a 4-bit interface gets out of sync, and it gets the low nibble from the last byte with the high nibble of the next byte.

Sometimes you can toggle the E line once to get it back in sync, but to detect when to do that you need to have the R/W line connected to the PIC so you can see the busy flag. If it's not busy for 1.6mS after giving it a clear screen command ($FE,1) then it's probably out of sync.

With an 8-bit interface that error can't happen.

You can also re-initialize the LCD by clearing PBP's FLAGS system variable.
On the next LCDOUT statement it will start from scratch as if power was turned on.

Code:

FLAGS = 0 LCDOUT $FE,1

In some cases, an LCD cannot be reset from software. It takes a power down sequence.
If the LCD is powered from a PIC pin, you can cycle power to the LCD, then clear the FLAGS variable.

thanks for all the HELP and hints.
Darrel , i ve no words to express my gratitude :rolleyes: !
You were 100% right, i used 4 bits data bus...and sometimes it was out of sycn.
you really save my day.

Note: i ve this card connected to another one that powers a 30A relay ...i guess the problem is here ( and i cannot redesign this card for zero crossing on-off...). Also a lot of cables are going thru the unit, and the FLAT cable i use to connecto to the LCD is probalby receiving a lot of EMF...).

I have the FLAG option now to reset from time to time ( also i need to program again the CGRAM ) and i will make another PCB with 8bits Data Bus.
!!!! REALLY THANKS !!!!

PS: where can i see a full desciption of what the FLAGS = 0 does in terms of the full registers/code that is running in the CPU ( i am using almost every juice i can get from the 32K of the 18f4520 ;-)