Moin moin ...der Treiber für das im Betreff angegebene GLCD auf dem Linux/CentiPad läuft soweit erstmal. Es gibt allerdings eine Sache, an der ich mir die Zähne ausbeiße: Laut Datenblatt hat das GLCD 2K VRam. Bei 160x80 Dots sind das 40 Byte "zuviel". Mir will es einfach nicht gelingen, den Nullpuinkt der Grafikausgabe zu setzen. Mehrfach hintereinnander eingespielte Grafiken, die immer mit dem gleichen Set_Display_StartAddress beginnen, landen im Display an den verschiedensten Orten. Da Text noch weniger Platz im VRam verbraucht, habe ich bisher den Textmode nicht für eigene Texte benutzen können, kann Text aber sichtbar machen, wenn ich einfach das VRam von vorne bis hinten mit ASCII-Zeichen "zukloppe". Kennt hier jemand die Magie die hinter dem richtigen Setzen der Display StartAddresse und der Cursorpositionen liegt??? Ich sage schonmal herzlichen Dank im Voraus! Schönes Wochenende! Gruß mcc
Timingprobleme? Fragst du das Busy vor jedem Befehl ab?
Moin Benedict, laut datasheet muss lediglich vor jedem Instruction nicht jedoch vor dem Schreiben der Daten das Busy abgefragt werden. Das mache ich mit einer loop, das Busy pollt und nach jedem Check ein udelay(1) einlegt. Nach Verlassen der Loop wird Busy nocheinmal gefragt und wenn frei: Gib's ihm... Alles funzt, nur das Bild "wandert" bleibt aber heile.
Ich meinte jetzt nicht nur bei dem Busy sondern auch generell das Timing: Hält der ARM das ein?
Da ich keinen Osci besitze, kann ich Deine Frage nur nebulös beantworten: Alle Befehle außer die Sache mit dem Screen Offset funktionieren. Der CentiPad hat sonst zur Zeit nichts zu tun, es kommen also keine großartigen Kernel-Lasten zustande. Und wenn es tatsächlich am Timingleigen sollte, weiß ich nicht, wie ich das ohne ein Osci in den Griff bekommen soll...
Im Datenblatt des Prozessors müsste das Timing stehen. Vermutlich kann man das Timing auch in weiten Bereichen verstellen.
Moin Benedict, hab' den Fehler: Das Problem lag darin, dass ich annahm, dass die Display-Startadresse die Adresse ist, an die ein nachfolgender Write-Vram-Befehl seine Daten schreibt. Dem ist nicht so. Die Display-Startadresse ist die Adresse, die als linke obere Koordinate des Bildschirms angenommen wird. Der Schreibbefehl ins VRam beginnt mit der Adresse die über den Befehl "Set-Cursor Address register" vorher gesetzt wurde. Da diese Adresse beim Schreiben ins VRam mit jedem Byte ein Autoinkrement erfährt, landete meine Grafik -- und erst mein Text -- an immer wieder neuen Stellen... Gruß mcc