auto-detecting the resolution of HD44780-based LCD modules ?

Hello,

I have hooked alphanumerical LCDs on some uCs in the past and I have always had to adjust the software to the actually installed module. I have a small collection of "compatible" displays with 1 to 4 lines and 8 to 40 char/line so the software could become messy.

In applications or situations where the LCD model is not pre-determined (like, a customer intends to upgrade to another resolution in the future or you don't know if the particular reference will be available later), I have wondered what would make LCD-handling interfaces more flexible.

One solution is to add jumpers, or pads, or things like that, on the PCB. This is not really practical because when changing the module, the jumpers or pads must also be updated, which is error-inducing. This also wastes precious pins...

I know that some recent LCD controlers have advanced features but most of what I find today is cheap, standard, even old modules so I rule out advanced protocols.

A particularly simple solution that I have just found is to solder some SMD resistors (>100K) on the data bus, either to ground or Vdd. These pull-ups or pull-downs provide a few bits that the host CPU or uC can read when it does not drive the bus itself. So there is no additional pin to reserve.

HD44780 displays are also often used in "reduced wiring" : Write enable is tied to write and only 4 data bits are used. This is compatible with the pull-up/down system, because in this situation the LCD module never drives the data bus.

I remember that there may be other pull-up/downs, maybe on the LCD side, but I can't be sure now, it could vary with the manufacturer or model... Anyway, the resistors are mounted on the module and not the host PCB so the value (could be 10K or less if needed) can be adjusted without affecting the host board.

So we have 4 bits : I guess that the encoded values on the data bus can be very easy :

bits 4 & 5 : number of char/line : 0 0 8 1 0 16 0 1 20 1 1 40 ?

bits 6 & 7 : number of lines 0 0 1 1 0 2 0 1 4 1 1 error ?

So during power-up, the host CPU/uC can hold the data bus in HiZ, read the 4 bits of data and determine the dimensions. The handling routines are then updated with correct values (start addresses etc.).

More bits could be read by feeding the pull-ups with the backlight's power, for example (don't forget the diodes to prevent messing with the values) or simply with the lower nibble. But it is more important to know whether the module has the pull-up/down resistors, so the dimensions could fall back to 1x8 for example. If most modules have pull-ups, then we could encode the dimensions in reverse order so

1111 means 1x8, and then there are only pull-downs to wire...

What do the readers think about this ? Is there something similar in the wild ? Is it worth it to modify my modules to implement this method ? Am I going to get annoying side effects ? (like different addresses with different makers of modules)

YG

--
http://ygdes.com / http://yasep.org
Reply to
whygee
Loading thread data ...

You haven't described *what* you are "reading". I.e., is this *the* data bus? Or, a port dedicated to the display? Or, something else?

If you are reading a port (or a buffer explicitly decoded) dedicated to the display, then you have some control over what else is on that bus.

If you are just trying to read *the* data bus while (in theory) *nothing* is on the bus, then you are subject to whatever else happens to be *on* that bus (this is also true of the above case but presumably that is a more restricted portion of the design).

You have to pick your pup/pdn values so that everything that might *want* to drive that portion of the bus can handle the added DC load. You also have to make sure the other things on the bus don't bias the bus unexpectedly.

E.g., with lots of TTL on the bus, it will *tend* to float HI. (given enough time -- i.e., the speed of the bus needs to be taken into consideration). OTOH, if everything on the bus is *CMOS*, you might find that the bus just *stores* (capacitively) the last value driven onto it. (i.e., if the CPU writes a 0x37 and then tries to read an "undriven bus", it could read that 0x37 back! If the bus is also used to bring opcodes in from the program store, then it could just end up reading the last byte/value of the most recently fetched instruction...

Bottom line: the bus isn't a DC device. Make sure you understand its AC characteristics as well as the DC impact of your proposed change.

Can't you just burn a byte in your FLASH/ROM that represents the display being used and let your code interpret *that*?

Reply to
D Yuniskis

I am speaking about a dedicated port.

Very very often, the HD44780-like LCD modules are tied to the microcontroller with dedicated wires. The controllers are AFAIK made with very low power, and slow, silicon, so they are unsuitable for general purpose communications (the timings are too slow and could interfere with other faster devices).

Eventually, when the CPU does not have dedicated I/Os, an external latch is used : look at the LCD tied to the parallel printer port as an example.

yes, that's the point that was inherent and implicit in my original post.

Sure.

Another post on Usenet pointed me to the fact that the LCD controller has 125uA pull-ups. I knew I missed a fact or two :-)

This makes my system a bit more power-hungry. There is the LCD pull-up (equivalent to 40K), then eventually the configuration SMT resistor (about 10K or less) and then the CPU/microcontroller must provide more than 1mA to reverse the data again when needed.

However, detection becomes easier because unmodified modules will read "1111" and can be handled with certainty. On top of that, the integrated pull-up make external pull-ups unnecessary and only pull-downs are needed.

with a microcontroller, this amounts to reflashing the memory after a recompile, so I see no advantage for field upgrades. For example, a technician has to carry a computer with the programming tool, or even bring a new board with new firmware, just because the LCD module is upgraded :-/

Anyway thank you for the remarks, I just hoped that my idea was not completely stupid and it looks almost feasible (at least when power consumption is not an issue).

YG

--
http://ygdes.com / http://yasep.org
Reply to
whygee

OK

Usually sinking current isn't a problem. And, many "dedicated I/O ports" can also source a fair bit of power. Though this is still power that you need to supply (if you have a tight power budget).

Presumably, the modules can't be "significantly" modified. I.e., tacking on a few resistors is relatively trivial (though SMT components may prove harder to find good mounting pads) but adding other (e.g., active) components would be out of the question (?)

For example, could you add a small serial memory device that you could query? (i.e., think in terms of the way DIMMs are identified) More expensive than resistors but more versatile.

No. I am saying your firmware knows how to handle all of these modules (this must be the case for *your* scheme, too, since your firmware doesn't know what module will be attached). You can reserve one memory location that you reflash whenever the module is

*changed* (to a different type) -- assuming you don't have any other nonvolatile memory to use.

Can your microcontroller be reprogrammed "in system"?

Reply to
D Yuniskis

Indeed : I once had a design where I had to chase every useless mA. Pull-ups and such were consuming maybe half of the power. After that, the design was smaller and could use a cheaper/smaller LDO.

that's the idea :-) but I've done crazy 3D circuits with 0603 parts lately so i'm not afraid ...

formatting link

well, more expensive, more complex... How can one be sure that an SPI/I2C part will not interfere with the LCD ?

I've also thought about hooking a 2-wire EEPROM on the LED backlight pin but i'm not sure it's such a good idea and it would add too much code to the CPU's application.

It seems that the 4 bits provided by the pull-downs is enough, at least for my applications.

or there could be a "configuration menu" that sets the handling routine at power-up. An internal EEPROM byte (think PIC) contains the type, that is changed through the menu before changing the LCD. So no programming/flashing device to carry.

But if a clueless technician messes with the menu, the board is bricked :-/ So here comes the flashing device again, along with the portable PC...

most could but require a bulky laptop with external devices... Also the uCs are soldered so no possibility to unsocket and change the chip.

anyway, it's going forward :-)

I have also found a list of other resolutions with starting addresses at

formatting link
so it looks that i'll need to use the full 15 valid combinations of 4 bits, instead of 4x3 combinations where some don't exist.

regards, yg

--
http://ygdes.com / http://yasep.org
Reply to
whygee

This "mode" is already used to get into the "menu" (plus a hardware key).

i've been too much spoilt by the width allowed by 1x16 displays ;-P

well it's another pin, and is is used by a standard key-enabled switch.

It looks like soldering some SMT pull-down resistors is not so complex or stupid after all :-)

Thanks, YG

--
http://ygdes.com / http://yasep.org
Reply to
whygee

You could add an emergency combination, such as holding both buttons while powering up, to get into a default 1x8 mode, which works on all displays. You would have to implement the display configuration menu in that limited 1x8 space, but I think that should be possible.

A jumper could also be used to enter the config menu if that is more suitable.

--
RoRo
Reply to
Robert Roland

Hello again,

I've written a draft (incomplete, preliminary etc.) about this idea, available at

formatting link

I have found a few tricks to reduce the power draw, like tying the pull-down resistors to the RS pin instead of Vss.

Comments are welcome, YG

--
http://ygdes.com / http://yasep.org
Reply to
whygee

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.