Reset per Software

hatten wir vor kurzem hier, such mal danach.
Aber im Prinzip hast du die beste Lösung schon selbst gefunden -
watchdog. Was ist dir daran nicht elegant genug? Bzw. was wäre an einer
anderen Lösung eleganter?

Moin moin..

Wenn noch nen I/O Pin frei ist,
bau dir doch den sich selbst reset-enden
Prozessor per I/O-Leitung mit Inverter
gegen \Reset .. aber das ist ja dann kein
"Software-Reset" ..

Gruss,
Tim

Die Timer laufen schon, bloß Du kriegst keinen Interrupt mehr.

Du hast nämlich kein RETI gemacht und deshalb denkt die 8051-CPU, sie
ist immer noch im Interrupthandler.

Und wenn Dein externer Interrupt die hohe Priorität hat, können sogar
noch 2 Interrupts am Laufen sein. D.h. dann must Du 2 RETIs machen um
alle Interrupts zu beenden.


Peter

@ Peter:
Das hört sich logisch an. Wenn ich so schnell drüber nachdenke, macht
doch ein RETI nichts anderes, als ein RET-Befehl und setzt gleichzeitig
noch das EAL-Bit oder nicht? Weil ich im Programmstart dieses Bit auch
wieder setze, muss ich doch dann kein RETI machen - also nach meinen
Überlegungen. Offenbar sind die falsch, aber was macht RETI denn noch?
Weil mir fällt grad nicht wirklich ein Weg ein, vor dem Reset 2 mal
RETI auszuführen, weil er doch dann 2 mal springt und zwar an ein mir
zu dem Zeitpunkt unbekanntes Ziel. Oder sollte ich auf den Stack 2
Adressen legen, die dann angesprungen werden? Ist ne Idee, oder?
Was mich aber wie gesagt interessiert, um das auch wirklich zu
verstehen: Was macht RETI genau, dass es ohne dies solche Problemen
gibt?

Tabi

Der 8051 hat eine Hardware-Prioritätslogik, d.h. er merkt sich zu jeder
Prioritätsstufe, ob ein Interrupt gerade abgearbeitet wird.
Das EA-Bit wird nirgends beeinflußt, sonst könnte ja die
Prioritätslogik nicht funktionieren.

Die 2 RETis gehen z.B. so:

...
      call leave_interrupts
      call leave_interrupts
...


leave_interrupts:
      reti


Peter

Ah ja! Alles klar. Ich komme also um die RETI's nicht herum, wenn ich
springen will. Ist ne gute Lösung so :-)

Dankeschön!!!

Tabi