Hallo Bin gerade am C-Programmieren. Wollte nur wissen ob man einen ATmega64 im Code selbst Reseten kann mit einem Befehl.. Geht das? Danke für eure Antwort mfg Almir
Gast
#2651351
Ja, man lässt den Watchdog zuschnappen
Gast
#2651367
Hi, Almir, > Bin gerade am C-Programmieren. Wollte nur wissen ob man einen ATmega64 > im Code selbst Reseten kann mit einem Befehl.. Geht das? asm("jmp 0x00000")funktioniert - aber nur im Prinzip. Weil die Power On Sequence nicht ausgeführt wird, welche alle Timer, IOs und Register zurücksetzt. Nach diesem Sprung weiß die CPU nicht mehr, in welchem Zustand sich der Prozessor gerade befindet. Dafür hat sie keine Zeit verloren. Diesen Sprung habe ich in meinem Bootloader mit voller Absicht, denn genau da soll die USART weiter funktionieren ohne Datenverlust. Sonst meide ich so was wie die Pest und bevorzuge, den Watchdog auf minimale Wartezeit zu stellen und auszulösen. Ciao Wolfgang Horn
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.
Gast
#2651490
wie hast du es gelöst ? - Watchdog zuschnappen lassen ? - Portpin löst an der Resetleitung einen Reset aus ? - IRQ-Irrfahrt - PC an die 0000 springen ?
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
Gast
#2651944
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ß. Sicherlich kommt Mißbrauch von Softresets vor, aber zu behaupten, dass ein Softreset grundsätzlich den Kontrollverlust des Programmieres dokumentiert, ist natürlich Quatsch.
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.
Gast
#2652179
H.joachim Seifert schrieb: > 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. Genau das haben die Programmierer bei Microsoft auch lange Jahre gemacht. Ganz getreu dem Motto: Keine Ahnung, wies System grad aussieht. Egal, machen wir einen Neustart. Vollständige Initialisierer sind in jedem Fall so einer Sintflut-Programmierung vorzuziehen.
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.
Gast
#2653675
H.joachim Seifert schrieb: > 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. Das Problem fängt an, wenn am Prozessor vielleicht mehr als nur ein Display dranhängt. Wenn beim Setzen von neuen Parametern nicht sämtliche Peripherie neustartet. Wenn die Anwendung komplexer wird und der Neustart länger dauert...
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)
Gast
#2654811
H.joachim Seifert schrieb: > 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) Und siehst du, genau das ist dann Schwachsinn. Einerseits möchtest du einen Hard-Reset erzwingen, weil der nämlich die Register definiert vorbelegt. Andererseits verlässt du dich dann aber doch nicht drauf. Warum also die Initialisiererei nicht ordentlich verpacken (wenig Aufwand, du hast sie ja ohnehin schon ausprogrammiert) und jede Menge Flexibilität gewinnen? Ich möchte als Benutzer halt nicht jedes Mal wieder ne zehnteilige Grundstellungsfahrt durchfahren, wenn ich irgendeinen Parameter verändert habe.