Graphlcd 0.1.2-2 unter VDRdevel 1.3.37 Problem

Hallo berniejonnie,

ist ja interessant, dass du das Problem auch hast. Da ich gleich mit der 0.1.2 eingestiegen bin habe ich mir nichts gedacht. Allerdings tritt das Problem bei mir nicht ständig und hauptsächlich in der Programmvorschau auf...!

WaitMethod=3
AdjustTiming -> Default

und ich habe ein T6963C...

Vielleicht sollte ich mal die Vorversion testen...!

Viele Grüße,
Max

Habt ihr schon einmal versucht die Fonts anzupassen (zu verkleinern) das wird in:
/etc/vdrdevel/plugins/graphlcd/fonts.conf eingestellt.

ich verwende in T6963C unter VDRDEVEL und das funktioniert eigentlich super, allerdings habe ich die Fonts verkleinert.
Hier einmal meine /etc/vdrdevel/plugins/graphlcd/fonts.conf

#Large Font = fnt:f12bn.fnt
#Normal Font = fnt:f8n.fnt
#Small Font = fnt:f5n.fnt
#Symbol Font = fnt:sym7.fnt


Large Font = fnt:f17bn.fnt
Normal Font = fnt:verdanab-013.fnt
Small Font = fnt:f8n.fnt
Symbol Font = fnt:sym11.fnt
jvdr:~# less /etc/vdrdevel/plugins/graphlcd/fonts.conf

und zur Sicherheit der Inhalt von:
/etc/vdrdevel/plugins/plugin.graphlcd.conf

-c /etc/graphlcd.conf -d t6963c

für VDR 1.2.x muss vdrdevel in den Pfaden durch vdr ersetzt werden

Viel Glück...

Hi berniejonnie,

danke! Dann werde ich auch mal mit dem AdjustTiming herumspielen. Leider weiß ich nicht wie wir dir jetzt helfen können...!

Viele Grüße,
Max

hallo berniejonnie,

Zitat

"Seit dem Update von TomG's VDRdevel 1.3.36 auf 1.3.37 funzt mein Graphlcd nicht mehr. Ich habe alle conf-Änderungen gemacht, alle Threads hier gelesen aber es wird nicht besser. Es ist ein ks0108, WaitMethod=3, AdjustTiming=19 aber es hilft alles nicht so recht.

Mit dem -plugin-graphlcd 0.1.1 gings noch tadelos, aber seit dem Update und dem -plugin-graphlcd 0.1.2-2 gibt es nur noch zerschnittene Inhalte aus. Es schaut aus, als ob die Synchronistion der Datenübergabe am /dev/parport (oder 0x378 genauso) nicht mehr klappt. Was hat sich von 0.1.1 auf 0.1.2-2 da geändert ?? Hat jemand eine Idee ????"

ist bei mir die gleiche Konstallation, gleiches Display. Der Fehler tritt nach einiger Zeit abrupt auf. AdjustTiming=35 scheint zumindest für den Augenblick zu helfen.

Mal sehen ...

Mist, habe gerade im Menü den Eintrag MPlayer ausgewählt: Vertikaler Schnitt in der Mitte, rechte und linke Hälfte des Displays laufen nicht mehr synchron (siehe Dein "Screenshot").
Das läßt sich auch zuverlässig reproduzieren

Gruße aus dem Rheinland

Hi dagobert_1 & berniejonnie,

das AdjustTiming=35 hat bei mir jedenfalls deutlich zur Verbesserung beigetragen. Danke dafür!!!

Zitat

Mist, habe gerade im Menü den Eintrag MPlayer ausgewählt: Vertikaler Schnitt in der Mitte, rechte und linke Hälfte des Displays laufen nicht mehr synchron (siehe Dein "Screenshot").
Das läßt sich auch zuverlässig reproduzieren

Muss ich leider bestätigen. Wenn es sich bei mir auch nur in 9 von 10 Fällen reproduzieren lässt...

Macht ein noch höherer Wert Sinn?

Viele Grüße,
Max

Hallo maxkr et al,

RefreshDisplay macht ja folgendes:

#  Normally, most of the drivers do not update the whole display, but
#  only the areas that have changed since last update. So it might be,
#  that some faulty pixels would stay a longer time. To avoid this, the
#  plugin makes a complete refresh from time to time. This parameter
#  defines how often a complete refresh will be done.
#  e.g.: A value of 5 means, that the plugin will make a complete
#        refresh on every 5th update.
#  A value of 0 completely disables complete refreshs.
#  Possible values: 0 <= x <= 50
#  Default value: 5

Somit sollte das Display beim Wert 1 nach jedem Update komplett refreshed werden. Hilft aber nicht. Scheint mir eher ein Fehler im plugin zu sein, der led. herausgezögert werden kann. Ist ja auch kein Pixelsalat, den man sieht.

Vielleicht sollten wir mal ein cross-posting auf das LCD Forum machen.

@ powARman+Randy: Wo sind die Experten ?

Gruß dagobert_1

ich hatte aehnliche probleme beim erstellen einer ks0108-unterstuetzung fuer meine library, die sich weder durch beeinflussung der signalgebung noch durch hinaufdrehen von delays verbessern haben lassen.
das problem liegt wohl bei CS1/CS2, die AEUSSERST empfindlich gegen nachschwingen zu sein scheinen (zu lange und/oder schlecht/nicht abgeschirmte zuleitungen). bei mir war dies durch eine zieml. lange zuleitung und einer ungeschirmten verkabelung auf einem experimentierboard noch verschaerft.

abhilfe schafften bei mir zwei kleine kondensatoren:

CS1 ----O---||----+
                  |
                  +---| GND
                  |
CS2 ----O---||----+

der wert der kondensatoren sollte irgendwo im pF-bereich liegen (ich habe einfach in eine kiste mit kondensatoren hineingegriffen und moeglichst kleine herausgefischt

wenn die ersten zeilen dann fehlen war der wert zu hoch -> kleinere kondensatoren nehmen.

seit dieser aenderung laeuft das display auch mit kleinen delays aeusserst stabil.

ERGAENZUNG:
hier der url zu einem thread zu selben thema (mit foto von meiner kondensatorloesung):
http://www.vdrportal.de/board/thread.php?threadid=42243&page=2&sid=

ERGAENZUNG 2:
diese veraenderung bitte nur bei displayloesungen mit schlecht abgeschirmten kabeln in erwaegung ziehen, wenn wirklich nichts mehr hilft und die probleme mit unterschiedlichen ansteuerungsprogrammen nicht in den griff zu bekommen sind!
'it worked for me but it may or may not work for you'

/wastl

berniejonnie

werd mir mal die unterschiede zw. 0.1.1 und 0.1.2 ansehen (weil es mich selber interessiert: da ich bei der erstellung meiner eigenen ansteuerung ja auch aehnliche probleme hatte.
das mit den kondensatoren war damals der letzte schritt vor der resignation: 'werfe ich das klump durch das geschlossene fenster oder probiere ich irgendeine verzweiflungstat'
die verzweiflungstat (kondensatoren) waren dann tatsaechlich die 'rettung'. habe vorher alle moeglichen aenderungen im signaling vorgenommen, einzelne signalwechsel verlaengert, delays verlaengert usw., usf. ...
im endeffekt hat bei mir immer nur CS1/2 hineingesch... gepfuscht)

du kannst aber auch gern den dzt. entwicklungsstand meiner lib testen, ob da der fehler auch auftritt ...

/wastl

Hallo wastl,

danke für den Tipp mit den Kondensatoren. Da das Problem aber wohl erst seit der neuen Version besteht werde ich mal davon absehen etwas zu verändern...

Viele Grüße,
Max

Hallo,

in der 0.1.2 habe ich die Ansteuerung des KS0108 verändert, da es Probleme mit einem Displaytyp gab, der jetzt wunderbar funktioniert. Außerdem ist die Ansteuerung auch mehr datenblattkonform gewesen, deswegen habe ich nicht gedacht das das Probleme bei anderen Displays verursacht. Da dem nun aber so ist, sehe ich erstmal als einzige Möglichkeit, die alte Variante parallel mit einzubauen und über die Config auswählbar zu machen.

Andreas

Hallo powarman,

das ist aber ein schönes Weihnachtsgeschenk

Fröhliche Weihnachten,
Max

Hallo,

ich habe mal unter http://home.arcor.de/andreas.r…phlcd-base-0.1.3-pre4.tgz
eine neue Version gestellt, bei der sich die Ansteuerungsvariante über die Config-Datei auswählen lässt. "Control" heißt der Parameter, zu finden in der KS0108 Sektion.

Andreas

Zitat

Original von powarman
ich habe mal unter http://home.arcor.de/andreas.r…phlcd-base-0.1.3-pre4.tgz
eine neue Version gestellt, bei der sich die Ansteuerungsvariante über die Config-Datei auswählen lässt. "Control" heißt der Parameter, zu finden in der KS0108 Sektion.

Mit dem Default Control=1 ist bei mir (graphlcd 0.1.2 mit graphlcd-base-0.1.3pre4, LCD von LC-Design mit KS0108) die Darstellung "defekt". Mit Control=0 sieht das besser aus - mal abwarten...

Nachtrag: Nach zwei Tagen wuerde ich sagen Problem geloest - Danke

habe die neue graphlcd-base ausprobiert (ohne Kondensatoren)

mit control=1: fehlerhaft (aehnlich wie foto oben v. starter des threads, aehnlich wie bei version 0.1.2)
mit control=0: fast fehlerfrei (nur noch aehnliche probleme wie bei meiner steuerung ohne kondensatoren (fehlerhafter klotz im jeweils anderem controller, tw. um eine zeile verschoben))
-> die kondensatoren scheinen wohl nur etwas bei schlechter verkabelung zu bringen (wie in meinem fall (experimentierboard, langes flachbandkabel, keine abschirmung, ...), ansonsten duerfte control=0 die loesung fuer die meisten hier sein.

/wastl

ergaenzung:
als root habe ich mit showpic keine probleme mit ioctl und /dev/parport2, als user die bereits beschriebenen probleme (ewige updatezeiten, ioctl-fehler en masse). interessant ... es tun sich immer wieder neue und interessante mysterien auf

ergaenzung 2:
mit kondensatoren und meiner 'speziellen' verkabelung:
control=0: fehlerfrei
control=1: ab und zu darstellungsfehler, aber weniger als oben (teilbilder in bestimmten situationen verschoben)