Forums

How often to re-initialize a character LCD display?

Started by mpm June 6, 2018
I'm just wondering what "standard practice" is for re-initializing a character-based LCD display (i.e., a 2x16 backlit LCD)?

I have a project in the works now that erratically displays a blank LCD.
I haven't quite tracked down what might be wrong, but I could "fix" the whole issue by just re-initializing the LCD on every pass.  (This is very simply loop software..., check some inputs, throw some relays, etc..)

I don't think it's a flaky LCD, and like I said, I'm not 100% sure why it's doing this?   The power rails are good and solid, and really nothing that stands out in the code (which is hand-assembler).  And probably 95%+ of that code is from other projects over the years which I know to be bulletproof.

So, not asking for help on the "fix".  

I'm just wondering how often (if ever?) folks re-initialize the LCD display?
This particular code never "sleeps".

If it did, I could more easily justify re-setting the LCD (via initialization) when coming out of low-power, or power-down modes.  (You know, just to be sure!)

This project uses an AT89LP51ED2 8-bit, 8051 derivative -- and the standard Hitachi language LCD character display.  Nothing special.  (The LCD is interfaced in 4-bit mode, and my code has complete control over it.)

Nothing unexpected if I'm in front of it, even if for hours.
But leave it a few days or weeks, and sometimes the LCD will be blank even though the code is working fine otherwise.  A reset fixes it, as does a software switch (toggle a port pin) to call the LCD init routine.
On 06/06/18 13:18, mpm wrote:
> I'm just wondering what "standard practice" is for re-initializing a character-based LCD display (i.e., a 2x16 backlit LCD)? > > I have a project in the works now that erratically displays a blank LCD. > I haven't quite tracked down what might be wrong, but I could "fix" the whole issue by just re-initializing the LCD on every pass. (This is very simply loop software..., check some inputs, throw some relays, etc..) > > I don't think it's a flaky LCD, and like I said, I'm not 100% sure why it's doing this? The power rails are good and solid, and really nothing that stands out in the code (which is hand-assembler). And probably 95%+ of that code is from other projects over the years which I know to be bulletproof. > > So, not asking for help on the "fix". > > I'm just wondering how often (if ever?) folks re-initialize the LCD display? > This particular code never "sleeps". > > If it did, I could more easily justify re-setting the LCD (via initialization) when coming out of low-power, or power-down modes. (You know, just to be sure!) > > This project uses an AT89LP51ED2 8-bit, 8051 derivative -- and the standard Hitachi language LCD character display. Nothing special. (The LCD is interfaced in 4-bit mode, and my code has complete control over it.) > > Nothing unexpected if I'm in front of it, even if for hours. > But leave it a few days or weeks, and sometimes the LCD will be blank even though the code is working fine otherwise. A reset fixes it, as does a software switch (toggle a port pin) to call the LCD init routine. >
The Hitachi-compatible 16x2 display chips vary in the delays they need after each kind of operation. If you have a flaky system, add some big delays. If it's not flaky any more, go looking for which delays fixed it and reduce them to the required duration. Clifford Heath.
AT Wednesday 06 June 2018 14:07, Clifford Heath wrote:

> On 06/06/18 13:18, mpm wrote: >> I'm just wondering what "standard practice" is for re-initializing a >> character-based LCD display (i.e., a 2x16 backlit LCD)? >> >> I have a project in the works now that erratically displays a blank LCD. >> I haven't quite tracked down what might be wrong, but I could "fix" the >> whole issue by just re-initializing the LCD on every pass. (This is very >> simply loop software..., check some inputs, throw some relays, etc..) >> >> I don't think it's a flaky LCD, and like I said, I'm not 100% sure why >> it's doing this? The power rails are good and solid, and really nothing >> that stands out in the code (which is hand-assembler). And probably 95%+ >> of that code is from other projects over the years which I know to be >> bulletproof. >> >> So, not asking for help on the "fix". >> >> I'm just wondering how often (if ever?) folks re-initialize the LCD >> display? This particular code never "sleeps". >> >> If it did, I could more easily justify re-setting the LCD (via >> initialization) when coming out of low-power, or power-down modes. (You >> know, just to be sure!) >> >> This project uses an AT89LP51ED2 8-bit, 8051 derivative -- and the >> standard Hitachi language LCD character display. Nothing special. (The >> LCD is interfaced in 4-bit mode, and my code has complete control over >> it.) >> >> Nothing unexpected if I'm in front of it, even if for hours. >> But leave it a few days or weeks, and sometimes the LCD will be blank >> even though the code is working fine otherwise. A reset fixes it, as >> does a software switch (toggle a port pin) to call the LCD init routine. >> > > The Hitachi-compatible 16x2 display chips vary in the delays they need > after each kind of operation. If you have a flaky system, add some big > delays. If it's not flaky any more, go looking for which delays fixed > it and reduce them to the required duration.
Quite often the cheap displays containing these controllers have no internal caps on the power supply. I had similar problems that several times when the customer switched to cheaper displays. But your argument about the timing is also correct, the required timing seems to vary with he moon phase. -- Reinhardt
On 6/06/2018 1:18 PM, mpm wrote:
> I'm just wondering what "standard practice" is for re-initializing a character-based LCD display (i.e., a 2x16 backlit LCD)? > > I have a project in the works now that erratically displays a blank LCD. > I haven't quite tracked down what might be wrong, but I could "fix" the whole issue by just re-initializing the LCD on every pass. (This is very simply loop software..., check some inputs, throw some relays, etc..) > > I don't think it's a flaky LCD, and like I said, I'm not 100% sure why it's doing this? The power rails are good and solid, and really nothing that stands out in the code (which is hand-assembler). And probably 95%+ of that code is from other projects over the years which I know to be bulletproof. > > So, not asking for help on the "fix". > > I'm just wondering how often (if ever?) folks re-initialize the LCD display? > This particular code never "sleeps". > > If it did, I could more easily justify re-setting the LCD (via initialization) when coming out of low-power, or power-down modes. (You know, just to be sure!) > > This project uses an AT89LP51ED2 8-bit, 8051 derivative -- and the standard Hitachi language LCD character display. Nothing special. (The LCD is interfaced in 4-bit mode, and my code has complete control over it.) > > Nothing unexpected if I'm in front of it, even if for hours. > But leave it a few days or weeks, and sometimes the LCD will be blank even though the code is working fine otherwise. A reset fixes it, as does a software switch (toggle a port pin) to call the LCD init routine. >
It has constraints on the rise and fall time of the clock signal. If you're driving it through a level-shifter, you might not be complying with them Sylvia.
On 06/06/2018 03:10 AM, Reinhardt Behm wrote:
> AT Wednesday 06 June 2018 14:07, Clifford Heath wrote: > >> On 06/06/18 13:18, mpm wrote: >>> I'm just wondering what "standard practice" is for re-initializing a >>> character-based LCD display (i.e., a 2x16 backlit LCD)? >>> >>> I have a project in the works now that erratically displays a blank LCD. >>> I haven't quite tracked down what might be wrong, but I could "fix" the >>> whole issue by just re-initializing the LCD on every pass. (This is very >>> simply loop software..., check some inputs, throw some relays, etc..) >>> >>> I don't think it's a flaky LCD, and like I said, I'm not 100% sure why >>> it's doing this? The power rails are good and solid, and really nothing >>> that stands out in the code (which is hand-assembler). And probably 95%+ >>> of that code is from other projects over the years which I know to be >>> bulletproof. >>> >>> So, not asking for help on the "fix". >>> >>> I'm just wondering how often (if ever?) folks re-initialize the LCD >>> display? This particular code never "sleeps". >>> >>> If it did, I could more easily justify re-setting the LCD (via >>> initialization) when coming out of low-power, or power-down modes. (You >>> know, just to be sure!) >>> >>> This project uses an AT89LP51ED2 8-bit, 8051 derivative -- and the >>> standard Hitachi language LCD character display. Nothing special. (The >>> LCD is interfaced in 4-bit mode, and my code has complete control over >>> it.) >>> >>> Nothing unexpected if I'm in front of it, even if for hours. >>> But leave it a few days or weeks, and sometimes the LCD will be blank >>> even though the code is working fine otherwise. A reset fixes it, as >>> does a software switch (toggle a port pin) to call the LCD init routine. >>> >> >> The Hitachi-compatible 16x2 display chips vary in the delays they need >> after each kind of operation. If you have a flaky system, add some big >> delays. If it's not flaky any more, go looking for which delays fixed >> it and reduce them to the required duration. > > Quite often the cheap displays containing these controllers have no internal > caps on the power supply. I had similar problems that several times when the > customer switched to cheaper displays. But your argument about the timing is > also correct, the required timing seems to vary with he moon phase. >
Those eBay-special displays can be pretty sensitive to brownouts/droops/noise on the supply rail; even very brief dips in the supply or EMI injected from a motor spinning up or relay switching can cause the controller IC to latch up and the display won't come back up until the power is cycled. I would ensure the supplies and ground were actually as "solid" as I thought they were
AT Wednesday 06 June 2018 15:21, bitrex wrote:

> On 06/06/2018 03:10 AM, Reinhardt Behm wrote: >> AT Wednesday 06 June 2018 14:07, Clifford Heath wrote: >> >>> On 06/06/18 13:18, mpm wrote: >>>> I'm just wondering what "standard practice" is for re-initializing a >>>> character-based LCD display (i.e., a 2x16 backlit LCD)? >>>> >>>> I have a project in the works now that erratically displays a blank >>>> LCD. I haven't quite tracked down what might be wrong, but I could >>>> "fix" the >>>> whole issue by just re-initializing the LCD on every pass. (This is >>>> very simply loop software..., check some inputs, throw some relays, >>>> etc..) >>>> >>>> I don't think it's a flaky LCD, and like I said, I'm not 100% sure why >>>> it's doing this? The power rails are good and solid, and really >>>> nothing >>>> that stands out in the code (which is hand-assembler). And probably >>>> 95%+ of that code is from other projects over the years which I know to >>>> be bulletproof. >>>> >>>> So, not asking for help on the "fix". >>>> >>>> I'm just wondering how often (if ever?) folks re-initialize the LCD >>>> display? This particular code never "sleeps". >>>> >>>> If it did, I could more easily justify re-setting the LCD (via >>>> initialization) when coming out of low-power, or power-down modes. >>>> (You know, just to be sure!) >>>> >>>> This project uses an AT89LP51ED2 8-bit, 8051 derivative -- and the >>>> standard Hitachi language LCD character display. Nothing special. >>>> (The LCD is interfaced in 4-bit mode, and my code has complete control >>>> over it.) >>>> >>>> Nothing unexpected if I'm in front of it, even if for hours. >>>> But leave it a few days or weeks, and sometimes the LCD will be blank >>>> even though the code is working fine otherwise. A reset fixes it, as >>>> does a software switch (toggle a port pin) to call the LCD init >>>> routine. >>>> >>> >>> The Hitachi-compatible 16x2 display chips vary in the delays they need >>> after each kind of operation. If you have a flaky system, add some big >>> delays. If it's not flaky any more, go looking for which delays fixed >>> it and reduce them to the required duration. >> >> Quite often the cheap displays containing these controllers have no >> internal caps on the power supply. I had similar problems that several >> times when the customer switched to cheaper displays. But your argument >> about the timing is also correct, the required timing seems to vary with >> he moon phase. >> > > Those eBay-special displays can be pretty sensitive to > brownouts/droops/noise on the supply rail; even very brief dips in the > supply or EMI injected from a motor spinning up or relay switching can > cause the controller IC to latch up and the display won't come back up > until the power is cycled. > > I would ensure the supplies and ground were actually as "solid" as I > thought they were
I had luck with one type - butnot all - by putting a tantal directly over the supply connector. -- Reinhardt
On Wednesday, June 6, 2018 at 3:21:54 AM UTC-4, bitrex wrote:
> Those eBay-special displays can be pretty sensitive to > brownouts/droops/noise on the supply rail; even very brief dips in the > supply or EMI injected from a motor spinning up or relay switching can > cause the controller IC to latch up and the display won't come back up > until the power is cycled. > > I would ensure the supplies and ground were actually as "solid" as I > thought they were
Yes - these are "El Cheapo" variety. A 16x2 white characters with blue LED backlight. $10 in single quantities from Digikey. Link: https://www.digikey.com/products/en?keywords=1471-1236-ND I will scope it today. Maybe I missed something...
On 06/06/2018 07:07, Clifford Heath wrote:
> On 06/06/18 13:18, mpm wrote: >> I'm just wondering what "standard practice" is for re-initializing a >> character-based LCD display (i.e., a 2x16 backlit LCD)? >> >> I have a project in the works now that erratically displays a blank LCD. >> I haven't quite tracked down what might be wrong, but I could "fix" >> the whole issue by just re-initializing the LCD on every pass.  (This >> is very simply loop software..., check some inputs, throw some relays, >> etc..) >> >> I don't think it's a flaky LCD, and like I said, I'm not 100% sure why >> it's doing this?   The power rails are good and solid, and really >> nothing that stands out in the code (which is hand-assembler).  And >> probably 95%+ of that code is from other projects over the years which >> I know to be bulletproof. >> >> So, not asking for help on the "fix". >> >> I'm just wondering how often (if ever?) folks re-initialize the LCD >> display? >> This particular code never "sleeps". >> >> If it did, I could more easily justify re-setting the LCD (via >> initialization) when coming out of low-power, or power-down modes. >> (You know, just to be sure!) >> >> This project uses an AT89LP51ED2 8-bit, 8051 derivative -- and the >> standard Hitachi language LCD character display.  Nothing special. >> (The LCD is interfaced in 4-bit mode, and my code has complete control >> over it.) >> >> Nothing unexpected if I'm in front of it, even if for hours. >> But leave it a few days or weeks, and sometimes the LCD will be blank >> even though the code is working fine otherwise.  A reset fixes it, as >> does a software switch (toggle a port pin) to call the LCD init routine. >> > > The Hitachi-compatible 16x2 display chips vary in the delays they need > after each kind of operation. If you have a flaky system, add some big > delays. If it's not flaky any more, go looking for which delays fixed > it and reduce them to the required duration.
The other thing to check if you can get at any of the LCD pins is to make sure that there is an oscillating signal present. LCD displays fade to nothing if they are DC biassed for any length of time. -- Regards, Martin Brown
On 06/06/2018 06:58 AM, mpm wrote:
> On Wednesday, June 6, 2018 at 3:21:54 AM UTC-4, bitrex wrote: >> Those eBay-special displays can be pretty sensitive to >> brownouts/droops/noise on the supply rail; even very brief dips in the >> supply or EMI injected from a motor spinning up or relay switching can >> cause the controller IC to latch up and the display won't come back up >> until the power is cycled. >> >> I would ensure the supplies and ground were actually as "solid" as I >> thought they were > > Yes - these are "El Cheapo" variety. A 16x2 white characters with blue LED backlight. $10 in single quantities from Digikey. > Link: https://www.digikey.com/products/en?keywords=1471-1236-ND > > I will scope it today. Maybe I missed something... > > > >
That it will run for many days or weeks without a problem and then blurp all of a sudden doesn't sound like a timing issue or noise on the clock and data lines, that usually results in garbled characters but not the whole display going down. If boards are already made and stuff re-initializing the display every so often is one of those pragmatic hacks that while not particularly elegant has probably been done before without anyone noticing.
On 06/05/2018 11:18 PM, mpm wrote:
> I'm just wondering what "standard practice" is for re-initializing a character-based LCD display (i.e., a 2x16 backlit LCD)? > > I have a project in the works now that erratically displays a blank LCD. > I haven't quite tracked down what might be wrong, but I could "fix" the whole issue by just re-initializing the LCD on every pass. (This is very simply loop software..., check some inputs, throw some relays, etc..) > > I don't think it's a flaky LCD, and like I said, I'm not 100% sure why it's doing this? The power rails are good and solid, and really nothing that stands out in the code (which is hand-assembler). And probably 95%+ of that code is from other projects over the years which I know to be bulletproof. > > So, not asking for help on the "fix". > > I'm just wondering how often (if ever?) folks re-initialize the LCD display? > This particular code never "sleeps". > > If it did, I could more easily justify re-setting the LCD (via initialization) when coming out of low-power, or power-down modes. (You know, just to be sure!) > > This project uses an AT89LP51ED2 8-bit, 8051 derivative -- and the standard Hitachi language LCD character display. Nothing special. (The LCD is interfaced in 4-bit mode, and my code has complete control over it.) > > Nothing unexpected if I'm in front of it, even if for hours. > But leave it a few days or weeks, and sometimes the LCD will be blank even though the code is working fine otherwise. A reset fixes it, as does a software switch (toggle a port pin) to call the LCD init routine. >
One thing that might be a good idea to do in future for debugging this kind of problem is if one is gonna go the China-special route on "Hitachi-compatible" 16x2 LCDs whose brain is a little chip-board-blob made by God-knows-who is I picked up some display modules from the late 1980s (also on eBay) that have the actual HD44780 OEM IC from goddamned Hitachi themselves on the board. That way one can do a "compare and contrast" on the performance and if the OEM works and the China-special doesn't you at least know the problem isn't you.