lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] [patch] adds keypad support for Crystalfontz 635

[C. M. <cm...@fr...>]

On Tue, Feb 21, 2006 at 10:51:29PM +0100, Till Harbaum waxed:
> H
> 
> On Tuesday 21 February 2006 07:10, Michael Reinelt wrote:
> > I already committed your patch to CVS. I cannot test it at the moment,
> > because I'd have to dig out a display with keys...
> You'll soon get one in the mail ... i have just added keypad support to the
> LCD2USB driver.
> 
> But i have a very stupid question: What is this good for? Ok, i can increment
> and decrement values, but is there some useful real life example?

I think it could provide for much more interactive displays
like changing layouts, offering confirmation dialogs, menus,
reboot, etc.  Potentially helpful stuff for rackmount machines.

Right now I'm making use of it with the file plugin to
scroll thru dmesg output:

Widget dmesg1 {
    class 'Text'
    expression file::readline('/var/log/dmesg',currline)
    width 20
    update 250
}

Widget keydown {
    class 'Keypad'
    position 'down'
    state 'pressed'
    expression currline = currline+1
}

> Two more things i notices:
> - i accidentally put the "Keypad1 'keyup'" line in the display part inside my
>  Row1 statement. This didn't work, but i didn't get a warning or error 

I guess I didn't realize that, but it seems to work the same
with GPO lines, silently ignoring them as far as I can tell.

Maybe that should change, too ?

> - why does the driver use two stages? first feed some device dependant
>   data into the keypad driver and then have a callback that interprets this
>   into some keypad specific values? Why don't we just return values
>   the driver expects in the first place?

By forcing you to write a separate translation function, the
code stays cleaner, at least that was one of my thoughts
behind the two-stage setup.  Looking at it now, it's not
really necessary and perhaps is a bit confusing.  Although
it feels like the driver should have some sort of callback...

> - What is the purpose of the KEYPADSIZE value? (BTW: A coding style
>   question: Why are these variables upper case? Maybe they were constants
>   once, but upper case variables are quite confusing ...)

I was looking at DCOLS, DROWS, etc., from the generic text
widget, trying to follow that convention.  But KEYPADSIZE
itself is just left over cruft, and I'm taking it out now.

> Anyway: I love to see lcd4linux react on my buttons :-)

Super !

--Chris

Re: [Lcd4linux-devel] [patch] adds keypad support for Crystalfontz 635

[Till H. <ti...@ha...>]

Hi,

On Tuesday 21 February 2006 07:10, Michael Reinelt wrote:
> I already committed your patch to CVS. I cannot test it at the moment,
> because I'd have to dig out a display with keys...
You'll soon get one in the mail ... i have just added keypad support to the
LCD2USB driver.

But i have a very stupid question: What is this good for? Ok, i can increment
and decrement values, but is there some useful real life example?

Two more things i notices:
- i accidentally put the "Keypad1 'keyup'" line in the display part inside my
 Row1 statement. This didn't work, but i didn't get a warning or error 
- why does the driver use two stages? first feed some device dependant
  data into the keypad driver and then have a callback that interprets this
  into some keypad specific values? Why don't we just return values
  the driver expects in the first place?
- What is the purpose of the KEYPADSIZE value? (BTW: A coding style
  question: Why are these variables upper case? Maybe they were constants
  once, but upper case variables are quite confusing ...)

Anyway: I love to see lcd4linux react on my buttons :-)

Ciao,
  Till

-- 
Dr.Ing. Till Harbaum <ti...@ha...>
http://www.harbaum.org/till

Re: [Lcd4linux-devel] [patch] adds keypad support for Crystalfontz 635

[C. M. <cm...@fr...>]

On Tue, Feb 21, 2006 at 07:10:13AM +0100, Michael Reinelt waxed:
> But there is one thing I don't like that much: your extension of the
> widget structure, especially the two new function pointers 'update' and
> 'find'.
> 
> First, I'd say that a keypad widget never has a 'draw' function. So I'd
> suggest removing the update function and use w->draw instead.

I've pulled the 'update' in favor of 'draw', as per your
suggestion, and committed the changes to CVS.  I think this
is a good idea, but please let me know if the patch meets
your expectations.

> I'm not shure about the find call. I'd accept a generic 'widget_find()"
> function, but i'm unhappy with a widget specific find() callback,
> because it's very keypad-specific....

I agree, at the moment, find is very specific to keypads.

> maybe we can find a cleaner way to implement this....

The problem I ran into is that the widgets were designed to
be self-updating and standalone.  Once they startup, there
didn't seem to be a lot of ways to iterate over them and
find a specific one.  The timer kind of takes the widget
away until quit is called on it.

I looked at storing the index of the generic Widgets array
in the keypad widget itself and searching that, but it was
messy.  I think another alternative would be coming up with
some sort of new 'control'-like abstraction layer to sit
alongside the 'widget' layer.  That might be overkill, tho.

--Chris

Re: [Lcd4linux-devel] [patch] adds keypad support for Crystalfontz 635

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

Hi Chri,

> The attached patch adds a new keypad widget and a generic
> keypad driver.  The widget is unique because I believe it's
> the only one that doesn't update with a timer, instead, it
> uses, you guessed it, the key pad. :)  The generic driver
> is useful for mapping key scan codes from the hardware into
> normal positions UP, DOWN, LEFT, RIGHT, etc. so that if you
> swap hardware you won't need to re-write the configuration
> file that much.

Hey, that's great news! Finally LCD4Linux gets support for keys!

I already committed your patch to CVS. I cannot test it at the moment,
because I'd have to dig out a display with keys...

I'm really surprised how neat you did integrate things... registering
the widget in the generic driver init is the right thing, but it's not
self-evident.

Great Work!

But there is one thing I don't like that much: your extension of the
widget structure, especially the two new function pointers 'update' and
'find'.

First, I'd say that a keypad widget never has a 'draw' function. So I'd
suggest removing the update function and use w->draw instead.

I'm not shure about the find call. I'd accept a generic 'widget_find()"
function, but i'm unhappy with a widget specific find() callback,
because it's very keypad-specific....

maybe we can find a cleaner way to implement this....


by,e Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] [patch] adds keypad support for Crystalfontz 635

[C. M. <cm...@fr...>]

Howdy y'all--

I tried to make the keypad support as extensible as
possible, but I've only got a Crystalfontz 635 at the
moment.  It's built with 6 buttons, and they generate
different events for both press & release.

The attached patch adds a new keypad widget and a generic
keypad driver.  The widget is unique because I believe it's
the only one that doesn't update with a timer, instead, it
uses, you guessed it, the key pad. :)  The generic driver
is useful for mapping key scan codes from the hardware into
normal positions UP, DOWN, LEFT, RIGHT, etc. so that if you
swap hardware you won't need to re-write the configuration
file that much.

Here's what some of the configuration might look like:

Widget keyup {
    class 'Keypad'
    position 'up'
    state 'pressed'
    expression somevar = somevar-1
}

Widget keydown {
    class 'Keypad'
    position 'down'
    state 'pressed'
    expression somevar = somevar+1
}

Layout partial_example {
    Keypad1 'keyup'
    Keypad2 'keydown'
}

It would be great to get some feedback.  Particularly if
this is unworkable for other displays with buttons.

Thanks,
--Chris

[Lcd4linux-devel] CF635 patch, file plugin, Tickets

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

Hi there,

there are two patches from Chris Maj that I just commited to CVS: a fix
for CF635 GPO's, and a new plugin "file" which provides a long time
missing function "file::readline()" which returns the contents of a file.

I want to thank Chris for his contribution!

@Chris: interested in a developer account? (CVS write access)

@Chris again: willing to do some documentation in the wiki?

Unfortunately, Chris posted this patches as "Tickets" in the wiki, so
that I fond them "by accident" only.

I'd prefer to receive patches on one of the mailing lists, either
lcd4linux-users or lcd4linux-devel.

In fact, I'd prefer not to receive tickets at all :-( I'm sure the
ticket system Trac provides is very powerful, but I just don't like it...

I try to answer all mail posted to one of the mailing lists (I said I
*try* to :-) at least I read them all. But I seldom have a look at the
ticket system...

If you guys and gals out there have a different opinion, let me know.
Maybe the ticket system can be of a lot of help, and I just don't
understand it....


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] Re: [lcd4linux] driving a TC6963 via USB?

[Till H. <ti...@ha...>]

Hi,

On Sunday 12 February 2006 12:36, Michael Reinelt wrote:
> I have no idea, but I think there's not much of a difference. I' expect
> the CPU load to be lower with USB.
Exactly. USB can be quite fast, but most simple devices aren't. E.g. my 
display transfers at most 4 bytes per USB-Transfer. The USBLCD and WBCT
interface only transfer single Bytes. USB devices can transfer much more bytes 
per tansfer, but for my soft USB solution it would have increased the 
complexity and the current solution is just fast enough, so i had no reason 
to do more.

The current code is fast enough for the text LCDs and since the PC does most 
of the USB stuff in hardware there's nearly no load on the PC whereas the 
printer port solutions require plenty of io port accesses per byte and do 
some busy waiting in the kernel which does have some small performance 
impact.

> Till has developed a cheap DIY interface for HD44780 displays. If you
> got a spare T6963 display, maybe he will adopt his interface...
Or you take my project and use it to build such an interface yourself. This is 
"open hardware" ...

Till

-- 
Dr.Ing. Till Harbaum <ti...@ha...>
http://www.harbaum.org/till

[Lcd4linux-devel] LCD2USB pcbs

[Till H. <ti...@ha...>]

Hi,

i missed the UPS guy trying to deliver the PCBs today ... 

And i updated the firmware and the driver a little bit. The firmware now
supports controller auto detection and will automatically determine if
there's a display with one or two controllers installed (or no display at 
all). This information can be read back via USB. lcd4linux now writes
this information at startup to the console.

Furthermore i have implemented a simple echo test. This can be used
by client software to test the reliability of the USB implementation. The
driver currently tests 100 read/write cycles and writes the results to
the log. This should allow me to check if USB transfers are the problem
if any user encounters strange display output.

And there's a small routine to return the state of the two buttons.
And yes, it's possible to add two more buttons, although they are not
present on the current PCB. But there's a rs232 debug connector on the
PCB which can easily be used to add two more button inputs. This
is just a matter of firmware and just requires me to disable debugging
when the two additional buttons are to be used.

The buttons would IMHO integrate nicely into the timer concept 
described in the wiki. If buttons as well as timers could be used to
switch between different display configurations, then you can e.g.
use one button to switch to a different display (e.g. a detailed network
io screen) and have the screen return to the default state after 
a few seconds. Although there are plently of other things that could 
be done with some buttons, this simple mechanism would IMHO 
already add some cool new possibilities to lcd4linux.

Till

-- 
Dr.Ing. Till Harbaum <ti...@ha...>
http://www.harbaum.org/till

AW: [Lcd4linux-devel] LCD2USB status and Wiki vandalism

[<li...@ha...>]

Hi,

 --- Urspr=FCngliche Nachricht --- 
Datum: 31.01.2006 06:14
Von: Michael Reinelt <re...@eu...>
An: lcd...@li...
Betreff: Re: [Lcd4linux-devel] LCD2USB status and Wiki vandalism
> Till, where do you buy the electronic components? Maybe it would be a
> good idea to sell all the components, too. I guess some of them
> (inductors, the two elkos look like tantal ones, the quartz oscillator)
> will be hard to get. My only local source is Conrad, which has a very
> limited range of products. If I order them in Germany (Reichelt, Segor)
> the shipping is very expensive...
I usually buy all my stuff online from reichelt or conrad. Shipping in
germany
is not expensive, so there's no reason for me to not do this.

But i am sure i could buy all the parts in local stores as well. The
crystal
is quite common with 12 Mhz, the elkos can be of any type and the
inductors ...
you might even try to replace them by a wire (the one in the power supply)
and
by e.g. a 47 ohms resistor (the one in contrast generation).

Maybe ordering from germany and forwarding everthing to you is cheaper.

> btw, I'm looking for a MAX1709.
Maxim parts have a problem: You can easily get some free sample, but
buying 
larger quantities is always a hassle. I know distributors that don't sell
maxim for exaclty that reason.

Ciao,
  Till

Re: [Lcd4linux-devel] LCD2USB status and Wiki vandalism

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

Hi Till,

> BTW: The LCD2USB pcbs aren't as cheap as i was hoping and 
> i estimate that one of them will cost me EUR 11.80, so the 
> final price will be ~12.00 + shipping ... if i didn't get the calculation 
> wrong ...
Should be no problem (at least not for me)

> Perhaps i'll be offering to add a preprogrammed mega8 cpu for
> about EUR 6. I haven't decided yet if i'll sell sompletely assembled
> devices as well.
If Till is short on time, I can help with soldering and programming, too.

Till, where do you buy the electronic components? Maybe it would be a
good idea to sell all the components, too. I guess some of them
(inductors, the two elkos look like tantal ones, the quartz oscillator)
will be hard to get. My only local source is Conrad, which has a very
limited range of products. If I order them in Germany (Reichelt, Segor)
the shipping is very expensive...

btw, I'm looking for a MAX1709.


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] LCD2USB status and Wiki vandalism

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

Hi Till,

> And the wikis front page was damaged. I restored the last useful
> version, but we should expect this to happen again. Perhaps
> some login etc. is needed. 

This is the second time that the start page is full of "wiki spam". So
it happens about once a year...

I've been thinking about restricting write access, but this is not the
idea of a wiki. And it happens that seldom, and it's easy to correct (at
least for me), so I'll leave it as it is.

Note that there *is* some sort of "access control": I am a "TracAdmin",
which means that I have some more options in the wiki,including the
possibility to delete whole pages (or page versions).

So I just deleted the last threee versions of the start page (including
Till's restore, sorry :-)


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] LCD2USB status and Wiki vandalism

[Till H. <ti...@ha...>]

Hi again,

BTW: The LCD2USB pcbs aren't as cheap as i was hoping and 
i estimate that one of them will cost me EUR 11.80, so the 
final price will be ~12.00 + shipping ... if i didn't get the calculation 
wrong ...

Perhaps i'll be offering to add a preprogrammed mega8 cpu for
about EUR 6. I haven't decided yet if i'll sell sompletely assembled
devices as well.

Anyway, i have ordered 30 of them and i hope that i'll be able 
to sell them to you :-)

They are designed to work out of the box with most standard 
LCDs incl. most of the displaytech ones (2*16, 2*20, 4*20, 
2* 40 and 4*40).

Till

-- 
Dr.Ing. Till Harbaum <ti...@ha...>
http://www.harbaum.org/till

[Lcd4linux-devel] LCD2USB status and Wiki vandalism

[Till H. <ti...@ha...>]

Hi,

the LCD2USB interface now supports the adjustable backlight and
displays with dual controller (tested with a 4x27 display from pollin. 
if your are searching a cheap display: they cost 4.95 ....)

I have used your updates Michael and the driver works fine.

And the wikis front page was damaged. I restored the last useful
version, but we should expect this to happen again. Perhaps
some login etc. is needed. 

Ciao,
  Till

-- 
Dr.Ing. Till Harbaum <ti...@ha...>
http://www.harbaum.org/till

Re: AW: [Lcd4linux-devel] problem with the uptime plugin?

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

Hi,

>> The "right" fix would be to use strncpy (x, y, lenght+1) because
>> length does not count the trailing zero.
> 
> If this is a useful solution, then there isn't any reason to use 
> strncpy instead of strcpy. strncpy will always fail if it truncates a
> string. So you are either sure that the string will not be truncated
> and can thus use strcpy. Or you aren't sure. Then your length+1
> wouldn't work as well.

You are right. And what I didn't know was that strncpy pads the whole
remaining bytes with zeros, which is absolutely useless here.

I found about strlcpy, but that's far from being portable.

So I changed back to strcpy, because I consider it safe here.


Thanks, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

AW: [Lcd4linux-devel] problem with the uptime plugin?

[<li...@ha...>]

Hi Michi,

 --- Urspr=FCngliche Nachricht --- 
Datum: 30.01.2006 07:02
Von: Michael Reinelt <re...@eu...>
An: lcd...@li...
Betreff: Re: [Lcd4linux-devel] problem with the uptime plugin?
> The "right" fix would be to use strncpy (x, y, lenght+1) because length
> does not count the trailing zero.
If this is a useful solution, then there isn't any reason to use
strncpy instead of strcpy. strncpy will always fail if it truncates a
string.
So you are either sure that the string will not be truncated and can thus
use
strcpy. Or you aren't sure. Then your length+1 wouldn't work as well.

> The "very right" fix would be tho change the meaning of 'length' to the
> size of the string buffer. For any unknown reason I defined it to be
the
> "maximum string length", which leads to this off-by-one errors...
Whatever your "length" will be: If strncpy truncates the string you always

have to manually add the trailing zero.

Ciao,
  Till

Re: [Lcd4linux-devel] problem with the uptime plugin?

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

Hi Till,

>>Up 0 days 01:33:58@=E2=96=92  (the last two chars are garbled and two s=
paces before
>>                                       the 0 are missing)

> This was due to a bug in the eval() routine in evaluator.c. The problem=
:=20
> strncpy does not add a trailing 0, if it truncates a string. Therefore =
one=20
> has to manually add the string termination char. Fixed in the CVS.

Thanks a lot for debugging. This leak was introduced by fixing another
memory leak in the evaluator.

The "right" fix would be to use strncpy (x, y, lenght+1) because length
does not count the trailing zero.

The "very right" fix would be tho change the meaning of 'length' to the
size of the string buffer. For any unknown reason I defined it to be the
"maximum string length", which leads to this off-by-one errors...

I'm going to change this in CVS.


bye, Michael

--=20
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] Help needed: LCD4Linux goes RGB

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

Hi there,

I just checked in a bigger change. In preparation for the image widget
(yes, there will be an image widget where you can load a PNM or PNG and
place it in the background) I converted the whole graphic subsystem to
RGBA (yes, Alpha-blending)

The X11 driver works, some of the other drivers *should* work. At least
they compile...

major change: Do not access drv_generic_graphic_FB[] anymore, but use
the drv_generic_graphic_gray(row, col) function instead, which returns
the gray value of a pixel. For B/W displays, draw a pixel if gray > 0
(to keep things simple)

I'm especially asking the authors of the G15 and LUI driver to check
their code, because I cannot test these displays (in the case of LUI, I
cannot even compile because of missing headers)


Second, I'm currently doing alpha-blending with integer arithmetics. But
I'm not sure if the code is right (but I'm sure it's far from optimal).
Someone with deeper knowledge than me?


Third, the X11 driver is very slow now, because I'm doing an
XAllocColor() for every pixel. Again, I'd need someone with X11
programming knowledge....


TIA, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] problem with the uptime plugin?

[Till H. <ti...@ha...>]

Hi,

just to answer my own bug report :-)

On Saturday 28 January 2006 15:19, Till Harbaum wrote:
> Up 0 days 01:33:58@=E2=96=92  (the last two chars are garbled and two spa=
ces before
>                                        the 0 are missing)
> instead of
> Up   0 days 01:35:56

This was due to a bug in the eval() routine in evaluator.c. The problem:=20
strncpy does not add a trailing 0, if it truncates a string. Therefore one=
=20
has to manually add the string termination char. Fixed in the CVS.

Till

=2D-=20
Dr.Ing. Till Harbaum <ti...@ha...>
http://www.harbaum.org/till

[Lcd4linux-devel] problem with the uptime plugin?

[Till H. <ti...@ha...>]

Hi,

i have just been debugging my driver for quite some while to find out, why
i sometimes get=20

Up 0 days 01:33:58@=E2=96=92  (the last two chars are garbled and two space=
s before         =20
                                       the 0 are missing)
instead of=20
Up   0 days 01:35:56

This just happens every few seconds. I finally found out, that the string i=
s=20
already passed this way to my driver. How comes? Is this a known issue?
The wrong string is given to drv_L2U_write().

See my config file attached. It's fairly simple and i really don't see why=
=20
this might be happening. Since the string is passed this way to my driver
i really don't think that my driver may be the culprit.

Till

=2D-=20
Dr.Ing. Till Harbaum <ti...@ha...>
http://www.harbaum.org/till

Re: [Lcd4linux-devel] USB based hd44780 units ...

[Till H. <ti...@ha...>]

Hi list,

the lcd2usb project now has its own usb ids, a seperate driver in the 
lcd4linux cvs, firmware source code, schematics, pcb layout etc on its web 
page at http://www.harbaum.org/till/lcd2usb. And the first few industry 
quality pcbs will hopefully arrive soon.

lcd2usb is not bwct compatible anymore, but now has its own driver and 
protocol. The new protocol is four times faster, supports backlighting and 
future firmware and driver versions will support multiple displays and two 
input buttons.

Stay tuned ...

Till

-- 
Dr.Ing. Till Harbaum <ti...@ha...>
http://www.harbaum.org/till

RE: AW: [Lcd4linux-devel] USB based hd44780 units ...

[Luis.F.Correia <Lui...@se...>]

Hi Michael,

> -----Original Message-----
> From: Michael Reinelt [mailto:re...@eu...] 
> Sent: Thursday, January 26, 2006 10:54 AM
> To: lcd...@li...
> Subject: Re: AW: [Lcd4linux-devel] USB based hd44780 units ...
> 
> Hi Luis,
> 
> > there is a much more cheaper source for those DC-DC converters, old 
> > ethernet cards with the BNC connector, it is a big black 
> block, shown 
> > vertically with the letters YLC, in this link:
> 
> You are right, but (there's always a 'but' :-)
> 
> A 5V to negative converter would be better here (as there are 
> no 12V when powered by USB).
> 
> These convertes from ethernet cards are all quite large (at 
> least these that I've seen), while the converter I've been 
> using are really small (and may be mounted somewhere on the board)

You are also correct, but let's face it, a display that requires
negative voltages, is usually an old device which would certainly
require a lot more then the 500mA that the USB port supplies, 
therefore requiring a separate power source.

Nonetheless, the current DC-DC converters are indeed quite small
while also being effective.

Luis

Re: AW: [Lcd4linux-devel] USB based hd44780 units ...

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

Hi Luis,

> there is a much more cheaper source for those DC-DC converters,
> old ethernet cards with the BNC connector, it is a big black block,
> shown vertically with the letters YLC, in this link:

You are right, but (there's always a 'but' :-)

A 5V to negative converter would be better here (as there are no 12V
when powered by USB).

These convertes from ethernet cards are all quite large (at least these
that I've seen), while the converter I've been using are really small
(and may be mounted somewhere on the board)


bye, Michael

-- 
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

RE: AW: [Lcd4linux-devel] USB based hd44780 units ...

[Luis.F.Correia <Lui...@se...>]

Hi there,=20

> -----Original Message-----
> From: Michael Reinelt [mailto:re...@eu...]=20
> Sent: Thursday, January 26, 2006 10:02 AM
> To: lcd...@li...
> Subject: Re: AW: [Lcd4linux-devel] USB based hd44780 units ...
>=20
> Hi there,
>=20
> >>I've just an other question. Does your layout support a negative=20
> >>contrast voltage? I've a display which needs a negative contrast =20
> >>voltage...
>=20
> Really? A HD44780 Display with *negative* contrast voltage?=20
> Never seen this...
>=20
> anyway, there are very small DC/DC converters which can=20
> produce -5V (or even -12V) out of +5V.
>=20
> Look for "RO-0505S", Conrad sells them for about 8=E2=82=AC

there is a much more cheaper source for those DC-DC converters,
old ethernet cards with the BNC connector, it is a big black block,
shown vertically with the letters YLC, in this link:

http://blackbox.minidns.net/Bilder/Verkauf/isa_ne2000.jpg

In this case it is a 12V to 9V converter, which can be used to=20
provide negative voltage, by properly connecting it.
There are some datasheets available for those DC-DC converters,
just search for the model you got.

Hope this helps a bit ;)


Luis Correia  =20
Bering uClibc Team Member

PGP Fingerprint: BC44 D7DA 5A17 F92A CA21 9ABE DFF0 3540 2322 21F6=20
Key Server: http://pgp.mit.edu

Re: AW: [Lcd4linux-devel] USB based hd44780 units ...

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

Hi there,

>>I've just an other question. Does your layout support a negative
>>contrast voltage? I've a display which needs a negative contrast
>> voltage...

Really? A HD44780 Display with *negative* contrast voltage? Never seen
this...

anyway, there are very small DC/DC converters which can produce -5V (or
even -12V) out of +5V.

Look for "RO-0505S", Conrad sells them for about 8=80


bye, Michael

--=20
Michael Reinelt <re...@eu...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

AW: [Lcd4linux-devel] USB based hd44780 units ...

[<ti...@ha...>]

Hi,

 --- Urspr=FCngliche Nachricht --- 
Datum: 26.01.2006 09:49
Von: Nico Wallmeier <nic...@po...>
An: Till Harbaum <ti...@ha...>
Betreff: Re: [Lcd4linux-devel] USB based hd44780 units ...
  
> I've just an other question. Does your layout support a negative
> contrast voltage? I've a display which needs a negative contrast
voltage...
No, it doesn't. I don't have such a display and never had. You'll have
to modify the pcb to support this. 

Ciao,
  Till