HD44780 Character LCDs in Parallel?

[For The Popcorn]

I'm working on a device with a 4 line × 20 character HD44780 LCD that has a very dim backlight. The display is also at a poor angle for visibility. It's soldered in, so replacement isn't trivial.

I have a display that should be a direct replacement that is beautifully back-lit. I had two thoughts:

● Paralleling the displays to test for compatibility.

● Adding a second LCD in parallel as a second remote display.

I don't believe any damage would come from paralleling two character LCDs. And depending on how the interface is implemented, I think the scheme would work fine.

Has anybody tried this?

 

[danadak]

The issue I think is the controller onboard is async, so two async controllers trying
to access the same buss and or R/W signals sounds like a recipe for failure. The enable
is not a tri stating buss kind of enable. So no help there, eg. write to display 1, then
write to display 2.

I use those displays a lot and the blue mode displays excellent in brightness/
contrast. The old puke green displays are just awful, especially viewing angle.

There are I2C versions if thats what you have which easily could do this.


Regards, Dana.

 

[tumbleweed]

As long as you never try to read from the display (R/W always=0) I don't see why that wouldn't work.
Having a "remote" display could cause signal integrity issues, though... adding some series R in the control signals (CS, R/W, and E) to the second display should help.

Worst-case you might have to add a few 'nop' instructions after setting the control signals to allow for the extra capacitance.

 

[danadak]

But they generate a asynch busy signal, couple that with internal clock with
wide variation of the state machine, could you have a situation where 1 gets
only partial or malformed writes ? Hence display artifacts ? Not sure.....Maybe
AND the busy signals and only write when both not busy ? Worth a try....

One thing I found with this controller that made a big difference in quality of
displayed data, eg. no artifacts, was to create a ram buffer. When a write was
requested first I checked that the character was already in display, by looking at
ram, if so no writes necessary. If different display.n and ram updated. I had display
running in tight loop so this dramatically cut down the # writes, and the artifacts
that got generated when in a tight loop.

Regards, Dana.

 

[For The Popcorn]

This is for a commercial product. No chance to modify the code.

 

[tumbleweed]

But they generate a asynch busy signal...

There are lots of code examples around that completely ignore the busy signal and use the display in write-only mode. As long as you wait the req'd delay between ops no busy signal required.

This is for a commercial product. No chance to modify the code.

Then it may or may not work depending on how the product interfaces to the existing display.

 

[Pommie]

Can you trace the R/W pin? If it's grounded then it should work.

Mike.

 

[For The Popcorn]

I suspect it is. They're not doing anything fancy with the display.

Good idea.

 

[rjenkinsgb]

Can you see the ends of the original display? Some types use a flat backlight module that can slid out (and replaced?) if you can get to its two terminals?

 

[For The Popcorn]

Hmmm. That's a good idea. The end of the LED module do stick out. This unit was built in 2002, so the module could be worn out or just dim by design.

 

[Nigel Goodwin]

There are lots of code examples around that completely ignore the busy signal and use the display in write-only mode. As long as you wait the req'd delay between ops no busy signal required.


Then it may or may not work depending on how the product interfaces to the existing display.

Generally most users ignore the busy signal, and just use timed delays - there's little benefit to using the busy signal, just as there's little benefit using 8 bit mode. By ignoring the busy signal and using 4 bit mode, you save five I/O pins.

A simple check with a multimeter on ohms should show if the busy signal is grounded, and if not then give it a go paralleling it, and see what happens.

 

[For The Popcorn]

Back in the Atari 800 days, I hooked two parallel printers to a single parallel port. If only one or the other printer was powered on, the printer worked perfectly.

If both printers were on at the same time, they very politely shared the print task. One would print aaq line, the other the next! It is kind of tough to read a document that way

Apparently, while one printer was asserting its busy signal, the other one would take the next line.

 

[danadak]

If you dont want to use delays, given the internal clock can vary and delays just waste MIPS -

Using the busy signals with a single gate logic AND gate as a trigger for display write.
e.g. write when both show not busy. But a nagging thought still persists, you have two
state machines running async, but want predictive behaviour. To me thats almost an
intermediate small micro that takes the data and insures, via each display busy signal,
that each display gets a proper write. So you dont get artifacts generated......Basically acts
as a buffer and synchronizer between the data source and the individual displays. The
code to do this would be pretty simple I think.

https://www.ti.com/lit/sg/scyt129g/scyt129g.pdf

Might be worthwhile contacting Renesas engineering about this.

https://www.ti.com/lit/sg/scyt129g/scyt129g.pdf

Regards, Dana.

 

[tumbleweed]

Since the busy flag is output on the data bus DB7 line you'd have to decode a read operation with EN=1, RS=0, R/W=1.
If you enable read operations then the data bus certainly can't be paralleled between the two displays without some form of isolation.

 

[For The Popcorn]

Two displays in parallel do play together nicely. The test was successful, but disappointing.

The "new" display needs a different contrast adjustment, but there are no pots on the board. No combination of button presses revealed a menu to set it in software.

The backlight was disappointing on the new display despite the apparent LED series resistor on the board being only slightly larger than optimal value.

With proper contrast adjustment, I'd rate the new display very marginally better but not worth the effort of changing it out.

I need to trace out the connections on the board to determine exactly what's going on.

I just had the thought – it seems reasonable that the backlight might be controlled by PWM.... I need to see what documentation I can scare up to see if there's a secret setup menu.

 

[danadak]

You have a datasheet for display you can post ? And or part number for display ?


Regards, Dana.

 

[For The Popcorn]

Here is the datasheet for the display. It's the green-yellow version.

But this display is not the issue. I know I can rig up a pot to adjust Vo and hardwire 5 volts through an appropriate resistor for the backlight if I decide to change displays. There's a 10 ohm resistor adjacent to pins 15/16 so I'm assuming that's the current series resistor although I did notice a 22 ohm resistor between the 2N3904 switching transistor and the 10 ohm resistor. I need to trace the tracks to see if they are in series.

 

[danadak]

You saw this ....

You have to add a pot to do the contrast, fed to pin 3.

And power to 15, 17, thru current limit R, and grounds to 16, 18 ? And ground to pin 1.

You could control display brightness and contrast with some interface design and PWMs.
But need power handling for the B/L. In case of contrast pin you would create a PWM DAC,
eg. pwm with a low pass filter on output to smooth PWM ripple.


Regards, Dana.

 

[For The Popcorn]

Thank you for your input.

I tried to make it pretty clear that I understand about Vo, hence my comment about adding a pot if there's not a (workable) adjustment on this commercial product.

I thought it pretty clear that I understand calculating series resistors for LEDs. Yes, a 10 ohm resistor with a typical Vf of 4.2 volts is somewhat miserly for a display that would like 240mA, but the backlight should be more than faintly visible.

Both the lack of a pot and a dim display with what should be a reasonable current lead me to believe both may be firmware controlled but as I stated, I haven't found any button combination that leads to a set-up menu.

I'll know more when I trace out the board.

 

[danadak]

Thank you for your input.

I tried to make it pretty clear that I understand about Vo, hence my comment about adding a pot if there's not a (workable) adjustment on this commercial product.

I thought it pretty clear that I understand calculating series resistors for LEDs. Yes, a 10 ohm resistor with a typical Vf of 4.2 volts is somewhat miserly for a display that would like 240mA, but the backlight should be more than faintly visible.

Both the lack of a pot and a dim display with what should be a reasonable current lead me to believe both may be firmware controlled but as I stated, I haven't found any button combination that leads to a set-up menu.

I'll know more when I trace out the board.

You did make it clear and my apologies, I was asleep at the switch......

Regards, Dana.