Dann geht es im Programm mit Laden einer Konstante in ein Register
weiter, also ähnlich wie es hier shcon alles war, nur auf andere Ports.
Jedoch geht das Programm immer nur bis hier hin, was ich reinkopiert
hab. Dann geht es wieder von vorne Los. Ich nehme an, das der µc ein
Reset durchführt, aber woher kommt der?
Kann jemand helfen?
mfg
ja, Endlosschleife habe ich, aber bis dort kommt er ja gar nicht. Er
kommt ja vermutlich nur bis hier hin, wo ich das Programm hier
hereinkopeirt habe, weil dann fangen die LEDs wieder von ovrn an zu
leuchten.
Das mit dem Label und Befehl stimmt eigentlich, ändert aj aber auch
nichts an der Funktion, würde ich jedenfalls meinen.
Push habe ich eigentlich auch nirgendwo verwendet.
Kann das sein, das das irgendwie mit der Watchdog oder so zusammenhängt,
ich wüsste da aber auch nicht weiter.
Moin..
Initialisierst du denn den Rest der Hardware ?
Stellst du sicher, das kein Interrupt ausgelöst wird,
der dir dann irgendwo ins Hauptprogramm springt, das ja
mitten in der "Zeropage" liegt ?
(@init dürfte ja 0x0001 sein, wenn ich das richtig sehe)
Gruss,
Timmey
> ich habe einen Ausschnitt aus meinem Programm:
In dem Ausschnitt ist kein Fehler, der zu einem Reset führt. Wenn es
einen Reset gibt, kommt der aus einem anderen Programmteil.
Zwischen main8 und main9 ist auch noch ein Fehler (Initialiserung von
schieb2). Ist aber unerheblich bzgl. der vermuteten Reset-Problematik.
Wie stabil ist die Spannungsversorgung? Kann es bei so vielen Ausgaben
sein, dass du in einen Brownout Zustand kommst?
>.org 0x0100>vor dem label init damit du sicher aus den interruptvektoren raus bist.
Ist kein SEI drin - sollte keinen Unterschied machen.
Er kann in seinem Falle sogar problemlos das
1
rjmp init
weglassen, wenn er explizit auf das Aktivieren der Interrupts verzichten
will.
Der Watchdog kann eigentlich kein Problem sein, da er nicht
eingeschaltet wird ;)
Ist das Problem im Simulator nachvollziehbar?
Kannst du den Code so weit reduzieren, dass das Problem nicht mehr
auftritt?
Noch ein paar Tipps/Anregungen unabhängig vom Problem:
Deine Dokumentation ist nicht wirklich hifreich beim Lesen des
Programms. Ein Kommentar wie "initialisieren" sagt irgendwie nichts aus.
Gönn dir ruhig ein paar Leerzeilen, wenn ein neuer Abschnitt mit einer
neuen Aufgabe anfängt und spendier einen Kommentar, der die Aufgabe des
Blocks beschreibt.
Wenn du Schleifen erstellst empfehle ich diese wie in einer Hochsprache
einzurücken:
1
; warte 1999998 Zyklen:
2
warten:
3
ldi R23, $04
4
WGLOOP0:
5
ldi R24, $C5
6
WGLOOP1:
7
ldi R25, $EA
8
WGLOOP2:
9
dec R25
10
brne WGLOOP2
11
dec R24
12
brne WGLOOP1
13
dec R23
14
brne WGLOOP0
15
16
ldi R23, $01
17
WGLOOP:
18
dec R23
19
brne WGLOOP
20
ret
Noch ein paar Kleinigkeiten:
1
LDI R22, 0b11111111 ;initialisieren
2
; besser:
3
SER R22
4
5
LDI aus, 0b00000000
6
; besser:
7
CLR aus
Wenn du schon Aliase für die Register verwendest (was gut ist!),
solltest du das konsequenter Weise auch für alle anderen Register
machen. Das vermeidet, dass du reservierte Register versehentlich mit
anderen Aufgaben belegst und erhöht die Lesbarkeit deutlich.
Gruß
Kai
Ok, Vielen rießen Dank für eure super guten Hilfen. Ich muss mich aber
bei euch entschuldigen, es lag am µc, der war irgendwie hin. Ich habe
einen neuen verwendet, da ging es, ich weis zwar nicht warum der andere
µc immer von vorn angefangen hat, das ist schon komisch. Also mit dem
neuen funktioniert es, also noch einmal vielen Dank für die vielen Tips,
denn die nützen mir auf jeden Fall von der Übersicht her zumindest auch
was für die nächsten Programme was.
mfg
Bleibt die Frage, warum der AVR verreckt ist.
Stefan "stefb" B. wrote:
> Wie stabil ist die Spannungsversorgung? Kann es bei so vielen Ausgaben> sein, dass du in einen Brownout Zustand kommst?
Welchen Strom zieht dein AVR bei den vielen OUTPUT-Aktionen insgesamt
(zeitweise arbeiten 4 PORTs als Treiber) und an den einzelnen Ports?
Vielleicht überschreitest du die max. elektrischen Daten des AVRs und
himmelst so nach einiger Zeit jeden AVR. Wird der AVR bei längerem
Betrieb in dem Gerät warm?
Untersuche mal die Fuses auf dem vermeintlich verreckten Controller, ob
die sich von denen des neuen in irgendeiner Weise unterscheiden.
Vielleicht liegt da der Hund begraben.
Also Fuses ist kein Unterschied. Warm wird der AVR (der neue) eigentlich
auch nicht wo wirklich.
Insgesamt ziehen die LEDs maximal 2A, aber zwischen µc und den LEDs ist
ja noch eine Darlingotn-Scghaltung, also dürfte da auch nicht unbedingt
was passieren.
