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

Hello,
and thank you for the answer :-)

D Yuniskis wrote:
whygee wrote:
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.).
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?

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.

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)

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.
yes, that's the point that was inherent and implicit in my
original post.

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.
Sure.

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.
<snip>
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.
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.

Can't you just burn a byte in your FLASH/ROM that represents
the display being used and let your code interpret *that*?
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
.

Relevant Pages

  • Re: Real Time sharing of data between WinCE systems?
    ... Maybe you can find CAN controllers that will work from the hardware side, ... I think CAN would be ideal for the non-video networking of systems. ... When you say "short" bus lengths, could you define that a little more ... autopilot and flight plan management ...
    (microsoft.public.windowsce.embedded)
  • Re: Combined RA92-KDA50 / RLV12-RL02 problem
    ... paks on a RA92 booted MicroVAX 3900. ... I guess it some kind of conflict between the controllers but it's strange ... I would suspect some kind of bus configuration problem. ...
    (comp.os.vms)
  • Re: Bulk transfers on CAN bus - HOW
    ... Works well but we would like to use the bus to also flash the ... controllers. ... Our programming team came up with a way to do this but it's ... CAN bus is very safe but there is an amazing ammount of overhead and allows ...
    (sci.electronics.design)
  • Re: LCD image flickering
    ... enough room on the bus for the rest of the peripherals ... because in case the videomemory is an SDRAM area and the LCD ... lot of bus activity only for the display. ... Linebuffer --> Display). ...
    (microsoft.public.windowsce.platbuilder)
  • Re: DCC & N_Gauge
    ... controllers work better with certain chips than others. ... One or two older controllers (eg. ... of the way bus wires are connected to each other and the rails. ... should be a terminator at the end of each bus. ...
    (uk.rec.models.rail)