LCDproc development and user support list

Text archives Help

[Lcdproc] Re: nSEL (EN2) state inverted (proposal for Soft-wiring)

Chronological Thread 
  • From: lucianm AT (Lucian Muresan)
  • Subject: [Lcdproc] Re: nSEL (EN2) state inverted (proposal for Soft-wiring)
  • Date: Wed Mar 23 10:15:02 2005


MALNATI Antoine wrote:
> Hi everyone!
> I've just bought a 40x4 LCD from crystalfontz. I've connected it with
> the "Winamp" wiring scheme... The 2 first lines work, but the 2 next
> don't. I checked the wiring with CrystalFontz Windows debugging program,
> and it appeared that EN2's state (2 screen enable) is inverted (high
> when asked low, low when asked high)!!
> I am using a Compaq Armada M700 Laptop, the problem might come from my
> computer. I will probably solve this problem by inserting an inverter
> gate (74HCT00)...
> I've noticed in a previous post that people using EN2 for controlling
> the backlight also noticed a inverted state (backlight off when asked
> on)
> Is there a way of inverting the EN2 state directly with lcdproc (by
> recompiling...)?
> Thanks!!

This would be easy after few changes to LCDproc even without recompiling
(of course, after someone has done these changes :-) ), if a sort of
soft-wiring would be implemented. This would of cours grow the number of
keys to be set maybe in each driver section of /etc/LCDd.conf, but would
allow the user to configure his own wiring (even with inversions on
specific lines) without having to modify the source code.
I did some preliminary work for this sort of thing (not a really
flexible soft-wiring, but supporting just 2 wirings for now) in the
noritake800 driver of the graphlcd-base library.

The idea is to map the low control bits of the LPT defined in
/lcdproc/server/drivers/lpt-port.h (the LPT control bits "space")to the
actual display's control ports (the device's control ports "space")
dynamically, with a function which computes the mapping for any of the
16 possible words, at initialization and stores those mapped words for
later usage in an array of 16 unsigned chars. Every time a control word
has to be written to the device's control port, this word is actually
used as an index in the mapping array and actually the mapped word is
written to the LPT control port, just suitable for the configured
wiring. That way, the rest of the code is independent of the actual LPT
control port lines (it only uses the "device's control ports space", and
the mapping is done only once at initialization and very flexible, the
actual writing to the control ports just involves accessing an array of
unsigned chars.

Of course, inversions of specific lines like this nSEL (EN2) mentioned
here can also be handled this way, as a configuration option.

Maybe there already have been discussions on this thematic on the ML,
but I don't know if something has been done in this area. What do you
core developers think of it? I might try to provide some code, but we
should conclude how to do it the best way in respect to re-usability in
all of the LPT-driven drivers, and a clean way to read the configuration
from LCDd.conf.


Archive powered by MHonArc 2.6.18.

Top of page