Questionable for me. These LCDs need 1mA or less that's why people like them, can run long time from battery. Thats also the reason for the low clocking frequeny. A potential of o.2v or so through a high-impedance IO structure wont harm CMOS. I doubt its happening, it will sag down the rest of the port, but as I said, these Hitachi LCDs are very conservative in terms of using power.

Maybe so but the datasheet for the Atmel AT89S52 guarantees only 60 uA (yes, microamps) at a minimum of 2.4V sourced from P1, P2 or P3. That's it. Likewise, the Hitachi datasheet gives a typical consumption of 600uA at 5V at 250KHz clock. Could the uC source more or the LCD controller require less? Could be, but a whole squad of engineers and technical writers at Atmel and Hitachi went out of their way to say they wouldn't guarantee it. That's enough for me.

There isn't any reason to go off into the weeds here. I've done lots of 44780 stuff - including 8051 class machines in C and assembler. If you have a decent source of power, hook up the contrast, mind the initialization and timings and know how to read and write your IO, the display will work just fine without resorting to heroic measures.

 

Maybe so but the datasheet for the Atmel AT89S52 guarantees only 60 uA (yes, microamps) at a minimum of 2.4V sourced from P1, P2 or P3. That's it. Likewise, the Hitachi datasheet gives a typical consumption of 600uA at 5V at 250KHz clock. Could the uC source more or the LCD controller require less? Could be, but a whole squad of engineers and technical writers at Atmel and Hitachi went out of their way to say they wouldn't guarantee it. That's enough for me.

There isn't any reason to go off into the weeds here. I've done lots of 44780 stuff - including 8051 class machines in C and assembler. If you have a decent source of power, hook up the contrast, mind the initialization and timings and know how to read and write your IO, the display will work just fine without resorting to heroic measures.

Yes I agree, it can be done. I found using small serial displays gets results faster. Can change contrast in software.

Really just 60uA? I have run a PIC 16F57 with 5x5 yellow LEDs directly from 2.4v
Quite decent brightness, and it did run for quite a few days from 2x NiMH cells.

If you have doubts, use a saturated transistor switch, oh well, that will need 1/10 for itself and who knows how it works at 600uA?

I have powered a small 8x2 display from 1.2v AAA with a MCP1640, using charge pump IC for the bias.
It had some range of voltage where it would work well. If you just have an user, they dont want to adjust two voltages, and probably even measure them, so you carefully need to test the range where it works properly, then set it somewhere inbetween.

Sure 5v is easier, just one adjuster for the contrast.

As a bonus, you get japanese Katakana font on these, its quite an effort to make defines for them. A beginner can spend months just perfectioning the way using these Hitachi displays.

 

Really just 60uA? I have run a PIC 16F57 with 5x5 yellow LEDs directly from 2.4v

This isn't a PIC, its an ATMEL 89S52. Big difference. Ditto for the MCP1640. RTFDS.

I get what you are saying but the TS is not in a position to use those approaches with the ATMEL.

 

This isn't a PIC, its an ATMEL 89S52. Big difference. Ditto for the MCP1640. RTFDS.

I get what you are saying but the TS is not in a position to use those approaches with the ATMEL.

OK I looked, the sheet says, at 60uA the port IO line could drop down to 1/2Vcc ?
On the other hand supposedly it can drive several TTL inputs.

Are the Atmels really fundamentally different? The LCD isnt a total short, same as LEDs it has a forward voltage. To a load which has a forward voltage, IO lines behave such as if they would have a small resistance.

Sure at 2.4V you dont get 2.4 volts out but its close (with a LED which has 2.2v forward voltage).

You can never know for sure, there might a small capacitor, and ICs draw dynamic loads, but I think when testing, you'd find a safe area, and trip points where you get trouble.

Anyway the IC is only specified at 5 volts, if someone says powering through IO isnt desireable, you need another buffer to satisfy your requirements. But you turn that on controlled, and fast, and all the LCD IO lines have desired value.

I've abused LCX244 at 5 volts as LED 7seg sink, 2 bit lines in parallel.

At 5 volt, a digital MOSFET is easy, should the designer see a requirement for one.

 

OK, last time through this..

On the other hand supposedly it can drive several TTL inputs. Are the Atmels really fundamentally different?

Yes. The 8051 dates back to when driving a few TTL loads was wonderful. Keep in mind that to bias TTL to a logic high requires very little source current as you are back biasing a diode. From the SN7400N datasheet (old, original TTL in use at the time of the 8051's design), a logic high is defined as 2.4V at 40uA max for one input. For a logic 0, a 1.6ma sink at <= 0.8V is required. So technically, you can only drive ONE TTL load with the 8051 (instead of the 4 claimed - and what I remember) if you are a stickler for specs (and we know I am). It would drive 4 LSTTL loads and more CMOS etc. but the point is, its a pretty wimpy port but par for the course for its time. The various Intel 8xxx peripherals 8x55 etc. are about the same. You get the logic level but have to provide the buffer. We are spoiled by PICs and later uCs which have good port drives but you can't make assumptions about other parts.

but I think when testing, you'd find a safe area, and trip points where you get trouble.

Here's where we depart in our thinking. My take on it is that Atmel and Hitachi have already done the testing and posted their results. To push things further to see what you can get away with might be an interesting exercise if that's what you want to do but the TS is not asking for that and that's why we're having the conversation. My view is that we should address the TS's problem and condense his issues towards a solution of the stated problem, not to introduce a bunch of additional unknowns. JMHO.

I've abused LCX244 at 5 volts as LED 7seg sink, 2 bit lines in parallel.

I don't think we'll find any common ground there.

Its always fun, though. Lets see how the TS is getting along.

 

So my current ssituation stands as follows:
I have added a reset button to my perf board circuit. However, its not woking like the one on my dev board.
On my perf board, when I power on my circuit after every 30 mins or so, the LCD displays correctly for a few seconds before the letters change to some other ascii characters(same ones each time). Pressing reset doesnt change anything(same letters are displayed). At this point, when I switch off and switch on power again, LCD fails to initialize(black boxes appear).
After keeping the circuit idle for about 30 mins, same things happen all over.
Components have been soldered solidly. Thick single strand wires have been used for short links.
I have changed a couple of things in the circuits: added a 100nF capacitor between Vss and Vcc of LCD.
Pull down resistor at P0.1 pin for EN of LCD causes LCD to not initialize at all.(I hope that is what JohnINTx meant)
I have also added a 2 sec delay approx before initializing LCD at all. Also increased delays several times.
P.S. All connections have been throughly inspected using multimeter continuity test. Results are positive.
Any ideas?

 

Pull down resistor at P0.1 pin for EN of LCD causes LCD to not initialize at all.(I hope that is what JohnINTx meant)

Yes and no. Yes, you should pull E down for the reasons stated. No, you can't have E on P0, its open-drain so without a pullup, E won't work. Try relocating E to one of the other ports and pull it down as noted.

Are you still using the same code and schematic? Are you sure you are allowing 40uS between all character writes?

when I power on my circuit after every 30 mins or so, the LCD displays correctly for a few seconds before the letters change to some other ascii characters(same ones each time). Pressing reset doesnt change anything(same letters are displayed)

30min is power-off for a cold start?
What other characters does the LCD change to?
Do you mean that after a reset, the same incorrect characters are displayed? That would imply init problems still.

Your original code really hammers the LCD in a tight loop. That should be OK but I'd try sending several messages in the loop with a couple of seconds delay between them to see what happens.

EDIT:
What are you using for a power supply?
Are there other noisy things in the circuit (relays, motors etc?) If so, disable them for now.
Have you looked at the sample code for the ULTRA 8051 board? Its pretty good...

 

Yes and no. Yes, you should pull E down for the reasons stated. No, you can't have E on P0, its open-drain so without a pullup, E won't work. Try relocating E to one of the other ports and pull it down as noted.

But doesn't the other ports have internal pull ups already? Will adding a 10k resistor between, say, pin P1.0 and GND do?

Are you still using the same code and schematic? Are you sure you are allowing 40uS between all character writes?
Your original code really hammers the LCD in a tight loop. That should be OK but I'd try sending several messages in the loop with a couple of seconds delay between them to see what happens.

I have also tried displaying several different messages with approx 2 sec delay in-between. However, after a cold start, only the first message is displayed properly and then it changes to ASCII characters which I don't know how to represent in text.

30min is power-off for a cold start?

I haven't exactly measured the time. But sometimes it works even after 10 mins.

What other characters does the LCD change to?
Do you mean that after a reset, the same incorrect characters are displayed? That would imply init problems still.

Yes it changes to the same incorrect characters every time. And once it goes into this state, it doesn't initialize the next time I turn on power. It feels like the data sequence changes suddenly, 2 secs(approx) after power is switched on. Anyone looking at it the first time would say that it was a case of loose connection. But I have thoroughly checked it. There aren't any loose connections or dry solder.
More interesting is the fact that the same circuit works on my Dev Board after I press the reset button. But doesn't work on my perf board. Only difference is that the Dev board is a PCB.

What are you using for a power supply?
Are there other noisy things in the circuit (relays, motors etc?) If so, disable them for now.
Have you looked at the sample code for the ULTRA 8051 board? Its pretty good...

I'm using a 9V battery as a supply along with a L7805 voltage regulator.
My perf board only has my LCD and my uC along with the L7805.

My entire circuit is drawing about 40mA of current from the 9V battery.

 

Test your circuit with a wall adapter or power supply instead of a 9V battery.

 

Feels weird, I use a loosely cobbled together 16lf1709 circuit with a coil for clocking, a piezo and a LED.

For Nokia 5110 displays, testing them before shipping.
I just insert the second battery + it starts up. Powering from 2x AA batteries.

It beeps and blinks too.

 

Test your circuit with a wall adapter or power supply instead of a 9V battery.

Could it be that the 9V battery is unable to provide sufficient current? But does an LCD and a MCU take that much of current together?

 

Could it be that the 9V battery is unable to provide sufficient current? But does an LCD and a MCU take that much of current together?

Thinking that too. Working backwards through your post #28:
What kind of 9V battery?

When it starts acting flaky, can you measure the 5V supply to see that it's still up? Wondering if the voltage is drooping. Are you driving the 8051 Ultra board from the same battery and it works? If so, its likely not an issue but check it, OK? OTOH, if you are powering the Ultra from a wall-wart maybe you have battery issues.

Something to consider is that your proto board does not have a big capacitor on its power input like the Ultra does. The LCD has a minimum Vcc rise time of 100us (form the 44780 datasheet) to ensure a proper power on reset. A battery won't have the slow rise that you get with a big cap on the input. Plus, connecting the battery is never a clean step-function - the ragged connecting may be violating reset timings.

I don't think your regulator is overheating. At 40ma, the power dissipation is .16W. At 230 degC/W junction to ambient for a 78L05 with a 40C ambient is a Tj of 76 degC. OK. The reason I looked at it is that the transistor-sized (TO-92) regulators frequently have heating issues.

Short answer - make sure your power is stable throughout the failure sequence.

Yes it changes to the same incorrect characters every time. And once it goes into this state, it doesn't initialize the next time I turn on power. It feels like the data sequence changes suddenly, 2 secs(approx) after power is switched on.

For the first sentence, I would think firmware issues but - the second sentence says hardware.

I have also tried displaying several different messages with approx 2 sec delay in-between. However, after a cold start, only the first message is displayed properly and then it changes to ASCII characters which I don't know how to represent in text.

Whew! If the power and timings are stable.. This could indicate that you are not returning E to a logic low after the first message and it is picking up junk?? WooHoo..

So answer this - if you run the exact same code on the Ultra board does it work?

Can you post your current schematic and code?

 

Powered up my circuit from the dev board itself(which is powered by a wall adapter). Same thing happening.

So answer this - if you run the exact same code on the Ultra board does it work?

Can you post your current schematic and code?

My schematic is just the same as before. Code is same too except increase of delay by increasing the value of the parameter sent by delay().

The exact same code, even the exact same LCD and uC combination is working on the Dev board. But its not working on my perf-board.

BTW, the cold boot time is 30secs and not 10mins. I measured it properly this time.