Forum: Mikrocontroller und Digitale Elektronik DOGM-204 Problem mit Steuercodes


von Anton Hermann S. (antonhermann)


Angehängte Dateien:

Lesenswert?

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:
1
.EQU  DSP_INIT_FCTSET1   = 0b0011_1010 ; (0x3A) Function-Set, 8 Bit Data-Mode, RE=1, IS=0
2
.EQU  DSP_INIT_FCTEXT    = 0b0000_1001 ; (0x09) RE1: Font width 5 Dot, 4 Line Display     
3
.EQU  DSP_INIT_ENTRYMD   = 0b0000_0101 ; (0x05) Entry-Mode = Bottom view
4
.EQU  DSP_INIT_BIAS      = 0b0001_1110 ; (0x1E) Bias BS1=1
5
.EQU  DSP_INIT_FCTSET2   = 0b0011_1001 ; (0x39) Function Set, 8 Bit, RE=0, Rev=1  
6
.EQU  DSP_INIT_OSC       = 0b0001_1011 ; (0x1B) Osc=540 (Def), BS0=1: Bias 1/6  
7
.EQU  DSP_INIT_FOLLOW    = 0b0110_1110 ; (0x6E) Follower control: Divider on
8
.EQU  DSP_INIT_POWERCRTL = 0b0101_0111 ; (0x57) Booster on, Kontrast C5 und C4              
9
.EQU  DSP_INIT_CONTRAST  = 0b0111_0010 ; (0x72) Kontrast C3:C0
10
.EQU  DSP_INIT_FCTSET3   = 0b0011_1000 ; (0x38) Function Set, 8 Bit, RE=0, IS=0
11
.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

von Crazy Harry (crazy_h)


Lesenswert?

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

von Bernd B. (bbrand)


Lesenswert?

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.

von Crazy Harry (crazy_h)


Lesenswert?

Ok ich lerne gerne was und so hab ich das noch nie gesehen.

von Anton Hermann S. (antonhermann)


Lesenswert?

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

von Crazy Harry (crazy_h)


Lesenswert?

Gibts einen Schaltplan, wie das Display angeschlossen ist?

von Anton Hermann S. (antonhermann)


Angehängte Dateien:

Lesenswert?

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

von Crazy Harry (crazy_h)


Lesenswert?

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

: Bearbeitet durch User
von Anton Hermann S. (antonhermann)


Angehängte Dateien:

Lesenswert?

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

von Crazy Harry (crazy_h)


Lesenswert?

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?

: Bearbeitet durch User
von Markus M. (adrock)


Angehängte Dateien:

Lesenswert?

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:
1
static void LCD1803_CMD(SPI_HandleTypeDef *spi, uint8_t inst) {
2
    LCD1803_WriteI(spi, inst);          // send command
3
    while(LCD1803_ReadS(spi)&LCD1803_FLAG_BUSY);     // wait until BF cleared
4
}
5
6
static void LCD1803_WriteI(SPI_HandleTypeDef *spi, uint8_t inst) {
7
    uint8_t tx[3];
8
9
    tx[0] = LCD1803_STARTBYTE;
10
    tx[1] = inst&0x0f;
11
    tx[2] = inst>>4;
12
13
    HAL_SPI_Transmit(spi, tx, 3, HAL_MAX_DELAY);
14
}
15
16
static uint8_t LCD1803_ReadS(SPI_HandleTypeDef *spi) {
17
    uint8_t tx = LCD1803_STARTBYTE|LCD1803_FLAG_RW, rx;
18
19
    HAL_SPI_Transmit(spi, &tx, 1, HAL_MAX_DELAY);
20
21
    tx = 0;
22
    HAL_SPIEx_FlushRxFifo(spi);
23
    HAL_SPI_TransmitReceive(spi, &tx, &rx, 1, HAL_MAX_DELAY);
24
25
    return rx;
26
}
27
28
static void LCD1803_WriteB(SPI_HandleTypeDef *spi, uint8_t b) {
29
    uint8_t tx[3];
30
31
    tx[0] = LCD1803_STARTBYTE|LCD1803_FLAG_RS;
32
    tx[1] = b&0x0f;
33
    tx[2] = b>>4;
34
35
    HAL_SPI_Transmit(spi, tx, 3, HAL_MAX_DELAY);
36
}
37
38
static uint8_t LCD1803_ReadB(SPI_HandleTypeDef *spi) {
39
    uint8_t b = LCD1803_STARTBYTE|LCD1803_FLAG_RS|LCD1803_FLAG_RW;
40
    uint8_t zero = 0;
41
42
    HAL_SPI_Transmit(spi, &b, 1, HAL_MAX_DELAY);
43
    HAL_SPIEx_FlushRxFifo(spi);
44
    HAL_SPI_TransmitReceive(spi, &zero, &b, 1, HAL_MAX_DELAY);
45
46
    return b;
47
}

LCD1803_CMD() ist die Funktion zum Senden von Befehlen. Dort wird 
grundsätzlich das Busy-Flag abgefragt.

Gruß
Markus

von Anton Hermann S. (antonhermann)


Lesenswert?

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

von J. -. (Gast)


Lesenswert?

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.

von Anton Hermann S. (antonhermann)


Lesenswert?

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

von Bernd B. (bbrand)


Lesenswert?

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

: Bearbeitet durch User
von Anton Hermann S. (antonhermann)


Lesenswert?

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

von Crazy Harry (crazy_h)


Lesenswert?

Und wieso ging es dann anfangs?

von Anton Hermann S. (antonhermann)


Lesenswert?

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

von Wolfram L. (amazon)


Lesenswert?

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
void dogs104_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
void dogs104_send_cmd(uint8_t byte) {
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
void dogs104_send_data(uint8_t byte) {
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
void dogs104_setROM (uint8_t rom)
55
{
56
  dogs104_send_cmd(0x3A);
57
  dogs104_send_cmd(0x72);
58
  dogs104_send_data(rom);
59
  dogs104_send_cmd(0x38);
60
}
61
62
void dogs104_display_string(char *data){
63
  int i;
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
78
    i++;
79
    data++;
80
  }
81
  delay_us(10);
82
  dogs_cs_high;
83
}
84
85
void dogs104_cursor(uint8_t row, uint8_t column){
86
  uint8_t line_offset;
87
    switch (row) {
88
      case 1:  line_offset = 0x00; break;  // Line 1
89
      case 2:  line_offset = 0x20; break;  // LIne 2
90
      case 3:  line_offset = 0x40; break;  // Line 3
91
      case 4:  line_offset = 0x60; break;  // Line 4
92
      default: line_offset = 0x60;         // line>3
93
    };
94
    dogs104_send_cmd( 0x80+line_offset + column );
95
96
}

von Saskia E. (Gast)


Lesenswert?

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

von Amazon (Gast)


Lesenswert?


Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.