Hallo Leute!
Ich programmiere gerade ein EA DOGL-128.
Ich möchte es über SPI ansprechen, da jedes Display der EA DOG-Reihe
über SPI angesprochen werden kann.
(Gut, das DOGL kann nur über SPI angesprochen werden, da habe ich jetzt
nicht so wirklich die Wahl. Aber ich bekomme auch bald das DOGXL.)
Ich finde das sehr gut, da ich bisher nicht gezwungen war, mich mit SPI
auseinander zu setzen. Somit aber schon.
Ich habe kein Problem damit, etwas zu versuchen und damit zu scheitern.
So habe ich mir einfach das Datenblatt angesehen und über Pinwackeln
versucht das notwendige Verhalten zu erzeugen, wie es im Datenblatt Auf
der Seite 5 beschrieben.
Funktioniert aber noch nicht. Ursachen, kann es aber viele haben.
So wollte ich erstmal das Hardware-SPI meines ATmega32 nutzen, um
fehlerhafte Programmierung meinerseits zu vermeiden.
Dazu habe ich mich jetzt über SPI belesen. Leider ist der
SPI-Artikel nicht wirklich gut.
1
<aufdiekackehau>
2
Kann es ja mal bei Zeiten verbessern!
3
</aufdiekackehau>
Mir ist nun aufgefallen, dass die Standard-Bezeichnungen für die Pins
nicht übereinstimmen.
Wie also ist die richtige Zuordnung?
Kann das stimmen:
1
MIS0 -- // Wird nicht gebraucht, da nicht gelesen werden kann.
2
MOSI -- SI
3
/SS(Freigabe) -- /CS1
4
SCK -- SCL
Wäre nahe liegend oder?
/RST geht dauerhaft auf 1.
Aus dem A0-Pin werde ich noch nicht so schlau.
Wie weiß der Display-Controller, von welchen Bit gerade gesprochen wird?
Kann /CS1 auch dauerhaft auf GND gesetzt werden? Oder ist dessen
fallende Flanke der Start für den Zähler?
Bei den anderen Modellen, zum Beispiel dem DOGXL sind die Bezeichnungen
wieder anders. Kann das am Kontext liegen? Oder weshalb ist das so?
Ich meine SI für Slave In kann ich mir ja noch erklären, aber SDA
wie beim DOGXL?
Danke für hilfreiche Tipps
Fabian
______________________________________________
P.S. Seit wann kann man eigentlich keine PDFs mehr anhängen, dass ging
doch mal!?
http://www.lcd-module.de/pdf/grafik/dogl128-6.pdfhttp://www.lcd-module.de/deu/pdf/grafik/dogxl160-7.pdf
Fabian Hoemcke schrieb:> Ich meine SI für Slave In kann ich mir ja noch erklären, aber SDA> wie beim DOGXL?
Die Bezeichnungen rühren vom ebenfalls unterstützen I2C-Protokoll her,
und sind dort Standart. Siehe auch das von dir verlinkte Datenblatt.
LG :)
An dem Zustand von A0 unterscheidet der Display-Controller zwischen
Befehlen und Daten.
Achte auch auf die richtige Konfiguration des SPI - im Register SPCR
müssen Phase und Polarität des Taktes eingestellt werden. Ich hatte das
Display laufen mit CPOL=0 und CPHA=0.
thomas schrieb:> im Register SPCR> müssen Phase und Polarität des Taktes eingestellt werden.
Danke für den Tipp!
Das hatte ich zwar schon auf dem Schirm, aber das heißt ja nicht, dass
ich es richtig gemacht hätte! ;)
spess53 schrieb:> Hi>> Und A0 erst umschalten wenn die Übertragung wirklich beendet ist.>> MfG Spess
Das verstehe ich nicht.
Laut dem Timing Diagram im Datenblatt muss A0, wenn überhaupt parallel
zum Wechsel der Bytes kommen. Also während D0 und dann D7 übertragen
werden.
Hi
>Laut dem Timing Diagram im Datenblatt muss A0, wenn überhaupt parallel>zum Wechsel der Bytes kommen. Also während D0 und dann D7 übertragen>werden.
Nein. Da darf es frühestens kommen. Das Timing wie auf dem Bild bekommst
du so nur schwer oder gar nicht mit dem Hardware-SPI hin. Daher ist es
besser und einfacher vor dem Umschalten von A0 das Ende der Übertragung
(SPIF in SPSR abfragen) abzuwarten.
MfG Spess
Ich habe letztes Jahr selber mit dem DogL herumgespielt und eine Library
dafür geschrieben gehabt. Diese ist zwar für einen LPC900, aber in C
geschrieben und es gibt nur eine einzige Methode, die Controller
spezifisch ist (SPI Ausgabe). Die für dich vermutlich interessanten
Routinen dadrin sind v_Init_DogL128() und v_Write_DogL128(). Es sind
auch einfache Methoden zum Zeichnen und eine 8x5 Pixel Schriftart
enthalten.
Beim Init ist mir damals aufgefallen, dass das LCD nach dem Einschalten
häufig nur funktionierte, wenn ich die Reset Leitung für kurze Zeit auf
0 legte. Scheinbar führt das LCD keinen zuverlässigen Einschaltreset
durch.
Die Lib findest du unter [1] und die dazugehörige Header Datei unter
[2].
Ciao,
Rainer
[1]
https://quakeman.homelinux.net/viewvc/uVision/trunk/Library/LCD_DogL128_Funktionen.c?view=markup
[2]
https://quakeman.homelinux.net/viewvc/uVision/trunk/Library/LCD_DogL128_Funktionen.h?view=markup
spess53 schrieb:> Hi>>>Laut dem Timing Diagram im Datenblatt muss A0, wenn überhaupt parallel>>zum Wechsel der Bytes kommen. Also während D0 und dann D7 übertragen>>werden.>> Nein. Da darf es frühestens kommen. Das Timing wie auf dem Bild bekommst> du so nur schwer oder gar nicht mit dem Hardware-SPI hin. Daher ist es> besser und einfacher vor dem Umschalten von A0 das Ende der Übertragung> (SPIF in SPSR abfragen) abzuwarten.>> MfG Spess
Das heißt, wenn A0 gesetzt sein soll für eine Übertragung, dann frage
ich das SPIF ab, setze dann A0 und starte dann die Übertragung indem ich
das eigentliche Byte (D7-D0) in das SPDR schreibe?
Gruß
Fabian
Fox Mulder schrieb:> Ich habe letztes Jahr selber mit dem DogL herumgespielt und eine Library> dafür geschrieben gehabt. Diese ist zwar für einen LPC900, aber in C> geschrieben und es gibt nur eine einzige Methode, die Controller> spezifisch ist (SPI Ausgabe). Die für dich vermutlich interessanten> Routinen dadrin sind v_Init_DogL128() und v_Write_DogL128(). Es sind> auch einfache Methoden zum Zeichnen und eine 8x5 Pixel Schriftart> enthalten.>> Beim Init ist mir damals aufgefallen, dass das LCD nach dem Einschalten> häufig nur funktionierte, wenn ich die Reset Leitung für kurze Zeit auf> 0 legte. Scheinbar führt das LCD keinen zuverlässigen Einschaltreset> durch.>> Die Lib findest du unter [1] und die dazugehörige Header Datei unter> [2].>> Ciao,> Rainer>> [1]> https://quakeman.homelinux.net/viewvc/uVision/trun...> [2]> https://quakeman.homelinux.net/viewvc/uVision/trun...
Ey! Super! Eine laufende Library!
Werde es mir bald anschauen!
Heute komme ich nur nicht mehr dazu!
Aber Danke!
Fabian
holger schrieb:>>Ey! Super! Eine laufende Library!>> Wenn du nach DOGM-128 suchst dann findest du noch mehr.> Scheint wohl das gleiche zu sein.
Stimmt, sogar der Controller ist der gleiche!
Auch die Auflösung stimmt.
Du meinst also, es gibt da noch mehr Libraries?
>Du meinst also, es gibt da noch mehr Libraries?
Eine liegt auf meinem PC und ein paar tausend im Internet.
Wenn man nicht sucht dann findet man natürlich auch nicht.
Ich hab auch eine eigene Lib für das DOGL geschrieben.
Es ist wichtig, Reset nach dem Start gezielt anzusteuern, einfach
festhängen reicht nicht aus.
Grüße,
Peter
Ach ja: CS ist auch der Sync für die Bytegrenzen, muss also auch bei
einem einzelnen Slave angesteuert werden. Ich glaube, mich zu erinnern,
dass das Display auch funktioniert, wenn man das nur gelegentlich macht,
aber irgendwann muss man einen Sync machen. So gibts aber mehr EMV
Probleme, deswegen steuer ich das bei jedem Byte.
Also: Festhängen geht auch da nicht.
Eine eigene Frage?
Dieser Thread ist über 14 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
