Reset des Atmega64 im Code ausführen

Und dann gibts noch die Möglichkeit, wenn man einen Portpin frei hat, 
diesen mit dem Reset zu verbinden...

Hallo zusammen!

Danke für eure Antworten!! Das Problem wäre somit gelöst :-)

Gruss Almir

Almir D. schrieb:
> Wollte nur wissen ob man einen ATmega64
> im Code selbst Reseten kann mit einem Befehl..

Im Prinzip geht das.
Es zeigt allerdings, daß der Programmierer total die Kontrolle über sein 
eigenes Programm verloren hat und nun zum allerletzten Rettungsring 
greifen muß.

Besser, das Schiff bleibt schwimmen und geht vom Kapitän (Programmierer) 
kontrolliert auf den nächsten Kurs.


Peter

Och, ich schaff das problemlos, jedesmal wenn ich 'n Interrupt aufruf 
ohne Interruptroutine. :)

Wobei, es gibt IMO durchaus Fälle wo die einfachste und sogar stabilste 
Lösung ein Reset ist, beispielsweise nach dem Aufspielen neuer Firmware. 
Damit erreicht man sehr zuverlässig einen stabilen und vorhersehbaren 
Ausgangszustand.

Hugin schrieb:
> wie hast du es gelöst ?

Ich habe jetzt vorläufig den Reset an einen Pin des uP`s gehängt. Hat 
mich interessiert, ob das irgendwie sonst eine Beinflussung ergibt. 
Klappt prima! Ich werde es jedoch mit dem Watchdog machen, weil das auf 
meiner gelayouteten Platine nicht so schön aussieht :)
Muss nur noch im Datenblatt nachschauen wie ich es machen muss

Peter Dannegger schrieb:
> Im Prinzip geht das.
> Es zeigt allerdings, daß der Programmierer total die Kontrolle über sein
> eigenes Programm verloren hat und nun zum allerletzten Rettungsring
> greifen muß.

Das Problem bei mir ist das es mit einem USB-Stecker verbunden ist. Wenn 
ich den USB-Stecker ziehe wird die SLEEP Leitung des USB-Treibers LOW. 
Diese Leitung führt direkt zum Prozessor. Sobald dies geschieht blinkt 
eine LED auf meiner Platine.
Nun steckt man das USB-Kabel wieder ein und es gibt Signalverzerrungen. 
Diese lösen bei mir einen Interrupt aus...

ISR(USART0_RX_vect)
{
  receive_UART();            //sobald ein Zeichen empfangen wird, 
receive_UART ausführen
}

Nach dem Einstecken des USB-Steckers macht mein Programm was es will...

Das ist aber nicht direkt ein Problem des USB.
Sobald man bei einer UART-Verbindung das Kabel steckt oder einen 
Teilnehmer einschaltet, kann es einen Low-Pegel geben, der als Startbit 
interpretiert wird.
Daher sollte auf der UART immer ein Protokoll laufen, welches Daten, die 
nicht dem Protokoll entsprechen, einfach ignoriert.
Z.B. man hat ein bestimmtes Zeichen oder Zeichensequenz für den Beginn 
eines Frame definiert und alles davor wird weggeschmissen.


Peter

Finde ich auch.
Habe auch so eine Anwendung. Parameterdaten werden während des Betriebs 
geändert (seriell ins EEprom), anschliessend Neustart mit den neuen 
Werten.
Klatsch, Reset, fertig.

Tja, und genau das macht der MC bei einem Reset.
Hardware wird in einen definierten Ausgangszustand gebracht, benötigte 
Teile initialisiert, Daten geladen und los gehts.
Seh nicht, wo da ein Problem sein soll.

Mich wundert, dass es überhaupt noch MC-Anwendungen gibt, die ohne 
Notstromversorgung daherkommen, um noch schnell ein komplettes image auf 
einen externen Datenträger schreiben zu können, um dann nach Rückkehr 
der Hauptversorgung den letzten gültigen Zustand direkt wiederherstellen 
zu können. Diese Entwicklung ist komplett an mir vorbeigegangen...
Meine Systeme müssen mit gelegentlichem Ausschalten klarkommen, 
üblicherweise also mit einem power-on-reset.
Ich seh keinen prinzipiellen Unterschied zwischen einem erzwungenen 
externen reset und einem gewollten Neustart. In beiden Fällen läuft die 
gleiche Sequenz ab.
jmp 0 ist ne andere Geschichte (aber selbst das würde bei mir i.a. 
funktionieren, ich geh nicht davon aus, dass sich die Peripherie im 
Zustand nach reset befindet, sondern schreibe das explizit rein. Ab und 
zu muss dieser "Rundumschlag" allerdings der stets begrenzten 
Flash-Grösse weichen)