Re: [lcd4linux] GPO circuitry

[Martin H. <ma...@he...>]

Hi Michael,

(I guess it's getting time we move this to the devel-list...)

>>> Oh, I think it is. It has to be. Brightness is proportional to 
>>> power. Power is proportional to the current.
>> Well, at least on the one display (manufactured by 
>> display-electronic) it's all but proportional (let alone linear). 
>> It's either on (at a constant brightness) or off (that is, using 5V 
>> as defined in the specs).
> Strange. I can't imagine how this should work. Maybe there's some 
> additional components on the display - something like a current sink?
Could well be, but I don't see anything. No "real" components (apart 
from a few smd resistors)  at the back of the display (and the front is 
covered by the display itself).

>> Oh, and no, the power supply used for this has plenty of Amps to 
>> spare (the backlight uses around 150mA at 5V, and the power supply is
>> rated at 5V/1.25A)
> Oh! I'd never spend so much current to my displays (I destroyed three 
> of them in the meantime :-(
I know the feeling - did that the other day too (by soldering the cable 
on from the wrong side, which unfortunately switched Vlcd and GND, which 
of course killed the display, just like everybody said it would...).

The only reason why I don't use anything with less power is that it's 
the only one I have which gives stable 5V.

>>> btw, Martin, I'd be very interested in your opinion regarding the 
>>> 'dynamic loading of plugins'.
>> I haven't forgotten about that - I have it on my todo-list. But in 
>> order to give you a meaningful response, I'll need to research a bit,
>> if my thoughts on that topic are actually correct (all of my 
>> experience with writing plugins and such are from Windows - not much 
>> use for lcd4linux).
> Well, I'm not expecting too deep experience - just your comments on my
> and Xavier's arguments....
>  
> OTOH, I'm planning to think about this stuff when the NextGeneration 
> has settled down a bit, and at least a 0.9.12 is released.
Sounds like a good idea - get it released, so it will receive some 
broader testing, before introductin even more new code.

Talking about testing - I'm having a problem with the current version 
from CVS - I'm running configure with:

--prefix=/usr/ \
--without-sco \
--without-sunos-curses \
--without-osf1-curses \
--without-vcurses \
--without-ncurses \
--disable-dependency-tracking \
--with-x=no \
--disable-shared \
--disable-static \ 
--with-drivers=BeckmannEgle,CrystalFontz,Cwlinux,HD44780,M50530,T6963,USBLCD,MatrixOrbital

But for some reason, it still tries to link against libcurses (which it 
doesn't find on my build system, so the build fails).

If I change configure.in
if test "$TEXT" = "yes"; then
    if test "$has_curses" = true; then
#     DRIVERS="$DRIVERS Text.lo"
#     DRIVERS="$DRIVERS Text.o"
       DRVLIBS="$DRVLIBS $CURSES_LIBS"
       CPPFLAGS="$CPPFLAGS $CURSES_INCLUDES"
       AC_DEFINE(WITH_TEXT,1,[Curses driver])
    else
       AC_MSG_WARN(curses not found: Text driver disabled)
    fi
fi

and comment out the line "DRVLIBS="$DRVLIBS $CURSES_LIBS", everything 
works fine.

Any idea? Sorry that automake stuff is also on my list of things to 
learn (but unfortunately, I haven't even started working with that yet).

Martin

-- 
You think that's tough?  Try herding cats!