Hallo zusammen, ich habe bei einer Anwendung die Herausforderung den Controller neu zu starten, aber ohne Reset. Nun überlege ich gerade welchen Nebeneffekte durch ein JMP 0x0000 auftreten können und was man sonst noch zu beachten hat. Controler: AtMega32 Toolchain: IAR Eingefallen ist mir bis jetzt: * Register haben nicht den Resetwert * Vor dem JMP alle IRQs sperren * RAM müsste durch die Init von IAR richtig initialisiert sein (Segement NEAR_I und NEAR_Z) Hat jemand diesbezüglich schon Erfahrung gemacht oder Ideen?
Kalli L. schrieb: > Controler: AtMega32 > Toolchain: IAR > > Eingefallen ist mir bis jetzt: > > * Register haben nicht den Resetwert > * Vor dem JMP alle IRQs sperren Was in einem gewissen Sinne aufs gleiche rausläuft. Was wird noch über Register geregelt (eigentlichg gibt es ja für alles irgendwo ein Bit in einem Register) UART abschalten ADC abschalten Timer abschalten und rücksetzen (inkl. der Prescaler Stufe) ... Geh einfach mal das Datenblatt durch und dort einfach mal im Inhaltsverzeichnis die Kapitel-Überschriften. Das sollte schon mal eine ganz gute Übersicht geben, worüber man sich genauer Gedanken machen sollte. Denk auch drann, dass Programme oft so geschrieben sind, dass eine gewisse Default-Reset Konfiguration vorausgesetzt wird. Wenn wir schreiben TCCR1B |= ( 1 << CS11 ); dann steckt da die implizite Annahme drinnen, dass CS12 und CS10 vom Reset her noch auf 0 sind. > * RAM müsste durch die Init von IAR richtig initialisiert sein (Segement > NEAR_I und NEAR_Z) Alles was irgendwie vom Compiler beim Hochfahren erledigt wird, findet da wie dort genau gleich statt. D.h. um diese Dinge musst du dir keine Sorgen machen. Interessant sind nur die Dinge, die der µC in Hardware macht, ehe dann nach einem richtigen Reset der erste Befehl in Angriff genommen wird.
Kalli L. schrieb: > ich habe bei einer Anwendung die Herausforderung den Controller neu zu > starten, aber ohne Reset. Weshalb ohne Reset? Der klassische Weg geht über einen vorsätzlich verhungerten Watchdog.
Es schadet nichts, wenn man eine saubere Init schreibt, die aus einem beliebigen Zustand in einen bekannten Zustand setzen kann. D.h. alle IO-Register so zu setzen, wie sie benötigt werden, ohne vorauszusetzen, daß sie vorher ihren Resetzustand hatten. Dann reicht der "Jump 0" völlig. Peter
> Weshalb ohne Reset? Der klassische Weg geht über einen vorsätzlich > verhungerten Watchdog. Der Controller hält sich über einen Portpin selbst eine Betriebspannung aktiv. Nach einem Reset im Batteriebetrieb bleibt er aus, da die Portpins kurzzeitig nicht mehr treiben.
Die Frage ist, ob der TE das gleiche Verhalten implementieren will, als ob ein richtiger Reset stattgefunden hätte, oder ob er nur "von vorn" anfangen will, ohne dass sämtliche Register zurückgesetzt werden. Im 1. Fall würde ich auch auf die WD-Methode von A.K. tendieren.
Was ist eigentlich an folgender Annahme falsch? Nach dem "normalen" Reset sind die Register (natürlich) im Reset-Zustand. Im nächsten Schritt muss ich auf jeden Fall alle wichtigen Register setzen. Bei einem Sprung zur Adresse 0 bricht doch normalerweise nicht ein Registerchaos aus. Wenn ich während der erneuten Initialisierung Befehle wie AND und OR benutze und nicht ADD bzw. SUB müsste doch ein Problemloser Neustart möglich sein. Da ich doch nur die Bits setze, an denen ich auch beim Original Reset herumgefummelt habe.
amateur schrieb: > Was ist eigentlich an folgender Annahme falsch? > Nach dem "normalen" Reset sind die Register (natürlich) im > Reset-Zustand. > Im nächsten Schritt muss ich auf jeden Fall alle wichtigen Register > setzen. > Bei einem Sprung zur Adresse 0 bricht doch normalerweise nicht ein > Registerchaos aus. Das kommt drauf an, aus welchem Grund man den 'Reset' machen will/muss. Wenn die Aufgabe lautet einen Bootloader zu schreiben, der das neu eingebrannte Programm durch einen 'Reset' starten soll, dann sollte das dann auch wirklich für das zu startende Programm von einem richtigen Reset nicht zu unterscheiden sein.
Ein JMP 0 verändert keine Register (ausser PC natürlich). Wenn vorher alles richtig initialisiert war brauchst Du nichts neu zu initialisieren.
>brauchst Du nichts neu zu initialisieren
Stimmt, aber der "Normale" Programmfluss nach einem JMP 0 durchläuft den
typischerweise am Programmanfang liegenden Initialisierungszweig.
Also ich schalte hierzu auch immer den Watchdog an und lasse den AVR 'abstürzen' (Durch Endlosschleife). Finde das bei den AVRs ein Manko. Es sollte möglich sein, ein Reset anders auszulösen z.B. durch ein Reset-Register. Mehrere Bits, die bestimmen, was alles resettet werden soll.
Peter da negger hats bereits gesagt: ne saubere Init-Routine und alles passt mit JMP 0.
In der Init sollten auch alle Variablen durch brauchbare Grundwerte besetzt werden.
Meine restlichen Bedenken drehen sich um den Punkt, ob die Konfigurationsregister im Betrieb auch durch die Hardware verändert werden könnten und ob dieses einen sauberen Neustart beeinflußt. Aber da muss man jetzt wohl mal aller Register raussuchen und sich durchs Datenblatt wühlen.
Es gibt da ein Problembit, das UDRE. Wenn man neu initialisiert, bevor das letzte Senden beendet wurde, bleibt es gelöscht und kann nicht per SW gesetzt werden. Ist aber nur beim Senden ohne Interrupt wichtig. In dem Fall kann man vor dem SW-Reset warten, bis es gesetzt ist. Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.