Ach ja nochwas, das ganze läuft an nem ATmega32 mit 16MHz, im moment zum
testen allerdings nur mit 1MHZ weil ich dachte dass es vielleicht an den
Wartezyklen liegt ..
Wenn Du jetzt noch sagst, was genau "nicht so wirklich" funktioniert,
wäre das hilfreich...
BTW: Für den ATMega32 stimmt die Interrupt-Tabelle aber überhaupt nicht.
Der Mega32 hat mehr als 8 KB Flash und deshalb sind die Vektoren 32 Bit
lang, weil rjmp nur 8K ansprechen kann. Dürfte aber für Deine Anwendung
keine Schwierigkeiten machen. Am besten immer die Vektortabelle aus dem
entsprechenden Datenblatt übernehmen. Dann passiert sowas nicht.
beide, oder nur eine reihe und eine halbe o.ä!?
eigentlich benötigt man bei dem ersten delay doch mindestens 11ms,
oder!?
naja, ich würde einfach mal versuchen die wartezyklen noch größer zu
machen, größer schadet eigentlich nie, nur wenn sie zu kurz sind,gibts
probleme...
d.
Es ist ein 4 Zeilen Display, Zeile 1 und 3 zeigen schwarz, liegt das
wirklich nur an der zu hohen Kontrastspannung?
@Dennis
Zur Initialisierung sinds sogar 250ms die ich dem Display Zeit gebe, 50
mal in die 5ms Schleife.
Peter wrote:
> Es ist ein 4 Zeilen Display, Zeile 1 und 3 zeigen schwarz, liegt das> wirklich nur an der zu hohen Kontrastspannung?
Nein, das bedeutet, das dass Display immer noch nicht initialisiert ist.
> out PORTA, temp1 ;RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0> clr temp1 ;0 0 0 0 1 1 * *
Schau Dir mal den Kommentar zu diesen beiden Zeilen an. Abgesehen davon,
dass der Kommentar mit der zweiten Codezeile überhaupt nichts zu tun
hat, ist er zusätzlich noch irreführend. Sowas macht so ein Programm
fürchterlich schwer lesbar und eine Fehlersuche echt anstrengend.
Außerdem hast Du in Deinem Code z.B. mindestens drei verschiedene
Schreibweisen für PORTA. So ein Programm zu lesen macht echt keinen
Spaß! Da musst Du doch selbst irgendwann die Übersicht verlieren, oder
nicht? Schreib das Programm doch erst mal ins reine. Groß- und
Kleinschreibung sind zwar dem Assembler egal, aber dem menschliche Leser
fehlen dadurch durchaus Blickfangpunkte. Und wenn Du r16 und r17 schon
extra Namen gibst, warum verwendest Du sie dann nur ab und zu mal?
Wozu soll übrigens das "pop r16" und "pop r17" vor dem Sprung in die
Endlosschleife dienen? Ist zwar an dieser Stelle auch Wurscht, aber
nicht dass Du bei einer Erweiterung darüber stolperst. Wenn man popt,
ohne dass vorher was gepusht wurde, gibts u.U. Probleme mit dem Stack.
Noch ne Frage zur Sicherheit: Dein µC läuft aber, oder?
@Jack
Das ist doch nötig um dem LCD zu sagen dass die Daten auf den Leitungen
DB0-7 jetzt richtig anliegen, nicht? Steht doch in sämtlichen Tutorien
so.
@Johnny.m
Sorry für das Chaos, ich werds mal ins Reine fassen und das mit dem
Kommentar liegt daran dass er eigentlich über 4 Zeilen geht, sieht
vielleicht etwas komisch aus.
Der uC sollte laufen, hab einfach mal auf PORTA 0xAA ausgegeben und das
hat er brav erledigt.
> Wackeln lassen?
Du toggelst einen Pin nach dem anderen und schaust mit
einem Multimeter bzw. Ossi nach ob am LCD auch tatsächlich
sich am richtigen Pin was tut.
> Wie solls denn eigentlich nach Initialisierung aussehen?
Richtig. Die schwarzen Balken müssen verschwinden.
Jetzt hab ich versucht die Pins einzeln zu toggeln, allerdings jedes mal
neu geflasht, also für jeden Pin, weil ich wissen wollte ob er das auch
vernünftig macht. Allerdings gibts da auch Probleme, ich hab den uC
jetzt eigentlich so geflasht, dass PORTA PIN 2 Spg. führen sollte,
allerdings scheint immer noch das Programm von davor drinnen zu sein,
also führt PIN1 die Spg. Hab auch den ISP Programmer weggenommen und die
Versorgungsspannung kurz, alles nach dem Flashen. Hat aber nix geholfen.
Peter
@Peter
> Jetzt hab ich versucht die Pins einzeln zu toggeln, allerdings jedes mal> neu geflasht, also für jeden Pin, weil ich wissen wollte ob er das auch
Naja, so kann mans auch machen. Aber hast du nciht einen Taster an dem
Ding? ODer wenigstens ein freis Pin um einen Taster anzuschliessen? Da
kannst du nämlich per Taster die einzelnen Pins durchschalten und
wackeln lassen. Musst dann nur einmal flaschen (was immens Zeit spart)
und kannst vor allem dynamisch debuggen.
> also führt PIN1 die Spg. Hab auch den ISP Programmer weggenommen und die
Pin kurzgeschlossen? Sowas sollte man fix messen können.
MFG
Falk
Wieso steht eigentlich im Datenblatt was von 5*7 Dots und die beiden
schwarzen Balken vor der Initialisierung haben pro Zeichen 5*8 Dots?
Hab mir das Programm jetzt noch mal angesehen, die Leitungen überprüft
kann nichts finden, die schwarzen Balken verschwinden einfach nicht, die
Initialisierung klappt also nicht.
Peter
Mach mal was andere schon empfohlen haben. Schreib das Programm SAUBER!
Wahrscheinlich wird irgendwo mal r16/temp1 verwechselt und überschrieben
und dadurch ist dann der Inhalt im Eimer.
MfG
Falk
> Wieso steht eigentlich im Datenblatt was von 5*7 Dots und die beiden> schwarzen Balken vor der Initialisierung haben pro Zeichen 5*8 Dots?
Weil da die Cursorzeile mit drin ist.
> Mach mal was andere ...
Oder geh im AVR Studio in den Simulator und geh mal
mit Einzelschritten die Initialisierungssequenz durch.
Nach jedem Schritt die simulierten Port Pins beobachten
und überlegen ob das so sein kann bzw. so sein soll.
@Peter
> Was könnte man deiner Meinung nach denn noch ändern?
Nun, man könnte WIRKLICH Ordnung schaffen. Nicht aus reinem Selbstzweck,
sondern damit man Fehler schneller sieht. Siehe Anhang.
MfG
Falk
@Peter
> Also der JTAG Interface Enabled Haken ist auf jedenfall nicht gesetzt> wenn ich die Fuses auslese, das heißt doch deaktiviert oder?
Denke ich schon. Aber wenn dein Pin-Wackeltest mit ALLEN Pins
funktioniert, dann ist das nicht das Problem.
Erfolge? Wahrscheinlich nicht? Hmmm. Wie sieht denn dein Gesamtaufbau
aus? Mach mal ein Bild.
MfG
Falk
Schalte doch mal alle pins am portc auf H und auch mal auf L, und dann
kannste messen, ob jtag auch wirklich aus ist. Die Fuses sind bisschen
blöd zu handeln. Wenn du jtag nicht ausgeschaltet hast, ist es mit
sicherheit noch an.
Hab mich jetzt mal mit dem Multimeter drangesetzt und wenn ich die
Spannungsversorgung draufgebe, dann sind erstmal die Bits RW, RS, und
DB0-DB7 für ca. 9-10 Sekunden auf High. Wenn ich das LCD ausstecke und
direkt am uC messe, dann ist das nicht der Fall. Woran liegt das denn,
dass die Pins so lange alle auf H-Level liegen?
Peter
@Peter
>direkt am uC messe, dann ist das nicht der Fall. Woran liegt das denn,>dass die Pins so lange alle auf H-Level liegen?
Die Eingänge sind extrem hochohmig (100 MOhm ++). Die entladen sich nur
sehr langsam über dein Multimeter.
MfG
Falk
????
Wenn das LCD am uC hängt, dürfte gar nix fallen. Denn der uC treibt die
Pins, LOW oder HIGH. Und das sofort (us!) nach dem Reset. Was für
superbilligen Klingeldraht hast du denn da verwendet?
MFG
Falk
Also nochmal, wenn ich auf die Schaltung (uC und Display) Spannung gebe
und ich am Display messe, dann sind die Pins RW, RS, DB0-DB7 alle auf
High und das für ca. 9-10 Sekunden.
Wenn ich nun aber das Display wegnehme und dann Spg. wegnehme und wieder
draufgebe, dann sind alle Pegel wie sie sein sollten (am uC gemessen).
Also muss es wohl so sein, dass das Display irgendwie die H-Pegel
produziert. Nur leider werd ich aus der ganzen Geschichte nicht schlau.
Und ich muss sagen mich wundert auch nicht dass sich das Display nicht
initialisieren lässt bei dem was ich da mit dem Multimeter direkt nach
dem Einschalten messe.
@Peter
>Also nochmal, wenn ich auf die Schaltung (uC und Display) Spannung gebe>und ich am Display messe, dann sind die Pins RW, RS, DB0-DB7 alle auf>High und das für ca. 9-10 Sekunden.
Dann ist was faul. Das Programm setzt die alle auf LOW. Bist du sicher,
dass der uC läuft?
MfG
Falk
Wenn ich es mit einfachen Programmen probiere, also einfach nur ein Port
setzen, rücksetzen solche Geschichten dann funktioniert das wunderbar.
Nur eben bei diesem Initialisierungsprogramm macht passiert das was ich
oben beschrieben habe.
Ach ja hab noch vergessen zu sagen dass die Pins DB1 und DB2 nach den
10Sekunden auch noch High sind, aber das liegt wohl daran, dass das der
letzte Wert ist den ich in meiner Initialisierungsroutine auf PortA
ausgebe (0x06).
Mit 0x08 in der Initialisierung schaltet man Display, Cursor und
Blinking off. Von daher hab ich nichts gesehen und in Kombination mit
dem zu hohen Kontrast hatte ich nur die Balken gesehen.
;)
Eine Frage hätte ich noch, und zwar muss ich das LCD auf 1 Zeilig oder 2
Zeilig stellen wenn ich alle 4 Zeilen nutzen will?
Gibts vielleicht wo nen Thread oder ne Seite wo das schön beschrieben
ist wie das auch mit Zeile 2 und 4 klappt, also das Ansprechen. Hab
schon versucht die richtigen Adressen für Zeile 2 und 4 anzugeben,
bisher ohne Erfolg.
@Peter
>Eine Frage hätte ich noch, und zwar muss ich das LCD auf 1 Zeilig oder 2>Zeilig stellen wenn ich alle 4 Zeilen nutzen will?
2 zeilig.
>ist wie das auch mit Zeile 2 und 4 klappt, also das Ansprechen. Hab>schon versucht die richtigen Adressen für Zeile 2 und 4 anzugeben,>bisher ohne Erfolg.
1. Zeile 0x00
2. Zeile 0x40
3. Zeile 0x10
4. Zeile 0x50
MFG
Falk
Hast du nach der Character-Definition die Schreibposition
wieder in den sichtabren Bereich zurück gesetzt?
Ein Character zu definieren ist auch nichts anderes als
normale Zeichen ausgeben. Nur dass diese 'Zeichen' in einem
speziellen Speicher landen, von dem sie dann zum Zeichnen
benutzt werden.
Du brauchst auch nicht die Schreibposition erhöhen.
Mit der Ausgabe von 0x40 auf das Commandoregister
setzt du den Ausgabecursor in diesen speziellen Speicher-
bereich. Nachfolgende Ausgaben landen dann in diesem
Speicherbereich, genauso wie sie es auch bei der normalen
Ausgabe im sichtbaren Bereich machen. Der Cursor wird dabei
automatisch erhöht. D.h. du setzt mit dem 0x40 einfach den
Cursor um und gibst danach 8 Byte als Daten aus.
Danach aber nicht vergessen, den Ausgabecursor wieder in den
sichtbraen Bereich zurückzusetzen!
So, brauchte erstmal ein Käffchen um den Kopf wieder klar zu kriegen.
Natürlich muss ich vorher wieder mit 0x80 ins DD-Ram um dann mit 0x00
das eben erstellte Zeichen auszugeben ;) ..
Danke für den kleinen Tip
@Peter
>So, brauchte erstmal ein Käffchen um den Kopf wieder klar zu kriegen.
Du brauchst auch einen besseren Programmierstil. Schreib doch einfach zu
jedem Kommand als Kommentar was es macht. Gerade in Assembler ist das
äusserst nützlich, ja geradezu zwingend.
MFG
Falk
