lcd4linux-users — lcd4linux users

[lcd4linux] Re: CrystalFontz drivers

[Michael R. <re...@eu...>]

Hi Ben,

Ben Schwemlein wrote:
> Hello, Do you have any plans to write Linux drivers for the new
> CrystalFontz  631 display?   Or do you have any suggestions or advice
> on making existing drivers work?

Drivers for all Crystalfontz Displays (including the cool 631) already 
exist in CVS (where the 631 isn't finished, but only a few steps away). 
This code will be released as lcd4linux-0.10 in a few weeks.

You are welcome to beta- (alpha-?) test the new drivers from CVS! Just 
follow the guids on the lcd4linux download page; if you need assistance, 
just let me know!


bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

[lcd4linux] m50530 Display

[<di...@ti...>]

Hello i have a little Problem with my Display ! It will not work :-)
Can anybody help me in German please ? *gg* my english is still bad !

Thanks 

Marco

__________________________________________________________________
Turbospeed zum Turbopreis! Surfen Sie doch auch mit der DSL-Flatrate
von Tiscali. Nur 15,90 EUR im Monat.
Tiscali DSL basiert auf dem T-DSL-Anschluss der Deutschen Telekom AG,
durch den weitere Kosten entstehen. Dieser ist in vielen
Anschlussgebieten verf=FCgbar. 6 Monate Mindestvertragslaufzeit.
Und falls Sie wider Erwarten im ersten Monat nicht zufrieden sein sollten=
,
gew=E4hrt Tiscali Ihnen ein sofortiges K=FCndigungsrecht und Sie erhalten=

Ihr Geld zur=FCck.

Klicken Sie hier:
http://registrierung.tiscali.de/produkte/1342_dslflatrate.php?akkcode=3D1=
0253

Re: The Finally Reply?: [lcd4linux] can you please make a lcd4linux conf?

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

Koma wrote:
> On Tue, 24 Feb 2004 20:40:22 +0100
> Martin Hejl <ma...@he...> Ha Scritto:
> 
> [~] Hi everybody,
> [~] 
> [~] (sorry Michael, I hit "reply" instead of "reply all" by mistake).
> [~] 
> [~]  >> # cat /etc/lcd4linux.conf Display "HD44780"
> [~]  >> Port "0x378"
> [~]  >> Size "16x2"
> [~]  >> Bits "4"
> [~]  >>     Wire.RW "GND"
> [~]  >>     Wire.RS "AUTOFD"
> [~]  >>     Wire.ENABLE "STROBE"
> [~]  >>     Wire.ENABLE2 "SELECT"
> [~]  >>     Wire.GPO "INIT"
> [~]  >> row1:"hello"
> [~]  >
> [~]  >
> [~]  > looks fine, too.
> [~] Maybe I'm too old to read the fine-print on the image - but what I _can_ 
> [~] read at http://www.camscode.org/images/lcd/th_schaltplan.jpg doesn't 
> [~] look like 4-Bit mode to me.
> [~] 
> [~] Does setting it to 'Bits "8"' help?
> [~] 
> [~] Just a thought
> [~] 
> [~] Martin
> [~] 
> [~] 
> -Snip-
> 
> Hi i know the italian is the most difficult language to understand :)
The language actually wasn't the problem - more the fact that the image 
was so small that it was very hard to read.

> I attach to you the images and the pin set.
> And the PDF with the data sheet :)
> 
> Connecting LCD pins to Parallel port pins and power.
> 
> 
> 1 Earth (Black wire on Molex connector) Earth
> 2 +5V (Red wire on Molex connector)     Power
> 3 Earth (Black wire on Molex connector)
> 4 Parallel Port pin 16 (Green/white wire) Register Select
> 5 Earth (Black wire on Molex connector)
> 
> 
> In the schemas:
> 
> Italian			English
> Porta Parallela		Parallel Port
> Alimentazione		+5 (alimentation power)
> LCD			You know :D
> 
> Html doc to see the pin usage :) (ciao.html)
> 
> Very very very onorated for your help :D
Ok, looking at the schematic you sent, your config looks way off. It if 
you wired it like on the schematics (and if I didn't screw up reading 
the schematics), it should look like this:

Port "0x378"
Size "16x2"
Bits "8"
Wire.RW "AUTOFD"
Wire.RS "INIT"
Wire.ENABLE "STROBE"
Wire.ENABLE2 "GND"
Wire.GPO "GND"

I hope that helps

Martin

[lcd4linux] Re: 4th email =)

[Michael R. <re...@eu...>]

Hi Xavier,

could we please transfer this to the list? Maybe other users are 
interested in you experiences, too...


Xavier LaRue schrieb:
> The problem of the CVS version is a BIG memory leak..
> start it an look your ram fill up..
One? Only one? :-)

The current CVS code is very much "Work in Progress". You're welcome to 
configure it with "--with-dmalloc" and debug it a bit. My priority at 
the moment is to finish code for the next release. Finding and fixing 
bugs comes afterwards...

> I can't Get the bug I was getting in the stable version into the CVS version..
> Kinda Bezare.. but I get another bug.. on my box it take around 5 to 20 % only 
> to drive it.. Is that normal ??

No, it isn't. OTOH, Martin Hejl has similar problems. Maybe caused by 
the memory leak?

> BTW it is very cool.. but a little TOO much cpu intensive =))
It should not. I'm shure we can fix it.

> After some try, I discover that the problem must reside into this box,
> Since I retry it on my DPIII 550 and he don't have any bugs.. This must
> be from this box. I take out my multimeter and try out to mesure the voltage
> out the paralele port.. I looks like 5V but I can't be sure.. could you tell 
> me what pin should I should test of the parport ??
Not that easy... the port shouldn't be in use (no lcd4linux running), 
but it still depends wether the lines are high or low at the moment. 
Normally, you can find at least one line being high, and all other lines 
use the same high level. So if you find a line at +5V, you have a "good" 
parport.

> Also, can the fact that I use
> rawport ( parport.c: using raw port 0x378 ) be a problem ?? I found out ( like 2 min ago )
> That the Enable Signal Rise Time is VERY VERY VERY VERY ( CF: The LcdProc Manual.. ) Critial..
Never heard of that...

> After some thinking I shorten my cable ( only for testing and I get less glitche ).. So It
> probably a unsolvable problem... I can't shorten my cable more because My lcd is out of my 
> box ( on my desk )... Is there a way to short a Rise time ?? ( I don't think so but I'm still
> asking )... ?
No, I'm afraid there's no way to control the rise time. But I don't 
think this is a problem. I, too, use quite long (2m) cables, and nevcer 
had such problems.

bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [lcd4linux] can you please make a lcd4linux conf?

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

Hi everybody,

(sorry Michael, I hit "reply" instead of "reply all" by mistake).

 >> # cat /etc/lcd4linux.conf Display "HD44780"
 >> Port "0x378"
 >> Size "16x2"
 >> Bits "4"
 >>     Wire.RW "GND"
 >>     Wire.RS "AUTOFD"
 >>     Wire.ENABLE "STROBE"
 >>     Wire.ENABLE2 "SELECT"
 >>     Wire.GPO "INIT"
 >> row1:"hello"
 >
 >
 > looks fine, too.
Maybe I'm too old to read the fine-print on the image - but what I _can_ 
read at http://www.camscode.org/images/lcd/th_schaltplan.jpg doesn't 
look like 4-Bit mode to me.

Does setting it to 'Bits "8"' help?

Just a thought

Martin

Re: [lcd4linux] can you please make a lcd4linux conf?

[Michael R. <re...@eu...>]

Hi Koma,


>  # lcd4linux -Fvv
> Version 0.9.10 starting
> lcd4linux.c: initializing driver HD44780
> wiring: [PARPORT:GND]==>[DISPLAY:RW]
> wiring: [PARPORT:AUTOFD]==>[DISPLAY:RS]
> wiring: [PARPORT:STROBE]==>[DISPLAY:ENABLE]
> wiring: [PARPORT:INIT]==>[DISPLAY:GPO]
> udelay.c: CPU supports Time Stamp Counter
> udelay.c: CPU runs at 1980.714000 MHz
> udelay.c: using TSC delay loop, 1981 ticks per microsecond
> parport.c: using raw port 0x378
> processor.c: Display: 2 rows, 16 columns, 5x8 pixels, 0 GPOs
> processor.c: Row1: *** %o %v ***
> processor.c: Row2: %p CPU  %r MB RAM
> lcd4linux.c: starting main loop
> system.c: uname(sysname)=Linux
> system.c: uname(release)=2.6.3-rc2-gentoo
> system.c: uname(machine)=i686
> system.c: sizeof(/proc/kcore)=268374016 bytes
> lcd4linux.c: got signal 2
> lcd4linux.c: leaving main loop
> HD44780: shutting down.
> parport.c: closing raw port 0x378

look ok to me.

> And my conf (is destroyed i know :) but i've done many experiments)
> 
> # cat /etc/lcd4linux.conf 
> Display "HD44780"
> Port "0x378"
> Size "16x2"
> Bits "4"
>     Wire.RW "GND"
>     Wire.RS "AUTOFD"
>     Wire.ENABLE "STROBE"
>     Wire.ENABLE2 "SELECT"
>     Wire.GPO "INIT"
> row1:"hello"

looks fine, too.


Maybe there's a wiring fault, but the picture quality of your schematics 
is too bad:

>>> http://www.camscode.org/images/lcd/th_schaltplan.jpg

I can't read the pin names. Have you got a better image?

> Now i'm tring LCDd but, your program is more configurable and so COOL 
> I like lcd4linux :D

Thanks!


bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [lcd4linux] can you please make a lcd4linux conf?

[Michael R. <re...@eu...>]

Hi Koma,

> Hi i've tried for 4 days to make a .conf file  but the only results i've have its a strange symbol repetute..  
> I put here the wire configuration and the modl of dysplay:
> 
> Display "HD44780"
> Port "/dev/lp0"
> Size "16x2
> http://www.camscode.org/images/lcd/th_schaltplan.jpg

/dev/lp0 is wrong. Either use /dev/parport0 (or dev/parports/0 with 
devfs) or the hex port adress (e.g. 0x378)

If it still doesn't wortk, I need the whole lcd4linux.conf and the 
output of 'lcd4linux -Fvv'

bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

[lcd4linux] can you please make a lcd4linux conf?

[Koma <ko...@em...>]

Hi i've tried for 4 days to make a .conf file  but the only results i've ha=
ve its a strange symbol repetute.. =20
I put here the wire configuration and the modl of dysplay:

Display "HD44780"
Port "/dev/lp0"
Size "16x2
http://www.camscode.org/images/lcd/th_schaltplan.jpg

if you can reply to me at kom4[=E6]email.it

Pleased
Thx :)

[lcd4linux] Re: LCD4Linux Bug... or a Computter bug =))

[Michael R. <re...@eu...>]

Hi Xavier,

> I was using my 20x4 HD44780 On my Dual Pentium 3 with LCDProc..
> I never seen a glitche in the screen... But I transfered to my 
> Pentium II 233 Mhz and now in lcdproc I get glitched character
> all the time.. In your prog that sligly less frequent.. I only get
> them if I overuse the cpu...
> 
> I don't know if you see where is the bug ( my first tough was that
> my box lock down sometime ant the update of the lcd is'nt done at the
> right time.. )

I've never seen such an error because of a slow CPU. All the timing 
stuff are "minimal" timings, so it should not matter wether it takes 
longer...

B ut there may be another issue: Most of the parallel port display use 
+5V for logical "high", some parallel port deliver only 3.3V. This may 
lead to misinterpretation and glitches. I've had this with T6963, and 
developed a circuit which does level shifting (quite complicated, 
because the T6963 needs to read from the parallel port, too)

Do you own a multimeter? Can you check wether the old and the new 
parport deliver 3.3 or 5V?


bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [lcd4linux] Re: Everbouquet 44780 modules

[Michael R. <re...@eu...>]

Hi Aragon,

>>I see there are three chips on your display. Two of them are HD44780. 
>>What's the third? How can you be shure that the middle one, where your 
>>R11 is connected to, is a HD44780, and not something completely 
>>different? (Maybe something like a LCD column driver?)

> I'm not sure what any of the blobs are, but all the I/O tracks lead into
> the left most blob.  If I were to destroy my module I could remove the LCD
> from the board and trace the tracks on the other side, but I'm not sure I'm
> keen to do that.  It probably won't help, and if it did, probably won't be
> worth it.

This is not a big problem - i have done this several times: Just move 
the clamps which hold the metal frame. On the other side you will find 
the display glass and two stripes of conducting rubber.

The only important thing when reassembling is to find the correct 
position. Try it out before fixing the clamps :-)


bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

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!

Re: [lcd4linux] Re: Everbouquet 44780 modules

[Aragon G. <ar...@ph...>]

Howdy

| By Michael Reinelt <re...@eu...>
|                                          [ 2004-02-16 21:15 +0200 ]
> >A high quality photo of my module's controller board is available at:
> >http://decoder.geek.sh/misc/mc2004E.jpg
> Hey! This is really high quality! How did you do this?

Canon Powershot S330 :)


> I see there are three chips on your display. Two of them are HD44780. 
> What's the third? How can you be shure that the middle one, where your 
> R11 is connected to, is a HD44780, and not something completely 
> different? (Maybe something like a LCD column driver?)

I'm not sure what any of the blobs are, but all the I/O tracks lead into
the left most blob.  If I were to destroy my module I could remove the LCD
from the board and trace the tracks on the other side, but I'm not sure I'm
keen to do that.  It probably won't help, and if it did, probably won't be
worth it.

I guess my only hope is to try get an answer out of the manufacturer.  I'm
considering making a distance call to them.  Emailing them has brought no
useful response so far.

Thanks for looking :)


Regards,
Aragon

Re: [lcd4linux] Re: Everbouquet 44780 modules

[Michael R. <re...@eu...>]

Hi Aragon,

> A high quality photo of my module's controller board is available at:
> http://decoder.geek.sh/misc/mc2004E.jpg
Hey! This is really high quality! How did you do this?

> The leftmost pad of Q1 leads through R11 and then into one of the 44780
> chips.  This must be the base.  Voltage between that line and ground is
> about 2.5V after 44780 initialisation.

Hmm... finding out which pin this is connected to will be impossible, 
because of these 'blobs'. Maybe you can figure out two neighbour pins, 
which lead to the external connector, and where you know the meaning.

I see there are three chips on your display. Two of them are HD44780. 
What's the third? How can you be shure that the middle one, where your 
R11 is connected to, is a HD44780, and not something completely 
different? (Maybe something like a LCD column driver?)


bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [lcd4linux] GPO circuitry

[Michael R. <re...@eu...>]

Hi Martin,


>> 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?

> 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 :-( That's why I spent the last months soldering a 
power supply with current limiting. No more buning chips....
It's a quite cool device - a step-down regulator (switching power 
supply) that delivers from 0 to 14 V, 0-6 ampere, and can be supplied by 
a car battery (i.e. it needs only +12V-+14V). Especially the absence of 
a symmetric supply voltage made things quite complex. (I need this for 
my model aircrafts, because you don't have 220V out there in the fields).

Oh... this is getting a bit off-topic :-)


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


-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [lcd4linux] Re: Everbouquet 44780 modules

[Aragon G. <ar...@ph...>]

A high quality photo of my module's controller board is available at:

http://decoder.geek.sh/misc/mc2004E.jpg

The interesting component pads are:

R11
Q1
R9
R10

The leftmost pad of Q1 leads through R11 and then into one of the 44780
chips.  This must be the base.  Voltage between that line and ground is
about 2.5V after 44780 initialisation.

The topmost pad of Q1 connects to pin15 on the connector (LED+).

The rightmost pad of Q1 connects to the LED Anode via R9/R10.

The jumper on R7 would need to be desoldered before attaching this extra
circuitry.  If R7 is left in place, the backlight will come on and stay on
whenever power is applied to LED+.

With the extra circuitry in place and R7 removed, the backlight will only
come on when Q1's output is HIGH, and LED+ has power.

Now the question is.. how do you tell the 44780 to set Q1 high!?

So far I've tried sending this data in instruction mode (RS low):

  1xx11
  1xx01
  1xx10

and:

  1xxx11

  x = appropriate value for my interface/cursor settings


No luck.  Voltage at R11 stays 2.5V.

Any ideas? :)


Regards,
Aragon


| By Aragon Gouveia <ar...@ph...>
|                                          [ 2004-02-16 10:29 +0200 ]
> I'll try take a photo of it tonight.
> 
> I can trace the track going into one of the silicon chips embedded on the
> controller board, but that's it.  It also jumps through to the otherside of
> the board, but can't trace it there (without breaking my module).
> 
> Before I went to bed last night I checked the voltage between the base pad
> and ground - ~2.7V before 44780 initialisation, ~2.5V after initialisation.
> 
> I'm going to hack up someone's source code tonight hopefully and see what
> happens if I play with the two "unused" bits (D1 and D0) of the Set
> Interface Length and Move Cursor commands. ;)

Re: [lcd4linux] GPO circuitry

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

Hi Michael,

Michael Reinelt wrote:
>>> Is the LED's brightness proportional to the current?  Not sure
>>> myself...
>> No, it isn't - at least not on the displays I have here.
> Oh, I think it is. It has to be. Brightness is proportional to power. 
> Power is proportional to the current.
> 
> Maybe you meant that it's not linear - that may be true.
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).

The other display I have is from Crystalfontz, and that one is the one
with the two levels of brightness - and this one 'jumps' from off to the
first brighness level to the second brightness level as the resistance
is lowered. Maybe it's just these two displays, and others work more
like you would expect.

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)

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

Martin

Re: [lcd4linux] Re: Everbouquet 44780 modules

[Aragon G. <ar...@ph...>]

| By Aragon Gouveia <ar...@ph...>
|                                          [ 2004-02-16 10:29 +0200 ]
> > >The reason I'm asking is because I have one, and I can't help but notice
> > >some of the unused circuitry on it.  There are pads for a transistor and a
> > >bunch of resistors which looks unmistakebly like a switching circuit
> > >attached to the LED backlight Anode.  The base of the transistor pads leads
> > >through a resistor pad into one of the controller chips.
> > >
> > >I'm thinking that perhaps these modules have an undocumented 44780 command
> > >to toggle the backlight on and off, maybe even to adjust its intensity 
> > >too. I've tried mailing them asking this, but so far no luck with useful 
> > >replies. 

Whoops, I cut off the first part without thinking.

This is in reference to 44780 modules manufactured by Everbouquet/Wayton. 
Their part numbers resemble MC1602, MC2002, MC2004, MC4004, etc.  If you
have one, read above. :)


Regards,
Aragon

[lcd4linux] Re: Everbouquet 44780 modules

[Aragon G. <ar...@ph...>]

| By Michael Reinelt <re...@eu...>
|                                          [ 2004-02-16 10:10 +0200 ]
> try to post such questions to the list!

Okay ;)


> >The reason I'm asking is because I have one, and I can't help but notice
> >some of the unused circuitry on it.  There are pads for a transistor and a
> >bunch of resistors which looks unmistakebly like a switching circuit
> >attached to the LED backlight Anode.  The base of the transistor pads leads
> >through a resistor pad into one of the controller chips.
> >
> >I'm thinking that perhaps these modules have an undocumented 44780 command
> >to toggle the backlight on and off, maybe even to adjust its intensity 
> >too. I've tried mailing them asking this, but so far no luck with useful 
> >replies. 
> 
> Can you tell what controller pin is connected to this transistor? I 
> could search through my various datasheets to find an answer...

I'll try take a photo of it tonight.

I can trace the track going into one of the silicon chips embedded on the
controller board, but that's it.  It also jumps through to the otherside of
the board, but can't trace it there (without breaking my module).

Before I went to bed last night I checked the voltage between the base pad
and ground - ~2.7V before 44780 initialisation, ~2.5V after initialisation.

I'm going to hack up someone's source code tonight hopefully and see what
happens if I play with the two "unused" bits (D1 and D0) of the Set
Interface Length and Move Cursor commands. ;)


Regards,
Aragon

[lcd4linux] Re: Everbouquet 44780 modules

[Michael R. <re...@eu...>]

Hi Aragon,

try to post such questions to the list!

> On a completely different thread, I was wondering if any of your 44780
> modules you had were made by Everbouquet/Wayton?  Their part numbers
> resemble MC1608, MC2004, MC4002, MC4004, etc.

No, I'm afraid I have none of such a kind.

> The reason I'm asking is because I have one, and I can't help but notice
> some of the unused circuitry on it.  There are pads for a transistor and a
> bunch of resistors which looks unmistakebly like a switching circuit
> attached to the LED backlight Anode.  The base of the transistor pads leads
> through a resistor pad into one of the controller chips.
> 
> I'm thinking that perhaps these modules have an undocumented 44780 command
> to toggle the backlight on and off, maybe even to adjust its intensity too. 
> I've tried mailing them asking this, but so far no luck with useful replies. 

Can you tell what controller pin is connected to this transistor? I 
could search through my various datasheets to find an answer...


bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [lcd4linux] GPO circuitry

[Michael R. <re...@eu...>]

Hi Martin,


>> Is the LED's brightness proportional to the current?  Not sure
>> myself...
> 
> No, it isn't - at least not on the displays I have here.

Oh, I think it is. It has to be. Brightness is proportional to power. 
Power is proportional to the current.

Maybe you meant that it's not linear - that may be true.


btw, Martin, I'd be very interested in your opinion regarding the 
'dynamic loading of plugins'.

bye, Michael

-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [lcd4linux] GPO circuitry

[Aragon G. <ar...@ph...>]

| By Martin Hejl <ma...@he...>
|                                          [ 2004-02-16 01:59 +0200 ]
> No, it isn't - at least not on the displays I have here. One kind seems 
> to have two "brightnesses" (low and _pretty_ high, to the point where I 
> think that "pretty high" may burn out the display soon - since it gets 
> somewhat warm) and the other kind simply has "on" if no resistor is 
> attached between pins 15 and 16 (I never attached anything to A and K 
> directly) and "off" if there's a resistor > 10 Ohm. Found this out 
> simply by attaching a pot to pins 15 and 16 and seeing what happens when 
> I turn the knob.

I think others with different modules will probably have different
experiences too, to make matters more difficult. :)


> But there are different kinds of backlights (electro luminescent, cold 
> cathode flourescent lamps and light emitting diode - and the LED type 
> might be implemented as a "Lightbox" or as a "Light-Pipe", or so I 
> gather from the various specs) and each will probably behave 
> differently. So, I guess you'll have to try to be sure.

EL and CCFL backlights I'm sure are very different from LED when it comes to
adjusting light intensity level.  I have experience only with LED
backlights.  Can anyone using EL and/or CCFL comment on the process of
adjusting brightness?

I'm leaning toward my design idea with a 4514 based decoder because it'll
allow the most flexibilty in choosing resistance values precisely for each
desired brightness level.  (at the cost of having to wire lots of resistors)


Regards,
Aragon

Re: [lcd4linux] GPO circuitry

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

Hi,
sorry for jumping in late into the discussion - but up until now, I 
didn't have much to add.

> Is the LED's brightness proportional to the current?  Not sure
> myself...
No, it isn't - at least not on the displays I have here. One kind seems 
to have two "brightnesses" (low and _pretty_ high, to the point where I 
think that "pretty high" may burn out the display soon - since it gets 
somewhat warm) and the other kind simply has "on" if no resistor is 
attached between pins 15 and 16 (I never attached anything to A and K 
directly) and "off" if there's a resistor > 10 Ohm. Found this out 
simply by attaching a pot to pins 15 and 16 and seeing what happens when 
I turn the knob.

But there are different kinds of backlights (electro luminescent, cold 
cathode flourescent lamps and light emitting diode - and the LED type 
might be implemented as a "Lightbox" or as a "Light-Pipe", or so I 
gather from the various specs) and each will probably behave 
differently. So, I guess you'll have to try to be sure.

Just my two cents

Martin

Re: [lcd4linux] GPO circuitry

[Aragon G. <ar...@ph...>]

Okay I understand now. :)

Your method makes sense.  I like it. :)

My method will require much more resistors, but it might afford me greater
flexibility in the brightness curve.  I'm saying this without having done
any testing on combining and removing resistors in parallel in an LED
circuit.  Is the LED's brightness proportional to the current?  Not sure
myself...

Whatever method one chooses to wire up, the programming in lcd4linux will
stay the same. (I think?)

Ideally it'd be nice to configure software to tell it what range of bits to
use for backlight brightness.  And then to also allow other bits to be
configured for additional toggles. (panel LEDs, relays, etc. would be cool!)


Regards,
Aragon


| By Michael Reinelt <re...@eu...>
|                                          [ 2004-02-15 20:22 +0200 ]
> Hi Aragon,
> 
> >>Every resistor can be switched on and off with a transistor, and every 
> >>resistor allows a specific current. If you choose the resistors in a way 
> >>like a "binary system", so that the current will be 10, 20 and 40 mA, 
> >>you can control the current from 0 to 90 mA in steps of 10 mA.
> >
> >How will you select each resistor?
> 
> Trial & Error? :-)
> 
> You have 5 V voltage. a typical LED needs about 1 V (hou have to find 
> out yourself. Maybe the backlight has already current limiting resistors 
> built in. I'm pretty shure they have, because otherwise you'd not be 
> able to connect it directly to +5V).
> 
> Maybe it's better to go for it the other way round: just measure the 
> current for backlight when connected to +5V and thus running at 100%. 
> Say this current would be 100mA (just a guess! I really don't know!)
> 
> This means the backlight has an equivalent resistance of
> 5V / 100mA = 50Ohm
> 
> To limit the current to 50 mA (which may give about half the intensity) 
> another resistor of 50 Ohm would be necessary.
> 
> use this 50 Ohm as the "middle resistor", and choose 25 and 100 Ohm for 
> the other resistors.
> 
> so you would have the maximum resistance (except from infinity where all 
> transistors are switched off) of 100 Ohm (only the transistor connected 
> to 100Ohm switched on) and a minimum resistance of about 14 Ohm (all 
> transistors switched on, therefore all three resistors 25, 50 and 100 in 
> parallel)
> 
> 
> >>I'm not shure, but what I've read is that the CD4514 is a demultiplexer. 
> >>This means that it has 16 outputs, but only one can be active at a time! 
> >>Are you shure that this is what you want?
> >
> >Pretty sure.  For the backlight trick, each of the 16 outputs is connected
> >to a resistor of different value (after going through a diode to prevent
> >pull-down).  The output of each resistor is connected to the base of a
> >transistor (I'm thinking 2N2222).  The output that is switched on will
> >determine which resistor power flows through onto the transistor's base
> >(thus providing a variable current level at the transistor's collector 
> >where
> >the load (LED) will be connected).
> 
> Well, thats quite similar to the scheme I'm talking about, with two 
> differences:
> 
> a) I'm saving some resistors and the demultiplexer by binary combining 
> some values (in my case, more than one transistor could be switched on 
> at a time!)
> 
> b) I'm controlling the current "after" the transistor. Shure, I need 
> three of them, where you need only one, but with my schematics the 
> current (and therefore the intensity) depends only on the resistor (and 
> can be easily adopted), where you have to take the transistor and all 
> this current-amplification stuff into account. Shure, it's possible. But 
>   I did calculate such transistor schematics about 15 years ago :-)
> 

Re: [lcd4linux] GPO circuitry

[Michael R. <re...@eu...>]

Hi Aragon,

>>Every resistor can be switched on and off with a transistor, and every 
>>resistor allows a specific current. If you choose the resistors in a way 
>>like a "binary system", so that the current will be 10, 20 and 40 mA, 
>>you can control the current from 0 to 90 mA in steps of 10 mA.
> 
> How will you select each resistor?

Trial & Error? :-)

You have 5 V voltage. a typical LED needs about 1 V (hou have to find 
out yourself. Maybe the backlight has already current limiting resistors 
built in. I'm pretty shure they have, because otherwise you'd not be 
able to connect it directly to +5V).

Maybe it's better to go for it the other way round: just measure the 
current for backlight when connected to +5V and thus running at 100%. 
Say this current would be 100mA (just a guess! I really don't know!)

This means the backlight has an equivalent resistance of
5V / 100mA = 50Ohm

To limit the current to 50 mA (which may give about half the intensity) 
another resistor of 50 Ohm would be necessary.

use this 50 Ohm as the "middle resistor", and choose 25 and 100 Ohm for 
the other resistors.

so you would have the maximum resistance (except from infinity where all 
transistors are switched off) of 100 Ohm (only the transistor connected 
to 100Ohm switched on) and a minimum resistance of about 14 Ohm (all 
transistors switched on, therefore all three resistors 25, 50 and 100 in 
parallel)


>>I'm not shure, but what I've read is that the CD4514 is a demultiplexer. 
>>This means that it has 16 outputs, but only one can be active at a time! 
>>Are you shure that this is what you want?
> 
> Pretty sure.  For the backlight trick, each of the 16 outputs is connected
> to a resistor of different value (after going through a diode to prevent
> pull-down).  The output of each resistor is connected to the base of a
> transistor (I'm thinking 2N2222).  The output that is switched on will
> determine which resistor power flows through onto the transistor's base
> (thus providing a variable current level at the transistor's collector where
> the load (LED) will be connected).

Well, thats quite similar to the scheme I'm talking about, with two 
differences:

a) I'm saving some resistors and the demultiplexer by binary combining 
some values (in my case, more than one transistor could be switched on 
at a time!)

b) I'm controlling the current "after" the transistor. Shure, I need 
three of them, where you need only one, but with my schematics the 
current (and therefore the intensity) depends only on the resistor (and 
can be easily adopted), where you have to take the transistor and all 
this current-amplification stuff into account. Shure, it's possible. But 
   I did calculate such transistor schematics about 15 years ago :-)



-- 
Michael Reinelt                                   Tel: +43 676 3079941
Geisslergasse 4                                   Fax: +43 316  692343
A-8045 Graz, Austria                          e-mail: re...@eu...

Re: [lcd4linux] GPO circuitry

[Aragon G. <ar...@ph...>]

| By Michael Reinelt <re...@eu...>
|                                          [ 2004-02-15 20:02 +0200 ]
> Hmmm.... sneding data to both displays is used for icon definitions. 
> This sequence is 9 bytes long, and can happen really often...
> 
> But I don't see the problem: You can use 4 control lines from the 
> parallel port (AUTOFD, INIT, SELECT and STROBE). The dual-HD44780 needs 
> at least three (RS, SELECT#1, SELECT#2), because you can hardwire RW to 
> GND. so you have a free line to control the latch individually...

Yea I see your point.  I guess I'll have to sacrifice the RW control.  Cool.


Thanks,
Aragon