lcd4linux-users

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

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