EA DOGM und ARM7

Es handelt sich um einen Softwarefehler in Zeile 183.

Welche Softwarefehler meinen Sie ?

Anbei Programmcode...

Danke ich probier´s aus...

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.

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.

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!

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

und hier noch der Quellecode...

vielen danke für Ihre Hilfe!

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.

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

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

>vor jedem Versuch Spannungslos damit es sich resetet!

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

@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

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

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 ?

>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

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!

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

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

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.