Hi,
ich versuche gerade ein DOGXL-Display an meinem STM32 per SPI zum laufen
zu bringen.
Den SPI zu aktivieren war erstaunlich einfach. Siehe angängenden
Screenshot meines LAs.
Obwohl ich die empfohlene Initsequenz verwende und die Verkabelung
dreimal überprüft habe passiert gar nichts.
Nach Aussage von Electronic Assembly müsste ich zumindest die
generierten LCD-Spannungen messen können, aber auch da ist tote Hose
(0V).
Hatte einer von euch schon mal das Problem?
Gruß
Tom
Ja, richtig, ich hab falsch abgelesen, es sind 2,25 MHz am SCK.
Ich würde testweise den CS zwischen den Datenworten wegnehmen um eine
bessere Synchronisation zu erzwingen.
Ich habe gerade folgendes alles nachgeprüft und das ist so in Ordnung:
Datenübernahme bei steigendem SCK.
Most Significant Bit first.
Initialisierungssequenz (Dateninhalt) stimmt.
CS wird auch im Beispiel vom Hersteller nur einmal auf low gesetzt.
Folgendes sollte man nochmal prüfen:
Wie es für mich aussieht, läuft das Display im 4 wire 8 bit SPI Modus.
Pin 26 und Pin 30 müssen demnach auf Gnd liegen.
Wird der Reset richtig durchgeführt?
Grüße,
Peter
Hallo,
würde mich mal interessieren woher ihr das DOGXL160 habt. Evtl mit
Touchscreen?!
Sobald ich mir dann eines gekauft habe kann ich gerne mithelfen.
Gruß
Jürgen
Hi
OK, das ist schlecht für mich. Dann bekomme ichs wirklich nirgends her.
D.h. Ich muss mir n anderes Display mit 3,3V und SPI suchen und du musst
auf meine Hilfe verzichten...
Gruß
Jürgen
PS: Auf der Hersteller Seite gibts unter Downloads so n Init Bsp, dass
du aber sicher schon gesehen hast.
Hi
stimmt die haben ja irgendwie so nen Service. Muss ich mal probieren...
Evlt kann ich mich ja in n paar Tagen mit ner funktionierenden Lösung
melden.
Gruß
Jürgen
Ich hatte mit dem DogL128 das Problem, dass es nach dem Start und
korrekter Initialisierung ebenfalls nicht funktionierte. Das Problem lag
dadran, dass ich den Reset nicht lange genug ausgeführt hatte.
Mittlerweile mache ich immer vor den eigentlichen Init Befehlen erst
einen 5ms langen Reset des Displays und seit dem funktioniert es
problemlos.
Eventuell solltet ihr das noch mal ausprobieren.
Ciao,
Rainer
Also mein Problem ist, das ich ab und zu was angezeigt bekomme, dann
aber nur sehr schwach. die meiste Zeit aber gehts nicht.
Ich denke bei mir hat das was mit den Kondensatoren zu tun. Welche
Kapazitäten habt ihr an:
VB0+ & VB0-
VB1+ & VB1-
Vlcd
Erst hab ich folgende Kondensatoren benutzt:
VB0+ & VB0- 2,2uF
VB1+ & VB1- 2,2uF
Vlcd 0,33uF
So wie es eigentlich im Datenblatt des Controller steht.
Der Support von EA meinte aber, dass ich am Vlcd auch einen 2,2uF C hin
löten soll. Doch jetzt erscheint gar keine Spannung mehr am Vlcd und es
funktioniert auch nicht.
@Rainer: mit Reset meinst du den Software Reset oder? Weil der Hardware
RESET Pin liegt bei mir die ganze Zeit auf Vdd.
Wäre super wenn wir das hin bekommen würden... ;-)
Viele Grüße
Marc
Marc Price schrieb:> @Rainer: mit Reset meinst du den Software Reset oder? Weil der Hardware> RESET Pin liegt bei mir die ganze Zeit auf Vdd.
Nein, ich meine den Hardware-Reset Pin. Anfangs habe ich den auch nicht
benutzt und es hat nicht funktioniert. Erst seit dem ich den Reset Pin
mit einem Pin am Controller verbunden habe und diesen zu Beginn für 5ms
auf 0 (GND) und danach wieder auf 1 (Vdd) lege funktioniert das Display
korrekt. Aber das war eben ein DogL128 und kein DogXL. Keine Ahnung wie
es sich bei diesem Display verhält, aber ich würde es einfach mal
ausprobieren. ;)
Im Datenblatt zum Controller des DogL128, dem ST765R, steht auf Seite
40:
"When the power is turned on, the IC internal state becomes unstable,
and it is necessary to initialize it using the RES terminal."
Deshalb mache ich immer erst einen Hardware Reset zu Beginn. :)
Ciao,
Rainer
Genau das mit dem Hardware-Reset hatte ich bei meinem DogM128. Das geht
nicht, wenn man den nicht gezielt ansteuert. Deswegen habe ich oben
nachgefragt, ob das Display nach dem Einschalten lange genug im Reset
gehalten wird.
Grüße,
Peter
Am Reset liegts nicht, da das DogXL einen anderen Controller (uc1610)
besitzt. Habs auch probiert aber leider ohne Erfolg.
Hat keiner das DogXL bis jetzt zum laufen bekommen?
Ich bekomms ab und zu hin, aber nur wenn ich die Vlcd Spannung versuch
zu messen, also Pin 17 über Innenwiderstand vom Messgerät zu Masse. Aber
das funktioniert auch nicht immer.
Ich denke, dass das Problem bei der Erzeugung der Vlcd Spannung liegt,
da es wie gesagt nur sehr selten erzeugt wird und auch nur wenn ich den
2,2uF Kondensator mit dem Messgerät überbrücke.
Also wenn es bei einem läuft, dann bitte bescheid geben.
Hoffe das ich das bald hin bekomme!
Vg marc
Hallo Tom, sorry für die späte Rückmeldung, jetzt war ich im Ausland.
Also ich hab am Pin17 einen 0,22 uF Kondensator gelötet. Am Pin 18 & 21
und 19 & 20 einen 2,2uF Kondensator ABER die Polung der Kondensatoren
vertauscht, da ich Elko Kondensatoren verwende. Drauf gekommen bin ich,
da bei EA ein anderes LCD einen ähnlichen Controller verwendet und
dieser im Datenblatt anders herum gepolt ist. Ob es wirklich der Grund
war, weiß ich nicht ganz genau, da ich auch die Hardware dahinter
gewechselt habe! Den Bm0 und D6 Pin leg ich gleich auf GND und 3,3V je
nach konfiguration, hatte diese zwei zuerst im Programm angesteuert was
aber falsch war. Die einzigen Pin's die nicht auf Gnd oder 3,3V liegen
ist der Takt, der Mosi und der CD Pin. CS liegt von Anfang an auf Gnd.
Ich steuer das Display mit einen ARM lpc2368 Controller an, wenn du also
Informationen zur Initialisierung brauchst, gib mir kurz bescheid dann
post ich den code.
Viele Grüße
Marc
Hmm, bis auf dass ich den CS auch am µC hängen habe und dass ich Pin 17
einen 1µF hängen habe ist es bei mir genauso.
Kanst Du mal die Initsequenz posten, ich meine also nur die Kommandos
die Du über SPI schickst. Der Programmcode ist nicht nötig da ich einen
STM32 verwende
Gruß
TOm
Das müsste zur Initialisierung ersteinmal langen:
Testen kannst du das ganze mit der Funktion:
1
voidtestpic(void)
2
{
3
uint8LcdData[]={0xFF};
4
uint8p,c;
5
for(p=0;p<26;p++)// 26 Pages */
6
{
7
for(c=0;c<160;c++)// 160 Columns */
8
{
9
GLCD_SetPageAddress(0x00+p);
10
GLCD_SetColumnAdress(0x00+c);
11
GLCD_SendData(LcdData,1);
12
}
13
}
14
}
Ach und was auch noch ganz wichtig war ist, dass ich die Zeile
S0SPDR = *DATA; mit der Zeile while (!(S0SPSR & 0x80)); vertauscht habe,
da sich bei mir das Programm immer aufgehängt hat.
1
voidSPI_transfer(uint8*DATA,uint8i)
2
{
3
while(i)
4
{
5
S0SPDR=*DATA;/* Transmit data */
6
while(!(S0SPSR&0x80));
7
DATA++;/* Increment the pointer on the array*/
8
i--;/* Decrement the Byte counter */
9
}
10
while(!(S0SPSR&0x80));/* Wait until buffer is ready? */
11
}
So ich hoffe das hilft Dir fürs Erste. Wenn du's mal zum Laufen gebracht
hast kann ich Dir meine Funktion zum schreiben der Bilder geben.
Das Display könnte theoretisch 2bit greyscale anzeigen, leider hab ich
noch kein Programm gefunden mit dem ich die Bilder erstellen kann. Bei
meinen monoscale Bildern hat ich dann nämlich das Problem, dass 1 byte
nur 4 Pixel und nicht wie sonst meine 8 Pixel ansteuern. Außerdem
schreibt das Display ein Byte also 4 Pixel untereinander, das zweite
Byte rechts daneben(von links nach rechts) usw bis Spalte 160, dann
fängt es erst wieder bei Spalte 1 an in der 5ten Zeile an. Dadurch ist
die Positionierung der dynamischen Felder nicht mehr so trivial.
Alles in einem überzeugt mich der Controller nicht wirklich, leider gibt
es aber dazu nicht viele Alternativen.
Bei Fragen einfach fragen ;-)
Viele Grüße
Marc
Ok, mein Display war kaputt. Habe heute morgen ein neues bekommen und
das funktionierte auf Anhieb.
Aber vielen Dank für die vielen guten Tipps
Gruß
Tom
Hallo,
Ich habe mir auch ein DOGXL160 Display gekauft und versucht dieses mit
dem I2C-Bus oder SPI anzusteuern. Doch leider macht das Display keinen
Mux!
Unter diesem Link habe ich mein Problem genauer erklärt...
Beitrag "EA DOGXL160 an Atmega328 über I2C / twi Bus ansteuern!?"
- Welche Spannung messt ihr an VLCD, VB0 und VB1 nach der
initialisierung?
- Welche Kondensatortypen verwendet ihr?
- Macht ihr zwischen den gesendeten Bytes pausen?
- Was macht ihr mit dem Resetpin?
Bitte um Hilfe!
Mit besten Grüßen
Thomas
Marc Price schrieb:> Bei Fragen einfach fragen ;-)
Hallo,
ich benutze auch das DOGXL und habe eine generelle Frage:
Ich benutze die 3-wire 8-Bit SPi-Variante.
Wenn sich das Display nicht ändern soll, soll man dann trotzdem
NOP-Befehle (Befehl-Nr. 22) senden, oder kann man die Kommunikation
einfach einstellen und nimmt die Kommunikation dann wieder auf, wenn man
etwas senden möchte?
Gruß
Hi
>Wenn sich das Display nicht ändern soll, soll man dann trotzdem>NOP-Befehle (Befehl-Nr. 22) senden, oder kann man die Kommunikation>einfach einstellen und nimmt die Kommunikation dann wieder auf, wenn man>etwas senden möchte?
Lass es einfach in Ruhe.
MfG Spess
Hi Andreas,
du brauchst keine NOP Befehle senden.
Sobald du deine Informationen (Daten) in den RAM des LCD-Controller
schreibst, werden diese auf deinem Display angezeigt und zwar so lange
bis sie geändert werden oder du die Spannung weg nimmst.
Leider ist es bei diesem Controller nicht möglich die 4160 Bytes
(160x104x2 Pixel) komplett in den RAM zu übertragen.
Du musst diese Spalten- und Zeilenweise übertragen, so wie in dieser
funktion:
1
voidtestpic(void)
2
{
3
uint8LcdData[]={0xFF};
4
uint8p,c;
5
for(p=0;p<26;p++)// 26 Pages */
6
{
7
for(c=0;c<160;c++)// 160 Columns */
8
{
9
GLCD_SetPageAddress(0x00+p);
10
GLCD_SetColumnAdress(0x00+c);
11
GLCD_SendData(LcdData,1);
12
}
13
}
14
}
Das bedeutet 160 Spalten x 26 Spalten (1 Spalte hat 4 Pixel).
VG Marc
Danke, mit den Zeilen und Seiten, das habe ich schon gesehen.
Sehe ich das richtig, dass es keinen Befehl gibt für alle Pixel=off?
Und wenn ich alle Pixel per Befehl auf "on" stelle, kann ich eigentlich
nichts anderes mehr anzeigen lassen, bis ich dieses Bit wieder lösche?
Wie du siehst, bin ich noch in den ersten Schritten und spiele damit
noch ein wenig rum :)
Ja das ist richtig. Wenn du den Befehl 0xA5 sendest gehen alle Pixel an
und erst wenn du den Befehl 0xA4 sendest nimmt der Controller wieder die
Daten aus dem RAM.
VG
Marc Price schrieb:> Leider ist es bei diesem Controller nicht möglich die 4160 Bytes> (160x104x2 Pixel) komplett in den RAM zu übertragen.
Stimmt so nicht, da der Controller automatisch auf die nächste
Spalte/Zeile springt wenn er am rechten Displayrand angekommen ist.
Wichtig ist nur die Start Spalte/Zeile zu setzen, ab da kann man einfach
Daten reinschaufeln.
Mit den Window-Optionen kann man dass noch besser nutzen. Von hand Zeile
und Spalte jedesmal zu setzen läßt sich gr0ßteil vermeiden.
Gruß
Tom
Hallo,
ich habe jetzt entweder ein defektes Display oder einen Fehler in der
Kommunikation...
Und zwar benutze ich den Code von Marc, siehe weiter oben. Die Pixel der
linken Hälfte des Displays werden auch gesetzt, dann kommt ein
vertikaler Balken (Breite 32 Pixel), der ein undefinierbares Muster hat,
dann wieder ein Balken wo alle Pixel gesetzt werden, und am Ende nen
Balken, wo wieder die Pixel einen undefinierbaren Zustand haben (Breite
16 Pixel).
Hoffe ihr könnt euch was darunter vorstellen.
Meine Routinen zum Setzen der Zeilen und Spalten sieht folgendermaßen
aus:
1
voidLCD_set_column(charcolumn)
2
{
3
charcolumn_lowbyte;
4
charcolumn_highbyte;
5
charmask_lowbyte;
6
charmask_highbyte;
7
8
PORTB&=~(1<<PB1);//LCD-CD auf low (Befehl senden)
9
10
column_lowbyte=(column&0x0F);
11
column_highbyte=(column&0xF0);
12
13
mask_lowbyte=column_lowbyte;
14
mask_highbyte=(column_highbyte|(0x10));
15
16
SPDR=mask_lowbyte;
17
/* Wait for transmission complete */
18
while(!(SPSR&(1<<SPIF)))
19
;
20
21
SPDR=mask_highbyte;
22
/* Wait for transmission complete */
23
while(!(SPSR&(1<<SPIF)))
24
;
25
}
26
27
voidLCD_set_page(charpage)
28
{
29
charmask_page;
30
PORTB&=~(1<<PB1);//LCD-CD auf low (Befehl senden)
31
32
mask_page=(page|(0x60));
33
SPDR=mask_page;
34
/* Wait for transmission complete */
35
while(!(SPSR&(1<<SPIF)))
36
;
37
}
38
39
voidLCD_send_data(chardata)
40
{
41
PORTB|=(1<<PB1);//LCD-CD auf high (Daten senden)
42
SPDR=data;
43
/* Wait for transmission complete */
44
while(!(SPSR&(1<<SPIF)))
45
;
46
}
Nachtrag: Wenn ich den Befehl: alle Pixel auf on sende, gehen auch alle
Pixel an, daher denke ich, dass ich in der Kommunikation wohl nen Fehler
habe.
Noch eine Frage:
Sehe ich das richtig, dass man jedes Pixel in vier verschiedenen Stärken
ansteuern kann? Also:
0= Pixel aus
1= Pixel 33% an
2= Pixel 66% an
3= Pixel 100% an
Thomas Burkhart schrieb:> Stimmt so nicht, da der Controller automatisch auf die nächste> Spalte/Zeile springt wenn er am rechten Displayrand angekommen ist.
Echt? Also bei mir funktioniert's nur so...
Andreas Heil schrieb:> Hat eigentlich jemand eine gute Vorlage um Buchstaben anzeigen zu> lassen?
schau mal in diesen Thread:
Beitrag "Re: DOGXL an STM32"Andreas Heil schrieb:> Sehe ich das richtig, dass man jedes Pixel in vier verschiedenen Stärken> ansteuern kann?
Richtig. Aber die Werte glaub ich stimmen nicht ganz. Aber im Grunde
könntest du 2bit greyscale anzeigen.
VG Marc
Hi
>Sehe ich das richtig, dass man jedes Pixel in vier verschiedenen Stärken>ansteuern kann? Also:>0= Pixel aus>1= Pixel 33% an>2= Pixel 66% an>3= Pixel 100% an
Lt. Datenblatt (vom Display) nicht. Da gibt es nur 'on' und 'off'.
MfG Spess
spess53 schrieb:> Lt. Datenblatt (vom Display) nicht. Da gibt es nur 'on' und 'off'.>> MfG Spess
Ja, laut Datenblatt von EA, aber wenn Du das Datenblatt des Controllers
anschaust, dann funktionierts. Konnte ich beim Testebn Verifizieren.
Marc Price schrieb:> Thomas Burkhart schrieb:>> Stimmt so nicht, da der Controller automatisch auf die nächste>> Spalte/Zeile springt wenn er am rechten Displayrand angekommen ist.>> Echt? Also bei mir funktioniert's nur so...
Wie ist denn Deine Initsequenz? Funktioniert wirklich Problemlos, steht
auch so im Datenblatt. Du darfst natürlich den Wrap Arround nicht
abschalten.
Gruß
Tom
Marc Price schrieb:>> Hat eigentlich jemand eine gute Vorlage um Buchstaben anzeigen zu>> lassen?>> schau mal in diesen Thread:>> Beitrag "Re: DOGXL an STM32"
Das ist für die Größe von 7x5 Pixel. Ich würde gerne die großen
Buchstaben (16x7) benutzen.