Hier schon mal ein kleiner Vorgeschmack auf das Display...
[solved] Problem mit VFD gu256x128D-3900
- detlef
- Geschlossen
-
-
Hi,
kurzer Zwischenstand:
Leider läuft das Display nicht mit graphlcd-0.1.2pre4. Beim starten des Plugins semmelt der vdr ab. Mit showpic bekomme ich eine Gleitkommaausnahme.
Wenn es nützlich ist, versuche ich nachher ein Backtrace zu erstellen.ralf1970, randy
Hoffentlich lest ihr mit und könnt mir evtl. helfen.Gruß
Detlef -
Hast du gecheckt ob das Ding controllertechnisch überhaupt unterstützt wird? Sonst kannste ewig versuchen und testen ....
arghgra
-
Hier wurde geäussert, dass es gehen könnte:
War halt nur ne Vermutung
-
Zitat
Original von detlef
Hier wurde geäussert, dass es gehen könnte:War halt nur ne Vermutung
Hmmm ... das ist sehr vage ....
Wolltest du das Ding als 128er oder als 64er testweise laufen lassen - was sagt denn die Doku dazu???
arghgra
-
Hallo arghgra,
Zitat
Wolltest du das Ding als 128er oder als 64er testweise laufen lassen
Habe beides probiert. Selbes Ergebnis.Zitat
was sagt denn die Doku dazu???
Welche? Vom Plugin oder vom Hersteller? Mit der Herstellerdoku kann ICH nicht
wirklich was anfangen. Würde es helfen, wenn ich sie Dir zukommen lasse?Danke schonmal für Deine Hilfe
Detlef -
Hat das Display auch DIP-Schalter? Wenn ja, SW6 auf ON um den DMA Modus zu aktivieren.
Die graphlcd.conf müßte ungefähr so aussehen(Ausschnitt):
Code
Alles anzeigen######################################################################## [gu256x64-3900] # gu256x64-3900 driver # This is a driver module for Noritake GU256X64x-3900 VFD displays. The # VFD is either operating in 8 bit-mode connected to a single PC # parallel port or in serial mode connected to a single PC serial port. # Default size: 256 x 64 Driver=gu256x64-3900 Port=0x378 #Device=/dev/parport0 Width=256 Height=128 UpsideDown=no Invert=no Brightness=100 AdjustTiming=0 RefreshDisplay=1 # Wiring # Select the type of wiring your display is connected with. # Possible values: 'Standard', 'Satyr' # Default value: 'Standard' Wiring=Standard # Interface # Select the interface your display is connnected to. # Possible values: 'Parallel', 'Serial' # Default value: 'Parallel' Interface=Parallel # DMA # Enables/disables the usage of the controller's DMA mode which # increases writing speed. This only works in parallel interface mode. # Possible values: 'yes', 'no' # Default value: 'yes' DMA=yes ########################################################################
-
Zitat
Original von Oxygen
Hat das Display auch DIP-Schalter? Wenn ja, SW6 auf ON um den DMA Modus zu aktivieren.
Hat es. SW6 ist auf on.Die Konfig. ist identisch mit o.a. mit Ausnahme des Ports. Der ist bei mir auf /dev/parport0. Ein Display mit ks_bla Kontroller funktioniert an diesem Port
einwandfrei.EDIT
Hab eben den Port wie oben eingestellt --> Display rührt sich nicht
/EDIT -
Zitat
Original von detlef
Hi,kurzer Zwischenstand:
Leider läuft das Display nicht mit graphlcd-0.1.2pre4. Beim starten des Plugins semmelt der vdr ab. Mit showpic bekomme ich eine Gleitkommaausnahme.
Wenn es nützlich ist, versuche ich nachher ein Backtrace zu erstellen.Mh ... 0.1.2pre hab ich selbst noch nicht probiert ... ich hab im Moment auch wenig Zeit meinen VDR diesbezüglich auf den neuesten Stand zu bringen. Könntest du testweise mal graphlcd-0.1.1 nehmen und schauen ob das Problem da das Gleiche ist? Wenn ja - bitte die Aufrufzeile von showpic und die Ausgaben die showpic macht mitschicken. Ein Backtrace wäre auch nett ... eventuell sieht man da ja was ...
Ralf
Nachtrag: Oxygen scheint ja seine Displays mit 0.1.2pre am laufen zu haben. Ist also doch eher unwahrscheinlich, dass sich beim Portieren auf die neue Version ein Fehler eingeschlichen hat. Wenn du also den Kram (egal ob 0.1.1 oder 0.1.2) mal mit Debug Code übersetzen könntest und dann einen Backtrace schickst kann man bestimmt was machen.
-
Hi Ralf,
das ging ja schnell Probiere ich gleich morgen früh mit der 0.1.1 Glaube aber nicht, dass es geht.
Mal sehen, ob ich das mit dem BT hinbekomme...Danke & Gruß
Detlef -
Hi,
hier der Backtrace:
Gelöscht weil falschen Treiber erwischt.
Aber jetzt tut sich was. Muss mal schnell die Treppe hoch....
Gruß
Detlef -
Jetzt brate mir mal jemand nen Storch! Habe nun ein Bild über die Hälfte des Displays (horizontal).
-
Deinem BT nach zu schließen hattest Du ja den falschen Treiber geladen. Hast Du die Höhe in der graphlcd.conf auf 128 Pixel angepasst?
-
Zitat
Original von Oxygen
Deinem BT nach zu schließen hattest Du ja den falschen Treiber geladen. Hast Du die Höhe in der graphlcd.conf auf 128 Pixel angepasst?
Ja, aber nur beim BT, weil ich den vdr händisch gestartet habe und den Controller
nicht mit angegeben hatte. Das Problem war wohl eine fehlende Zeile in der graphlcd.conf (RefreshDisplay=1). Die ist mir irgendwie abhanden gekommen.So siehts jetzt aus
Code
Alles anzeigen[gu256x64-3900] # gu256x64-3900 driver # This is a driver module for Noritake GU256X64x-3900 VFD displays. The # VFD is either operating in 8 bit-mode connected to a single PC # parallel port or in serial mode connected to a single PC serial port. # Default size: 256 x 64 Driver=gu256x64-3900 #Port=0x378 Device=/dev/parport0 Width=256 Height=128 UpsideDown=no Invert=no Brightness=100 AdjustTiming=0 RefreshDisplay=1 Wiring=Standard Interface=Parallel DMA=yes
-
.
-
Ich würde jetzt mal etwas mit WaitMethod, AdjustTiming und RefreshDisplay in der graphlcd.conf herumspielen. Ich habe bei meinen beiden Displays da auch unterschiedliche Werte in der Konfigdatei stehen.
Meine Displays sind an internen PCI-Schnittstellenkarten angeschlossen. Ich hatte in einem VDR derartige Probleme eine stabile Anzeige zu bekommen, dass ich nachher die Schnittstellenkarten untereinander ausgetauscht habe. Danach lief`s... -
Habe jetzt alle Bios/software- Kombinationen durchgetestet. Die Anzeige ändert sich dahingehend, dass sie entweder träge reagiert oder die Zeilen zerhackt dargestellt werden. Allerdings immer nur in der ersten Hälfte des Displays. Der Rest bleibt Dunkel
Eine 2. LPT bringt auch nicht DIE Verbesserung.Kann es nicht doch ein Treiberproblem sein? Die Verkabelung wird wohl ausscheiden.
-
Ok - gefunden.
Fehler meinerseits. Der Speichertansfer an das Display wird fix nach 2kB abgebrochen. Etwas cleverer wäre es gewesen das entsprechend der Pixelauflösung zu berechnen. Bei graphlcd-0.1.1 findest du die problematischen Zeilen in ./driver/gu256x64-3900.c ganz am Ende, in der Methode cGraphLCDDriverGU256X64_3900::Refresh():
Code
Alles anzeigenif(wiring==kDMA) { Write(dBLITIMAGE0); Write(dBLITIMAGE1); Write(dBLITIMAGE2); Write(dBLITIMAGE3); Write(0); // low byte address Write(0); // high byte address Write(0); // low byte size // Write(8); // high byte size Write(m_iSizeYb); // high byte size } else { Write(nSETCURSOR0); Write(nSETCURSOR1); Write(0); // low byte x Write(0); // high byte x Write(0); // low byte y Write(0); // high byte y Write(nBLITIMAGE0); Write(nBLITIMAGE1); Write(nBLITIMAGE2); Write(nBLITIMAGE3); Write(0); // low byte width Write(1); // high byte width // Write(8); // low byte height Write(m_iSizeYb); // low byte height Write(0); // high byte height Write(1); // end header }
... probier das mal - damit könnte der Rest vom Bild auch angezeigt werden. Ich weiß wie gesagt im Moment nicht in wie weit sich der Code bei 0.1.2pre4 geändert hat - sollte aber noch so ähnlich aussehen. Also einfach mal danach suchen ... sobald ich dazu komme werd ich den entspechenden Patch auch auf meine Download Seite legen.
Ralf
-
Wäre das so richtig?
Code
Alles anzeigenif (interface == kInterfaceParallel) port->Claim(); if (interface == kInterfaceParallel && useDMA) { Write(dBLITIMAGE0); Write(dBLITIMAGE1); Write(dBLITIMAGE2); Write(dBLITIMAGE3); Write(0); // low byte address Write(0); // high byte address Write(0); // low byte size // Write(8); // high byte size } else { Write(nSETCURSOR0); Write(nSETCURSOR1); Write(0); // low byte x Write(0); // high byte x Write(0); // low byte y Write(0); // high byte y Write(nBLITIMAGE0); Write(nBLITIMAGE1); Write(nBLITIMAGE2); Write(nBLITIMAGE3); Write(0); // low byte width Write(1); // high byte width // Write(8); // low byte height Write(0); // high byte height Write(1); // end header } for (xb = 0; xb < width; xb++) { for (yb = 0; yb < m_iSizeYb; yb++) { Write((m_pVFDMem[xb][yb]) ^ (config->invert ? 0xff : 0x00)); } // parallel port writing is busy waiting - with realtime priority you // can lock the system - so don't be so greedy ;) if ((xb % 32) == 31) { uSleep(1000); } } if (interface == kInterfaceParallel) port->Release(); } } } // end of namespace
-
Fast ... da sind zwei Fehler drin - einer von dir und einer von mir - wieder mal. Zum einen hab ich mich verschrieben - m_iSizeYb ist schon die durch 8 geteilte Größe in Y Richtung (ich korrigiere das gleich noch in meinem Posting von gestern Abend - man sollte nicht beim Fernsehen programmieren ...). Also das durch 8 in meinem Code ist Quatsch. Zusätzlich mußt du nicht nur die "Write(8)" Zeilen auskommentieren sondern auch die Zeilen mit "Write(m_iSizeYb)" dafür wieder einfügen. Was ich geschickt hatte wäre, wenn es richtig gewesen wäre, gewissermaßen das gewünschte Endergebnis Der Fehler ist, dass die 8 dort als Konstante steht. In Wirklichkeit ergibt sich die Größe des zu transferierenden Speicherbereichs natürlich aus den Pixel-Dimensionen des Displays. Ganz korrekt müßte es für useDMA heißen:
statt:
- Write(0);
- Write(8);+ Write((m_iSizeYb*width)&0xff)
+ Write((m_iSizeYb*width)>>8)Und wenn kein DMA verwendet wird:
statt:
- Write(0);
- Write(1);
- Write(8);
- Write(0);+ Write(width&0xff);
+ Write(width>>8);
+ Write(m_iSizeYb);
+ Write(0);Und schreib bitte ob das geholfen hat ... dann kann ich es ruhigen Gewissens in den Treiber übernehmen (lassen).
Ralf
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!