Hallo Leute,

ich versuche gerade die S65 display library von Christian Kranz auf
einem AT90CAN128 zum laufen zu bekommen.
(Querverweise:
 Beitrag "The Siemens S65 132x176, 65536 color display with AVR"
 Beitrag "Nokia 6100 Grafiklibrary die Zweite")

Die mitgelieferte Demo für den Mega128 geht prima, nur auf dem CANxxx
gibt es folgende Fehler:

glcd_init.asm:91: Error: number must be positive and less than 32
glcd_init.asm:94: Error: number must be positive and less than 32

das bezieht sich auf folgende Zeilen in "glcd_init.asm":

...
SPI_SEND:   
    sbi     LCD_SPCR,SPE        ;enable SPI
...
SPI_SEND_0: 
    sbis    LCD_SPSR,SPIF
...

Ursache ist klar: beim Mega128 sind die SPI-Register im Bereich
0x0d-0x0f, also noch im IO-Bereich (unterste 32 Byte). Beim CANxxx sind
sie jedoch bei 0x2c-0x2f und damit für SBI/SBIS u.ä. unerreichbar.

Habt Ihr eine Idee, wie man das umschreiben könnte? Ich hab da momentan
einen Knoten im Gehirn.

Mir fällt nur folgendes ein, kommt mir aber doof und ineffizient vor,
außerdem ist mir unklar, welches Register noch frei ist. Hier eins mit
PUSH/POP zu sichern, macht es noch ineffizienter.

...
SPI_SEND:   
    in      Rxx, LCD_SPCR
    ori     Rxx, 1<<SPE
    out     LCD_SPCR,Rxx
...
SPI_SEND_0:
    in      Rxx, LCD_SPSR
    sbrs    Rxx, SPIF
...

An dem gleichen Problemchen klemmt übrigends auch Hagens glcd-library.

Please advise!

Grüße, Stefan

Also die erste Frage kann ich schonmal halbwegs beantworten:

der o.g. Code kann angepaßt werden zu, glcd_init.asm ab Zeile 90:

SPI_SEND:   
    push r16                    ;* register sichern
    in r16,LCD_SPCR             ;* SPI Control in register
    ori r16,1<<SPE              ;* Bit setzen
    out LCD_SPCR,r16            ;* wieder augeben
    pop r16                     ;* register wiederherstellen
    out     LCD_SPDR,T1         ;load byte in SPI data register

    push    r0                  ;short time workaround to be fixed
SPI_SEND_0: 
    in r0, LCD_SPSR             ;* SPI Status lesen
    sbrs r0,SPIF                ;* nächste Überspringen wenn SPIF in R0 gesetzt
    rjmp    SPI_SEND_0          ;transmitt byte to LCD
    in  r0,LCD_SPDR
    pop r0

Nicht elegant, aber damit geht erstmal die Grundlegende Ansteuerung.

Trotzdem steh ich grade Kopf, weil alles auf dem Kopf steht.
Soll heißen, die Orientierung im Display ist nicht ok.
Habe schon rumgespielt mit glcdSetOrientation(ORIENTATION_0)
und anderen Werten, aber immer noch Kopfstand.

Hat jemand dieses Feature der Lib zum laufen bekommen? In welcher
Reihenfolge müssen diese Aufrufe kommen? Vor/Nach glcdDisplayInit();??

Please Help!  // Stefan

...
    in  r0,LCD_SPDR
    pop r0
...

und was soll nach dem pop r0 in r0 drinnen stehen ? bestimmt nicht dasw
as du vorher mit in darin geladen hast, oder ?

Gruß Hagen

Hagen Re schrieb:

> und was soll nach dem pop r0 in r0 drinnen stehen ? bestimmt nicht dasw
> as du vorher mit in darin geladen hast, oder ?

Nein, das, was mit dem push r0 in der Zeile vor SPI_SEND_0: gerettet
wurde.

Da die Ausgabe prinzipiell funktioniert, ist dieser Workaround für mich
ok.

Das Problem liegt in der Orientierung :( es steht alles Kopf und ich
weiß nicht wieso oder wie das zu ändern ist.

Mein Display ist von Display3000, es ist ein Nokia mit LS020....

Hagen Re schrieb: (die 2te)
> und was soll nach dem pop r0 in r0 drinnen stehen ? bestimmt nicht dasw
> as du vorher mit in darin geladen hast, oder ?

Nein, das, was mit dem push r0 in der Zeile vor SPI_SEND_0: gerettet
wurde.

Mal nochmals mit dem Originalcode vergleichen:

SPI_SEND:   
    sbi     LCD_SPCR,SPE        ;enable SPI
    out     LCD_SPDR,T1         ;load byte in SPI data register
SPI_SEND_0: 
    sbis    LCD_SPSR,SPIF
    rjmp    SPI_SEND_0              ;transmitt byte to LCD
    push    r0          ; short time workaround to be fixed
    in  r0,LCD_SPDR
    pop r0
    sbi     LCD_PORT,LCD_CS     ;deselect Display
    ret

Tja, die Frage ist, wofür dient der "short time workaround". Scheinbar
geht es nur darum, eine Lese-Operation auf LCD_SPDR auszuführen. Was
dort gelesen wurde, ist wohl uninteressant!?
Ich habe in meinem Code das pusc r0 vor die Warteschleife SPI_SEND_0;
geschoben, da ich ebenfalls r0 brauchte... liegt hier mein
Orientierungsproblem? Da SPI_SEND_0 von nirgends sonst angesprungen
wird, sollte das gehen.

Da die Ausgabe prinzipiell funktioniert, scheint dieser Workaround für
mich ok.

volltroll.de schrieb:
> "Nokia mit LS020." Äh, ist der LS020 nicht im S65er Display, oder in
> beiden?
Mein Display ist das ganz links, siehe
http://www.superkranz.de/christian/S65_Display/Dis...

volltroll.de schrieb:
> Bei einen von den beiden Displays gibts nen Kommando um das Display zu
> spiegeln/Drehen. Steht auch in dem Quellcode drin(afair).
Really? Hm, wo nur.... **äug**

also ich habe die Lib ursprünglich fürs Nokia entwickelt und Chrisian
hats dann portiert fürs S65. Meine eigene S65 lib unterstützt nur das
LPH und das aus gutem Grund. Bei dem ist nämlich die Ansteuersequenz für
die Orientierung etc.pp. bekannt.

Gruß Hagen

Hagen Re schrieb:

> Bei dem ist nämlich die Ansteuersequenz für
> die Orientierung etc.pp. bekannt.

Hallo Hagen.

Wo genau in deinen Source passiert die Orientierungs-Umschaltung in
deinem Code?

*Ich glaube, ich weiß jetzt, wie man diese Umschaltet beim LS020.*

Da ich zusammen mit dem Display eine library bekommen habe (die ich
leider nicht als Quelle veröffentlichen darf), kann ich dort aber nach
diesem Kommando schauen. Dort funktioniert das nämlich :D

Dort passiert das in einer Routine, die nebenbei ein Ausgabefenster
festlegt. Diese wird vor allen Ausgaben aufgerufen (CLS, Plot, Font,
Line etc) und legt dort immer den nötigen Bereich oder das gesamte
Display als Bereich fest, zusammen mit der Orientierung.

//folgende Kommandobytes müssen an das LS020 Display gesendet werden,
//um die Orientierung umzuschalten

//default (PORTRAIT)
0xEF, 0x08,
0x18, 0x00,            //0x00 ist der mode PORTRAIT
0x12, x1, 
0x15, x2,
0x13, y1,
0x16, y2 

//default (PORTRAIT180)
0xEF, 0x08,
0x18, 0x03,            //0x03 ist der mode PORTRAIT180
0x12, breite-1 - x1, 
0x15, breite-1 - x2,
0x13, hoehe-1 - y1,
0x16, hoehe-1 - y2 

//default (LANDSCAPE)
0xEF, 0x08,
0x18, 0x05,            //0x05 ist der mode LANDSCAPE
0x12, breite-1 - y1, 
0x15, breite-1 - y2,
0x13, x1,
0x16, x2 

//default (LANDSCAPE180)
0xEF, 0x08,
0x18, 0x06,            //0x06 ist der mode LANDSCAPE180
0x12, y1, 
0x15, y2,
0x13, hoehe-1 - x1,
0x16, hoehe-1 - x2 

Die Frage ist eher, wo man das in deiner bzw. Christians library
einpflegen muss/kann. Über Tips wäre ich sehr erfreut!

Grüße, Stefan

Deine Aussagen sind sehr interersant für mich ;)

So wie ich es in meiner GLCD umgesetzt habe ist der beste Punkt die
Orientierung zu setzen direkt vor den gemeinsam genutzen Basisfunktionen
wenn man das Fenster und die Start Addresse an der man zeichnen möchte
setzt. Also exakt so wie du es schreibst und in deiner nicht zu
veröffentlichen Lib auch gelösst ist.

Allerdings ist es in meiner Lib so aufgebaut das man die Orientierung
nicht zur Laufzeit sondern zur Compilezeit festlegt. Man legt also die
Ausrichtung des LCDs auf Grund der Bauform der eigenen HW fest.
Bestimmte Funktionen wie Linien, Fonts, Bitamps ändern dann zur Laufzeit
die Orientierung, spiegeln oder rotieren um +-90 Grad um effizienter zu
sein. Zb. die Linienfunktion kann nur in einem der vier Quadranten
zeichnen. Sie wird also für die anderen drei Quadranten die Orientierung
verändern und somit kann man die Linienroutine effizienter machen und
sie arbeitet in ihrer Liniendarstellung immer rotationssymmetrisch.
Die Fonts arbeiten grundsätzlich mit um +-90 Grad rotierter Orientierung
in Relation zur eingestellten Orientierung, da meine Fonts Spalten-
statt Zeilenweise die Pixel zeichnen.
Die Standardorientierung ist als zur Compiletime festgelegt und wir zur
Runtime bei der Initialisierung des LCDs das erste mal gesetzt. Werden
nun Grafikroutinen benutzt entscheiden diese ob sie mit einer
abweichenden Orientierung arbeiten müssen und setzen die aktuell
eingestellte dynamisch um und restaurieren diese dann wieder am Ende der
Funktion. Da dieser Switch wesentlich weniger wahrscheinlich ist als
nicht zu switchen hat man so den Kommunikationsoverhead minimiert und
damit die Gesamtperformance gesteigert.

In meiner Lib sind alle LCD spezifischen Kommandos als Makros umgesetzt,
also nicht in speziellen Funktionen. Damit werden sie erstens inlined
und zweitens kann man die Lib relativ einfach an andere LCDs anpassen.

Im CodeLib Thread habe ich es schon angeboten das man über eine PN bei
mir durchaus anfragen kann und den Source bekommt.

Gruß Hagen

Hagen, es freut mich dein Interesse zu sehen. Vielleicht haben wir ja
alle was davon, wenn das Problem verschwindet :)

Wenn ich ehrlich bin, finde ich es praktischer, nicht jedesmal die lib
compilieren zu müssen. Da ich mehrere Projekte mit verschiedenen CPUs
habe, wo das Display auch verschieden angeschlossen ist, würde ich das
lieber im Projekt als der lib festlegen, soll heißen, ich könnte auch
ohne Lib und nur mit Includes leben. Ist aber egal...

Dein Makro-Style ist atemberaubend, so daß ich noch nicht genug
durchsehe, um die o.g. Sache einzupflegen ;) oing

Jedenfalls schlug ein Test fehl, deine Lib und die mitgelieferte
gleichzeitig zu nutzen (mit deiner Ausgeben und mit der anderen die
Orientierung schalten). Hierbei ist die Ausgabe mit Portrait_0 ok, die
anderne sind verkrüppelt irgendwie. Mal sehen.

Stefan