SPI (DOGL-Display)

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

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.

<aufdiekackehau>
Kann es ja mal bei Zeiten verbessern!
</aufdiekackehau>

Mir ist nun aufgefallen, dass die Standard-Bezeichnungen für die Pins 
nicht übereinstimmen.
Wie also ist die richtige Zuordnung?

Kann das stimmen:

MIS0          --  // Wird nicht gebraucht, da nicht gelesen werden kann.
MOSI          --  SI
/SS(Freigabe) --  /CS1
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.pdf
http://www.lcd-module.de/deu/pdf/grafik/dogxl160-7.pdf

[J. W. (jw-lighting)]

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

[thomas (Gast)]

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.

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

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 (Gast)]

Hi

Und A0 erst umschalten wenn die Übertragung wirklich beendet ist.

MfG Spess

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

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.

[Der Tukan (Gast)]

An D0...7 und A0 darfst du solange rumfummeln wie du willst. Sobald SCL 
kommt, muss aber alles korrekt stehen.

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

Der Tukan schrieb:
> An D0...7 und A0 darfst du solange rumfummeln wie du willst. Sobald SCL
> kommt, muss aber alles korrekt stehen.

Alles klar!

[spess53 (Gast)]

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

[R. W. (quakeman)]

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

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

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

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

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 (Gast)]

>Ey! Super! Eine laufende Library!

Wenn du nach DOGM-128 suchst dann findest du noch mehr.
Scheint wohl das gleiche zu sein.

[Fabian H. (Firma: Technische Universität Berlin) (brein)]

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?

[holger (Gast)]

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

[spess53 (Gast)]

Hi

>Du meinst also, es gibt da noch mehr Libraries?

>Eine liegt auf meinem PC...

Auf meinem auch. Sogar EA hat etwas.

MfG Spess

[Peter D. (pdiener)]

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

[Peter D. (pdiener)]

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.