EA DOGM und ARM7

[Ka_deu (Gast)]

Gute Tag,

     Ich habe ein LCD EA DOGM162L-A mit einem ADuc7020 geschaltet und 
schein leider am Display nichts zu bewegen. Ich habe alle Pins getestet 
und es kommt bei High 3.3V. Anbei die Schaltung angehängt.

Vielen Dank für Ihre Hilfe.

[Martin (Gast)]

Es handelt sich um einen Softwarefehler in Zeile 183.

[Ka_deu (Gast)]

Welche Softwarefehler meinen Sie ?

[Andreas S. (andreas) (Admin)]

Das sollte ein dezenter Hinweis darauf sein, dass man ohne den 
Programmcode zu sehen nichts zu dem Problem sagen kann.

[Ka_deu (Gast)]

Anbei Programmcode...

[Kai F. (k-ozz)]

Ausgänge werden so auf high gesetzt: GP1SET = LCD_RS;
Also nicht '|=', sonder nur '='.
Rückgesetzt (auf low) werden sie so: GP1CLR = LCD_RS;
Also nicht das betreffende Bit in GP1DAT löschen, sondern das 
betreffende Bit in GP1CLR setzen!

Vielleicht solltest du dir einfach ein paar Makros schaffen:

#define lcd_set_rs() GP1SET = (1 << 23)
#define lcd_clear_rs() GP1CLR = (1 << 23)
#define lcd_set_e() GP1SET = (1 << 22)
#define lcd_clear_e() GP1CLR = (1 << 22)
#define lcd_set_rw() GP1SET = (1 << 20)
#define lcd_clear_rw() GP1CLR = (1 << 20)

außerdem muß die lcd_send_bits geändert werden (die clear_data kann 
damit entfallen)

void lcd_send_bits(int data)
{
    data &= 0x0F;
    GP1CLR = (0x0F << 16);
    GP1SET = (data << 16);
}

Probier's mal aus!

[Ka_deu (Gast)]

Danke ich probier´s aus...

[Ka_deu (Gast)]

Ich hab die makros benutzt, aber leider ohne Erfolg. Ich habe 2 LCD wo 
ich gerade ausprobiert habe. Das prb ich weiss nicht wie kann ich 
testen, ob die LCDs wirklich Daten bekommen, anders gesagt ob sie nicht 
kapput sind.

[Was anderes (Gast)]

Auf dem P1.x sind doch die SPI Signale, schließe das DOG Modul doch im 
SPI Mode an, dann werden nur noch 4 Leitungen für die Verbindung 
benötigt.

Das Schreiben der Bits/Clk macht dann der SPI, nur noch latchen, warten 
100us dann darf das nächste Byte geschrieben werden.

Ist doch viel einfacher, als das Display über 4-Bit-Bus anzusteuern.

Das Timing ist wichtig, z.B. der CLS Befehl benötigt wirklich die 
angegebenen ms vom Datenblatt.

[Jansus (Gast)]

Die EADOG-M Displays sind sehr empfindlich was die Initialisierung 
angeht. Außerdem haben sie die nervige Eigenart, dass sie erst nach 
erfolgreicher Initialisierung etwas anzeigen. Mache Dir also keine 
Sorgen, die Dinger gehen meistens und können auch ein bisschen was ab. 
Suche mal nach Code für die Initialisierung (gibt's hier im Forum), 
passe sie auf Deinen Controller an und freue Dich über das Ergebnis!

[Jaouad (Gast)]

Ich habe nochmal mit spi geschaltet, und scheint immer noch nichts am 
display. anbei die schaltung

[Jaouad (Gast)]

und hier noch der Quellecode...

vielen danke für Ihre Hilfe!

[Thilo M. (Gast)]

Wenn du ein Display mit 3.3V benutzt musst du (bin nicht sicher) die 
interne Ladepumpe zuschalten. Guck' besser nochmal genau ins Datenblatt.

Auch das Zuschalten der Betriebsspannung ist kritisch, lieber die 
Initialisierung erst nach 1s starten, wenn die Versorgung des Moduls 
stabil ist.

[Was Anderes (Gast)]

Hallo,

Anbei mein C-Code, allerdings für einen ARM-Prozessor LPC23xx.

Initialisierung:
LCD_TaskInit(0);

Zyklischer Aufruf aus dem Main-Loop:
LCD_Task();

Im Interrupt wird die CS Leitung automatisch gelöscht.

Mit dabei sind vollständige Routinen:
LCD_Char(char Dat);
LCD_CLS(unsigned char Lines);
LCD_Locate(int X, int Y);
LCD_Text(char * sText);
LCD_Int(int iVal);
LCD_NibbleHex(unsigned char x);
LCD_ByteToHex(unsigned char cVal);
LCD_IntToHex(int iVal);
LCD_LongToHex(unsigned long iVal);
(Die LCD_Float Routine habe ich noch nicht gebraucht, daher auch nicht 
hinzuerfunden.)

Nur noch die IO's und den verwendetetn Timer anpassen und fertig. Meine 
Routinen warten nicht bis die Daten im LCD sind, sondern buffern diese 
im RAM. Erst der LCD_Task() macht die Ausgabe, getriggert über Timer. 
Damit bleibt die Applikation nicht wegen der LCD Ausgabe stehen. 
Schließlich hat der Prozessor ja noch eine Hauptaufgabe und die ist 
meistens nicht das LCD zu beschreiben.
Alle LCD Befehle die länger als 100us benötigen dürfen nicht verwendet 
werden, daher habe ich das LCD_CLS() anders gemacht.

@Jaouad: Wieso steuerst Du eigentlich das CS Signal nicht an (LOW) wenn 
Du Daten/Steuerwörter übertragen willst und nimmst es dann wieder weg 
(HI)?

Gruß MM

[Was Anderes (Gast)]

Wenn man experimentiert mit dem Display und schrott rein schreibt, dann 
ist die Funktion des Displays kaputt. Am besten man macht es vor jedem 
Versuch Spannungslos damit es sich resetet!
Sonst passiert es, dass man einen guten Quellcode hat aber im Display 
dennoch nichts zu sehen ist.
Gruß MM

[Thilo M. (Gast)]

>vor jedem Versuch Spannungslos damit es sich resetet!

Dafür hat das Ding einen Reset-Pin. ;)

[Robert Teufel (Gast)]

@Thilo
da gibt es haeufig gravierende Unterschiede zwischen einem "warm reset" 
und einem "power-on reset". Auch noch zu beachten, die Kondensatoren auf 
einem Board verhindern oft einen power-on reset, wenn man ihnen nicht 
genug Zeit gibt sich zu entladen.

Just my 2 cents, Robert

[Jaouad (Gast)]

Ja, vielen dank für die Tipps, ich mache jetzt die Änderungen und hoffe 
dass es funktioniert...

[Jaouad (Gast)]

ich habe gerade bemerkt:

*(seite 55) Serial Clock Period : tSCYC  min = 200ns => 5Mhz
*(seite 66) Im Aduc7020 kann ich max "SPI speed in MHz = 3.482Mhz" 
erreichen.

Kann es daran liegen, dass es nicht funktioniert ?

[Robert Teufel (Gast)]

>Kann es daran liegen, dass es nicht funktioniert ?
SPI speed, nicht wirklich.
Das hier "*(seite 55) Serial Clock Period : tSCYC  min = 200ns => 5Mhz" 
ist etwas ungluecklich formuliert aber bedeutet ebenfalls 
Maximalgeschwindigkeit. Alsoe die Maximalgeschwindigkeit des Micros ist 
lansamer als die der Peripherie, dann sollte schon mal alles in Ordnung 
sein.

Robert

[Was Anderes (Gast)]

Mach doch den SPI so langsam wie möglich, mann muss sowiso 100us warten 
bis man das nächste Byte schicken darf, so wie in meinem Codebeispiel.
Dadurch wird das ganze auch unempfindlicher wegen sonstigere Störungen.

An der Geschwindigkeit solltest Du erst anfangen zu Optimieren wenn es 
überhaupt mal funktioniert!

[Jaouad (Gast)]

Die Linke für das DOG Module :

http://www.lcd-module.de/eng/pdf/zubehoer/st7036.pdf

für ADuc7020:

http://www.analog.com/UploadedFiles/Data_Sheets/ADUC7019_7020_7021_7022_7024_7025_7026_7027_7028.pdf

[Jaouad (Gast)]

Ich habe die Wartezeiten mit einem Timer genauer beschrieben. Auch noch 
das CS-Signal betrachtet...Code im Anhang.

[piepvogel (Gast)]

man muss das timing bei diesen EADOG dingern genau einhalten. ich hatte 
mal das problem, dass 3 wollten und ein viertes nicht, weil ich irgendwo 
zu schnell war. also genau die timing-diagramme im datenblatt beachten, 
dann klappt das schon.