[solved] Problem mit VFD gu256x128D-3900

Hast du gecheckt ob das Ding controllertechnisch überhaupt unterstützt wird? Sonst kannste ewig versuchen und testen ....

arghgra

Zitat

Original von detlef
Hier wurde geäussert, dass es gehen könnte:

http://www.vdrportal.de/board/thread.php?threadid=20769&sid=&threadview=0&hilight=&hilightuser=0&page=2

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

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

########################################################################


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

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?

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

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():

if(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

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