Hallo,
ich habe folgende Situation:
An einem ATMEGA8 hängt am SPI (über ein Pegelwandler 5V <->3.3V) ein
Display DOGM-204-A (4*20 Zeichen). Die SPI-Kommunikation funktioniert
und eine Textausgabe erscheint auch korrekt. Was nicht funktioniert, ist
die Ausgabe von Steuerzeichen...
Ich habe die Kommunikation dabei mit einem Logic Analyzer kontrolliert
und kann dabei keinen offensichtlichen Fehler erkennen (siehe
beiliegenden Screenshot). Die Daten sind wie im Datenblatt des SD1803a
(Vers 2.0) formatiert (LSB zuerst).
Sync-/Ctrl-Byte:
- Sync "11111" (D0-D4)
- R/W = "0" (D5, Daten schreiben)
- RS = "0" (D6, Steuerzeichen übertragen)
- abschließendes "0" Bit (D7)
Das eigentliche Steuerzeichen (0x01,CLEAR DISPLAY) ist lt. Datenblatt
auf 2 Bytes aufgeteilt:
Lower Data:
- "1000" (D0-D3, unteres Nibble vom Steuerzeichen)
- "0000" (D4-D7, ist immer 0)
Upper Data:
- "0000" (D0-D3, oberes Nibble vom Steuerzeichen
- "0000" (D4-D7, ist immer 0)
Nach dem Abschicken dieses Kommandos erwarte ich eine gelöschte
Displayanzeige - aber es passierts schlicht nichts. Ein Test mit anderen
Steuerzeichen hat das gleiche Ergebnis ergeben - sie kommen "nicht
durch".
Das Display wurde zuvor mit dem im Datenblatt vorgegebenen INIT-String
initialisiert:
.EQU DSP_INIT_DSP_ON = 0b0000_1100 ; (0x0C) Display on, Cursor off, blink off
Die einzelnen Zeichen werden in einen Buffer geschrieben und dann per
Interruptroutine zeichenweise auf dem SPI ausgegeben.
Wie gesagt, die Textausgabe darüber funktioniert ohne weitere erkannbare
Fehler. Die Ausgabe der Steuerzeichen erfolgt über die gleiche Routine
(dann aber mit RS=0). Da die Daten über die SPI-Kommunikation scheinbar
richtig verschickt werden (Screenshot), glaube ich auch nicht, dass der
Fehler an der SPI-Routine liegt.
Habe ich etwas übersehen ?
Was könnte die Ursache sein ?
Welche Ideen für Lösungsansätze gibt's ?
Besten Dank für die Hilfe,
Anton
Das stimmt so nicht. Ein ClearDisplay ist 01h als Command (RS=0)
gesendet.
9.1 Clear Display RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0 0 0 0 0 0 0 0
0 0 1 Clear all the display data by writing "20H" (space code) to all
DDRAM address, and set DDRAM address to "00H" into AC (address counter).
Return cursor to the original status, namely, bring the cursor to the
left edge on first line of the display. Make entry mode increment (I/D =
"1").
Crazy H. schrieb:> Das stimmt so nicht.
Doch, das stimmt so:
7.10.2 Serial interface (IM2=L, IM1 = H)
[...]
Write Operation (R/W = 0)
After start byte is transferred from MPU to SSD1803A, 8-bit data is
transferred which is divided into 2 bytes, each byte has 4 bit's real
data and 4 bit's partition token data. For example, if real data is
"10110001" (D0 - D7), then serially transferred data becomes "1011 0000
0001 0000" where 2nd and 4th 4 bits must be "0000" for safe transfer.
Hallo,
ich hab ein wenig mit dem INIT-String gespielt. Diese Zeichen werden
nach dem Reset aus einem Buffer über die SPI-Schnittstelle ans Display
übertragen und erstaunlicherweise werden alle Steuerzeichen angenommen
und ausgeführt. Ich habe einige Zusätzliche angehängt und ausprobiert,
wie "double height", etc. und es geht, aber eben nur während der
Init-Phase.
Danach muss aber irgend etwas eigenartiges passieren. Wird erneut eine
Steuerzeichensequenz per SPI übertragen, also die 5 Sync-Bits ("1"),
RS="0" und RW="0" und z. B. ein CLEAR DISPLAY, gehen die offensichtlich
ins "Nirvana". Das Display scheint nun irgendwie für Steuerzeichen
blockiert zu sein! (die reine Textausgabe funktioniert).
Mir gehen langsam die Ideen aus und das Datenblatt gibt auch nicht viel
mehr Infos aus.
Hat jemand Ansatzpunkte oder Ideen ?
Hilfe dringend nötig!
P. S.: Ich weiß nicht, ob's relevant ist, aber nach einem Display-Reset
ist der Zeichensatz aus dem ROM-C aktiviert - ich habe ROM-A erwartet...
Viele Grüße,
Anton
Hallo,
einen Schaltplan(-auszug) habe ich angehängt. Das Wesentliche ist im
oberen Bereich abgebildet.
Da der ATMega mit 5V läuft, das Display aber nur mit 3,3V, liegt
dazwischen der 74LVX125 als 5V toleranter Pegelwandler. Damit ist dann
auch gleichzeitig das fehlende Save-Select-Signal (/SS2) verknüpft. Da
die Ausgänge des LVX125 einen Tristate-Zustand einnehmen, wenn /SS2
nicht aktiviert ist, liegt ausgangsseitig in der SCL und MOSI-Leitung
noch jeweils ein Pullup, um klare Signalverhältnisse zu haben. Die
Display-Beschaltung entspricht ansonsten dem Applikationsbeispiel von EA
für die serielle Betriebsart.
Im Programm habe ich noch
- eine Busy-Abfrage vor jeder schreibenden Ausgabe zum Display ergänzt,
um sicher zu gehen, dass das Display auch empfangsbereit ist;
- auch mal das Restprogramm "abgehängt", um nur mit dem Dispaly nach der
Initialisierung zu "spielen"
... alles ohne Erfolg.
Es ist nach wie vor so, dass das Display nur nach dem Einschalten
Steuerzeichen verarbeitet (die Initialisierung). Wenn dieser Vorgang
aber abgeschlossen ist, funktionieren zwar noch reine Textausgaben, aber
keine weiteren Steuerzeichen, wie CLEAR DISPLAY, HOME, ...
Irgendwie scheint sich das Display dann in einen sonderbaren "Modus"
verfangen zu haben ...
Ich vermute(te), dass die Initialisierung fehlerhaft ist, aber sie
entspricht im Wesentlichen dem EA-Beispiel. Auch konnte ich die
Kommunikation mit dem LA 1:1 auf dem SPI verfolgen (auf der 5V und 3.3V
Seite). Elektrisch scheint es zu passen.
Könnte das Display einen "Knacks" haben ?
Viele Grüße,
Anton
Kannst du mal den Reset des Displays fest auf +3.3V hängen?
Kannst den MCP mal raus nehmen? Oder ist das SMD?
Und dann noch den /SS2 fest auf 0.
Dann sollte der SPI mal "richtig" da sein.
Vielleicht ist es keine gute Idee, den MISO in die Luft zu hängen, was
du mit dem /SS2 machst.
Ich dachte eigentlich, daß ich alle DOG-Displays durch hab, aber das
fehlt mir tatsächlich noch. Ansonsten hab ich alle: 162, 163, S102, M,
XL, .....
Der 74LVX125 ist ein SMD, den kriege ich leider nicht so einfach raus.
Aber tatsächlich, der Pullup am DSP_RESET (nach dem Pegelwandler auf
Display-Seite) fehlte, den habe ich mittlerweile ergänzt, so dass die
Reset-Leitung displayseitig über den Pullup auf 3,3V liegt, wenn SS2 auf
HIGH liegt, also inaktiv ist.
Das SS2-Signal kriege ich leider nicht ohne weiteres abgekoppelt (wg.
SMD)
und somit auch nicht fest auf LOW.
Den MCP habe ich rausgenommen... der sollte nicht stören.
Ich habe mir die Ansteuersignale auch noch mal mit einem Oszi auf
Display-Seite angeschaut. Es liegen stabile Pegel an und die Flanken
sehen auch relativ ansehlich aus (das Über-/Unterschwingen an den
Flanken ist wohl dem "legeren" Messaufbau geschuldet).
Man sieht im ersten Bild das Sync-Byte und im zweiten Bild das untere
Datenbyte vom CLEAR DISPLAY (oben jeweils SCLK, unten MOSI).
Die Merkwürdigkeiten auf der Softwareseite hören nicht auf:
Durch die ergänzte Busy-Abfrage wird der DDRAM-Adress-Zähler um zwei
Positionen weiter gesetzt (???). Der angezeigte Text wird also um zwei
Positionen nach rechts versetzt dargestellt. Das kenne ich so vom
HD44780 auch nicht. Der SSD1803a erweist sich bisher als recht sonderbar
und ziemlich zickig.
Das Ausgangsprobelm besteht nach wie vor...
Viele Grüße,
Anton
Willst du mal versuchen, das Display via I2C zu beglücken? Mußt halt nen
Soft-I2C nehmen.
Gibts bei SPI auch die längeren Pausen bei Clear, ClearHome und (glaub)
SetDDRAM-Adress?
Kannst du das Display raus nehmen (gesockelt?) und mal ganz einfach an
einem 3.3V-uC direkt und ohne Pegelwandler und Zusatzperipherie in
Betrieb nehmen?
Die Busy-Abfrage würde ich aber schon einbauen.
Hatte damals mal eine Library für das DOGM204 geschrieben, allerdings
für STM32.
Ich fand das Datenblatt an vielen Stellen etwas konfus bzw. auch
wiedersprüchlich.
Aber es hatte per SPI perfekt funktioniert. Anbei mal der Code, die paar
HAL-Funktionen für den STM32 sind eigentlich selbsterklärend falls Du es
auf AVR portieren willst.
Evtl. für Dich interessant inder lcd1803.c:
I2C müsste ich dann mit einem Steckbrett testen. Da ich aber nur das
eine Display habe, müsste ich es auch umbauen bzw. die Beschaltung
ändern.
Generelles Problem dabei wird sein, dass der Flash-Speicher schon
ziemlich belegt ist. Ich würde wahrscheinlich die zusätzlichen
Initialisierungen und Routinen nicht mehr unterbringen. Den SPI brauche
ich zwingend für den MCP...
Ich glaube auch nicht, dass es an Ausführungszeiten liegt. Zwischen den
div. Aufrufen liegen (lt. LA) einige ms (der ATMega läuft "nur" mit
1MHz).
Es ist mir ein Rätsel, warum die Initialisierung und die Textausgabe
funktioniert, und die spätere Anwendung von Steuercodes dann nicht mehr
geht. Ich hab schon gelesen, dass der SSD1803a in 4Bit Modus so seine
Macken hat. Vielleicht ist das im SPI-Modus auch so ? Ich habe bisher
dazu im Netz allerdings noch keine Hinweise dazu gefunden.
Angeblich gibt es Bibliotheken von EA. Die muss ich mir mal besorgen und
analysieren. Vielleicht ergibt sich daraus noch etwas
aufschlussreiches..
Viele Grüße,
Anton
Anton Hermann S. schrieb:> Es ist mir ein Rätsel, warum die Initialisierung und die Textausgabe> funktioniert, und die spätere Anwendung von Steuercodes dann nicht mehr> geht. Ich hab schon gelesen, dass der SSD1803a in 4Bit Modus so seine> Macken hat. Vielleicht ist das im SPI-Modus auch so ? Ich habe bisher> dazu im Netz allerdings noch keine Hinweise dazu gefunden.
Nur als kurzes Geblubber, ohne das von Dir Gezeigte konkret
durchgespielt oder durchdacht zu haben: Als ich mit dem DOGM204 zu tun
hatte, hat das eine Zeit gedauert, bis ich das Setzen und Löschen des
RE-Bits verstanden hatte. Das ist ein extended Register-Bit, was u.a.
die Verarbeitung von Steuercodes beeinflußt.
Das mit dem "RE-Zustand" hatte ich auch schon im Verdacht. Im Prinzip
ist es ein Umschaltmechanismus, so dass mit gesetztem RE-Bit auf einen
alternativen Befehlssatz umschaltet wird.
Allerdings ist das RE_Bit nicht bei allen Kommandos relevant.
Insbesondere beim CLEAR DISPLAY Befehl (0x01) ist der RE-Zustand lt.
Datenblatt "don't care". D. h. für speziell diesen Befehl ist dessen
Zustand egal.
Ich kann die Wirkung dieses Befehls nur beobachten, wenn er im Zuge der
Initialisierungssequenz nach dem Hochlaufen des Systems ausgeführt wird.
Wird er später erneut aufgerufen, kann ich die Wirkung nicht mehr sehen
- Der zuvor ausgegebene Text bleibt stehen.
Viele Grüße,
Anton
Hi,
ich weiß nicht, ob das etwas mit dem Problem zu tun hat, aber an U04
scheinen am Puffer für das MISO-Signal die Pins 11 und 13 vertauscht zu
sein. Laut Datenblatt ist Pin 11 der Ausgang und Pin 13 ist /OE, aber im
Schaltplan ist es umgekehrt.
Gruß,
Bernd
Hallo,
Die vertauschten Pin-Bezeichnungen war einer der ersten Fehler, der mir
aufgefallen ist. Die Hardware ist schon korrigiert, Pin 13 ist /OE und
Pin 11 der Ausgang.
Ich muss die fehlerhafte Symboldatei durch eine korrigierte ersetzen und
diesen Fehler noch im Plan korrigieren.
Nach dem Durchschauen der Code-Beispiele (Danke an adrock) ist mir
aufgefallen, dass dort die SPI-Schnittstelle mit CPOL=1 und CPHA=1
initialisiert ist, in meinem Programm aber mit CPOL=0 und CPHA=0.
Die SPI wird falsch initialisiert. Das war der Fehler !
Nach dem Ändern der 2 Bit im SPCR kommen die Steuerzeichen durch und das
Display macht nun auch mit den Steuerzeichen das was es soll :-)
Vielen Dank an alle für die super Unterstützung und die Tipps zur
Fehlersuche !
Viele Grüße,
Anton
Hallo,
das ist das Eigenartige...
Die Parameter waren schon von Anfang an falsch. Genau dieser Umstand hat
mich ja im Irrglauben gelassen, dass bez. der Kommunikation
softwareseitig alles passt.
Bezüglich der Parametrierung der SPI-Schnittstelle ist das Datenblatt
leider nicht sehr ergiebig. Man muss im Datenblatt schon sehr ganu auf
das Timing-Diagramm (Fig. 7-11) schauen, um die SPI-Parameter abzulesen.
Im Text habe ich keinen Hinweis darauf gefunden. Darum ist es mir das
auch nicht aufgefallen.
Ich habe momentan keine Erklärung dafür, warum sich die falschen
SPI-Parameter erst nach der Initialisierung und nur bei den
Steuerzeichen auswirkten. Dazu kenne ich die Interna des SSD1803a
einfach nicht genau genug. Ich vermute, dass bei der Behandung der
Textausgabe und der Steuerzeichen intern andere Timings vorliegen
(Durchtakten der Daten in das jeweilige Empfangsregister). Ggf. gelten
auch in der Initialisierungsphase andere ("offenere") Timings, um
anfangs über die verschieden möglichen Schnittstellen ansprechbar zu
sein. Die an anderen Stellen erwähnten Besonderheiten bei der
Iitialisierung im 4Bit-Betrieb deuten ggf. darauf hin...
Vielleicht kennt sich jemand noch besser mit dem SSD1803a aus ?
Es würde mich auch interessieren, wie sich dieses eigenartige Verhalten
erklären lässt.
Viele Grüße,
Anton
Hallo Anton,
also ohne den ganzen Thread im Detail gelesen zu haben - ich habe auch
lange gekämpft um das kleine DOGS 104 mit dem 1803A anzusteuern. Im
Prinzip gehts ganz gut wenn man das orginale Datenblatt des Controllers
befolgt. Ist aber alles andere als leicht zu durchschauen. Und unbedingt
die Reset Timings beachten, sonst geht gar nichts. Soll heißen reset auf
low ziehen und danach mindestens 50ms warten bevor man Kommandos oder
Daten sendet.
Und was ich noch herausgefunden habe ist, dass man die 3 Byte Sequenzen
JEWEILS mit CS "einpacken" muss, sonst ist das Ergebnis wirklicher
Zufall.
Problem waren am Anfang auch die SPI Clockphase Settings die mich
Stunden gekostet hatten.
Hier zumindest meine Sequenz zur Ansteuerung:
1
...
2
voiddogs104_init(void)
3
{
4
dogs104_send_cmd(0x3A);// 8 bit data length
5
dogs104_send_cmd(0x09);// 4 line display
6
dogs104_send_cmd(0x06);// 06 bottom view. 05 top view
7
dogs104_send_cmd(0x1E);// BS1=1
8
dogs104_send_cmd(0x39);// 8bit data length extension
9
dogs104_send_cmd(0x1B);//
10
dogs104_send_cmd(0x6E);// Divider on set value
11
dogs104_send_cmd(0x56);// booster on set contrast
12
dogs104_send_cmd(0x7A);// set contrast
13
dogs104_send_cmd(0x38);// 8 bit extension
14
dogs104_send_cmd(0x0C);// display on | cursor off | blink off
15
dogs104_send_cmd(0x01);// clear display
16
dogs104_setROM(ROMA);// Select ROM A
17
}
18
voiddogs104_send_cmd(uint8_tbyte){
19
dogs_cs_high;
20
dogs_cs_low;// set chip select for the display cs pin
21
delay_us(10);
22
SPI_I2S_SendData(SPI1,0x1F);// Command mode is 00011111 = 0x1F
23
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_TXE)==RESET);// 1 when empty register
24
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_BSY));// 0 when transmission is finished
25
SPI_I2S_SendData(SPI1,(byte)&0x0F);
26
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_TXE)==RESET);// 1 when empty register
27
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_BSY));// 0 when transmission is finished
28
SPI_I2S_SendData(SPI1,(byte)>>4&0x0F);
29
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_TXE)==RESET);// 1 when empty register
30
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_BSY));// 0 when transmission is finished
31
delay_us(10);
32
dogs_cs_high;
33
delay_us(10);
34
}
35
36
37
voiddogs104_send_data(uint8_tbyte){
38
dogs_cs_low;// set chip select for the display cs pin
39
delay_us(10);
40
SPI_I2S_SendData(SPI1,0x5F);// Data mode is 01011111 = 0x5F
41
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_TXE)==RESET);// 1 when empty register
42
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_BSY));// 0 when transmission is finished
43
SPI_I2S_SendData(SPI1,(byte)&0x0F);
44
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_TXE)==RESET);// 1 when empty register
45
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_BSY));// 0 when transmission is finished
46
SPI_I2S_SendData(SPI1,(byte)>>4&0x0F);
47
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_TXE)==RESET);// 1 when empty register
48
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_BSY));// 0 when transmission is finished
49
delay_us(10);
50
dogs_cs_high;// set chip select for the display cs pin
51
delay_us(10);
52
}
53
54
voiddogs104_setROM(uint8_trom)
55
{
56
dogs104_send_cmd(0x3A);
57
dogs104_send_cmd(0x72);
58
dogs104_send_data(rom);
59
dogs104_send_cmd(0x38);
60
}
61
62
voiddogs104_display_string(char*data){
63
inti;
64
65
dogs_cs_high;
66
dogs_cs_low;
67
delay_us(10);
68
while(*data){
69
SPI_I2S_SendData(SPI1,0x5F);
70
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_TXE)==RESET);// 1 when empty register
71
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_BSY));// 0 when transmission is finished
72
SPI_I2S_SendData(SPI1,*data&0x0F);
73
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_TXE)==RESET);// 1 when empty register
74
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_BSY));// 0 when transmission is finished
75
SPI_I2S_SendData(SPI1,(*data>>4)&0x0F);
76
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_TXE)==RESET);// 1 when empty register
77
while(SPI_I2S_GetFlagStatus(SPI1,SPI_I2S_FLAG_BSY));// 0 when transmission is finished
Moin,
@Wolfram funktioniert der Rom Wechsel bei dir?
Wolfram L. schrieb:> void dogs104_setROM (uint8_t rom)> {> dogs104_send_cmd(0x3A);> dogs104_send_cmd(0x72);> dogs104_send_data(rom);> dogs104_send_cmd(0x38);> }
Habe auch noch ein Beitrag dazu gefunden aber finde das "zweite"
Funktion Set irgendwie nicht.
Beitrag "Re: Display DOGM-204A/SSD1803A mit I2C - ROM Auswahl"
Viele Grüße
Saskia