mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik S65 display library on AT90CAN128: Compile errors


Autor: Stefan L. (tarabas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan L. (tarabas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...
    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

Autor: Stefan L. (tarabas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: volltroll.de (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Nokia mit LS020." Äh, ist der LS020 nicht im S65er Display, oder in 
beiden?
Bei einen von den beiden Displays gibts nen Kommando um das Display zu 
spiegeln/Drehen. Steht auch in dem Quellcode drin(afair).

Autor: Stefan L. (tarabas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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**

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan L. (tarabas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan L. (tarabas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.