Forum: Mikrocontroller und Digitale Elektronik ATMega: Reboot per Software auslösen?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Zempel (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Hi,

gibt es beim ATMega eine Möglichkeit, einen Reboot per Software 
auszulösen, bei dem die MCU (fast) wie bei einem Hardware-Reset mit dem 
Bootloader startet?

Danke!

von Klugscheisser (Gast)


Bewertung
0 lesenswert
nicht lesenswert
1
asm("jmp 0x0000");

fiele mir da ein... könnte gehen

von CK (Gast)


Bewertung
6 lesenswert
nicht lesenswert
Der einzig saubere Weg ist ein Watchdog-Reset zu forcieren.
Nur dann werden die Hardware-Register neu initialisiert.

von Klugscheisser (Gast)


Bewertung
0 lesenswert
nicht lesenswert
da hast Du Recht... ist wohl noch zu früh heute ;-)

von Zempel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klugscheisser schrieb:
> da hast Du Recht... ist wohl noch zu früh heute ;-)

Zumal die Startadresse ja nicht unbedingt immer 0x0000 ist - oder? Ich 
dachte, das hängt davon ab, wie die Fuses programmiert sind...

von Sascha W. (sascha-w)


Bewertung
0 lesenswert
nicht lesenswert
Zempel schrieb:
> Klugscheisser schrieb:
>> da hast Du Recht... ist wohl noch zu früh heute ;-)
>
> Zumal die Startadresse ja nicht unbedingt immer 0x0000 ist - oder? Ich
> dachte, das hängt davon ab, wie die Fuses programmiert sind...
genau, mit dem jmp 0 wird der Bootloader mit Sicherheit nie gestartet.
Du könntest auch einen Portpin mit Reset verbinden :)
Aber Watchdog ist schon die beste Lösung. Wenn du natürlich aus der 
Applikation nur in den Bootloader willst kannst du auch dessen Adresse 
anspringen (die ist dann allerdings vom Typ und den Fuses abhängig).

Sascha

von Zempel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sascha W. schrieb:
> Du könntest auch einen Portpin mit Reset verbinden :)

Sowas ähnliches habe ich schon...für eine Testapplikation würde ich den 
Reset aber eben auch gerne in Software auslösen können.

von Watchdog (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Habe ich immer per Watchdog gemacht. Einfach und zuverlässig. Spricht 
irgendetwas dagegen?

von g457 (Gast)


Bewertung
2 lesenswert
nicht lesenswert
> Du könntest auch einen Portpin mit Reset verbinden :)

Der daraus resultierende Resetpuls ist nicht notwendigerweise lang 
genug, das Resetergebnis ist dann undefniert. Für ein defniertes 
Ergebnis braucht es einen hinreichend langen Restpuls, z.B. von einem 
Resetgenerator.

Der Hardwarewatchdog (die Brown-out-Einheit übrigens ebenso) bringt 
definiertes Verhalten ohne extra Beschaltung mit, ist also die 
wesentlich bessere Option.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Sascha W. schrieb:
> Du könntest auch einen Portpin mit Reset verbinden :)

Das dürfte mächtig in die Hose gehen.
Das CPU-Reset wird erst mit der nächsten Taktflanke erzeugt, die Ports 
gehen aber asynchron in Tristate.
Du brauchst also noch einen Monoflop.

von Hanns-Jürgen M. (yogy)


Bewertung
2 lesenswert
nicht lesenswert
Ich "mache" so etwas über den Watchdogtimer, der "normalerweise" zyklich 
in der Hauptprogrammschleife zurückgesetzt wird.  Mittels eines Befehls 
über die serielle Schnittstelle lasse ich das Programm eine 
Endlosschleiße ohne Watchdogbedienung ausführen. Und: Voila

BTW: Leider nutzen viele Prgrammierer den Watchdog nicht. Für Tests mag 
das okay sein, aber nie für Produktivsysteme.

Beitrag #5531821 wurde von einem Moderator gelöscht.
von Naja (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Das dürfte mächtig in die Hose gehen.

Sicher?
1
Ausgang nach Low
2
-> Reset nach Low
3
-> Ausgang nach Tristate
4
-> Reset nach High (wegen Pullup)
5
-> Reset-Ende
6
-> Programmstart

Ich habe das grade ausprobiert. Ich sehe kein Problem. Der Reset scheint 
normal ausgeführt zu werden.

von g457 (Gast)


Bewertung
2 lesenswert
nicht lesenswert
> Ich sehe kein Problem.

Beispielsweise der m328pa will grob 2.5µs Resetpuls sehen. Wie schaffst 
Du das in Deinem Aufbau? Zur Verdeutlichung: wenn der mit 16MHz läuft 
sind das 40 Takte!

> Der Reset scheint normal ausgeführt zu werden.

Joa, iss aber wider der Speck, und damit ist das Ergebnis undefiniert. 
Wer sonst nix zu tun hat verstößt so oft (und unnötig) wie möglich gegen 
die Herstellervorgaben, weil der Hersteller hat ja eh keine Ahnung.

von c-hater (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
CK schrieb:

> Der einzig saubere Weg ist ein Watchdog-Reset zu forcieren.

Nein. Der einzig saubere Weg ist: Der Bootloader räumt sauber auf und 
stellt so den Hardware-Reset-Zustand her, bevor er die Applikation 
anspringt. Er kann das tun, denn sein (hoffentlich kompetenter) 
Programmierer weiss sehr genau, was er daran verändert hat und wie man 
das wieder zurücksetzt...

Der Weg über den Watchdog-Reset ist schmutzig. Denn bei vielen Devices 
stellt er den Zustand der Hardware eben nicht vollständig wieder her. 
Man sieht das an dem Gefrickel, was z.B. diese Arduidioten betreiben 
müssen, um die Folgen zu bekämpfen, eben sukzessive Watchdog-Resets...

Die einzige akzeptable Ausrede für die Verwendung des Watchdog-Reset 
durch den Bootloader zum Zwecke des Aufrufs des Hauptprogramms ist: 
extreme Knappheit im Codespace. Denn das saubere Aufräumen durch den 
Bootloader kostet doch meist einige Bytes mehr als das Aktivieren des 
Watchdog-Reset.

So sieht's aus.

von Naja (Gast)


Bewertung
0 lesenswert
nicht lesenswert
g457 schrieb:
> Beispielsweise der m328pa will grob 2.5µs Resetpuls sehen. Wie schaffst
> Du das in Deinem Aufbau? Zur Verdeutlichung: wenn der mit 16MHz läuft
> sind das 40 Takte!

Das geht automatisch. Die Leitung bleibt solange auf Low bis der 
Controller den Reset schließlich macht. Wenn dazu 123µs nötig sind, dann 
dauert das halt 123µs.
(Es war übrigens ein ATTiny85 der auf 1MHz RC lief.)

g457 schrieb:
> Joa, iss aber wider der Speck, und damit ist das Ergebnis undefiniert.
> Wer sonst nix zu tun hat verstößt so oft (und unnötig) wie möglich gegen
> die Herstellervorgaben, weil der Hersteller hat ja eh keine Ahnung.

Das sind viele Behauptungen und Unterstellungen.
Im privaten und unkritischen Fällen hätte ich keine Bedenken das so zu 
machen. Ich kann mir aber keinen Fall vorstellen, in dem das Sinn macht.
Per Watchdog ist alles besser: Ich verliere keinen Pin, es gibt nichts 
zu verdrahten und diese Methode ist 100%ig zuverlässig.

von H.Joachim S. (crazyhorse)


Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> CK schrieb:
>
>> Der einzig saubere Weg ist ein Watchdog-Reset zu forcieren.
>
> Nein. Der einzig saubere Weg ist: Der Bootloader räumt sauber auf und
> stellt so den Hardware-Reset-Zustand her, bevor er die Applikation
> anspringt. Er kann das tun, denn sein (hoffentlich kompetenter)
> Programmierer weiss sehr genau, was er daran verändert hat und wie man
> das wieder zurücksetzt...
>
> Der Weg über den Watchdog-Reset ist schmutzig. Denn bei vielen Devices
> stellt er den Zustand der Hardware eben nicht vollständig wieder her.
> Man sieht das an dem Gefrickel, was z.B. diese Arduidioten betreiben
> müssen, um die Folgen zu bekämpfen, eben sukzessive Watchdog-Resets...
>
> Die einzige akzeptable Ausrede für die Verwendung des Watchdog-Reset
> durch den Bootloader zum Zwecke des Aufrufs des Hauptprogramms ist:
> extreme Knappheit im Codespace. Denn das saubere Aufräumen durch den
> Bootloader kostet doch meist einige Bytes mehr als das Aktivieren des
> Watchdog-Reset.
>
> So sieht's aus.

Da haste ja wieder mal deinen Schmutzkübel geleert....
Mir ist noch in keinem Datenblatt ein Unterschied zwischen POR, externer 
Reset und watchdog-reset aufgefallen (bis auf die paar Bits, die genau 
dafür da sind zu erkennen, was den Reset ausgelöst hat).
Der Bootlader soll aufräumen, soso. Wozu?

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> CK schrieb:
>
>> Der einzig saubere Weg ist ein Watchdog-Reset zu forcieren.
>
> Nein. Der einzig saubere Weg ist: Der Bootloader räumt sauber auf und
> stellt so den Hardware-Reset-Zustand her, bevor er die Applikation
> anspringt. Er kann das tun, denn sein (hoffentlich kompetenter)
> Programmierer weiss sehr genau, was er daran verändert hat und wie man
> das wieder zurücksetzt...

 Genau.
 Und der saubere Bootloader:
 a) Nimmt beim Start an, dass alle I/O Register, 32 general purpose
 Register und der ganze SRAM absolut zufällige Werte haben.

 b) Setzt beim rausspringen alle I/O Register auf initial Werte.

von Jim Beam (Gast)


Bewertung
7 lesenswert
nicht lesenswert
1) Der WATCHDOG-Reset stellt EXAKT DEN ZUSTAND her,
der auch beim Hardware- oder PowerOn-Reset erfolgt.
(Natürlich bis auf das Statusbit, welches die Resetursache zeigt)

2) Dies ist die EINZIGE Möglichkeit den internen Reset-Zyklus per reiner 
Software auszulösen.

Jeder andere Unfug der hier geschrieben wurde
ist überflüssig.
Punkt.

von Naja (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Punkt.

von Sebastian S. (amateur)


Bewertung
-1 lesenswert
nicht lesenswert
Vielleicht rückst Du ja mal den Nachnamen raus!

Die etwas älteren ATMegas beginnen ihre Arbeit bei 0.
Genaueres wirst Du aber nur erfahren, wenn Du den vollständigen Namen 
Deines µP raus rückst.

Natürlich kann auch geraten werden oder alternativ schmeißt Du mal eine 
Pupille ins Handbuch.

Beitrag #5531942 wurde von einem Moderator gelöscht.
von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
Jim Beam schrieb:
> Punkt.

Beeindruckendes Statement.
Für den Fall, daß du geistig in der Lage bist, die Problematik zu 
erfassen:
Das WDRF überschreibt das WDE.

von H.Joachim S. (crazyhorse)


Bewertung
-1 lesenswert
nicht lesenswert
Das meine ich mit Schmutzkübel, deine ständigen und sinnlosen 
Beleidigungen
> Man sieht das an dem Gefrickel, was z.B. diese Arduidioten betreiben

Ich verstehe in der Tat nicht, was du meinst. Zeige mal EINEN AVR, der 
einen internen watchdog hat und dessen Reset kein vollwertiger Reset 
ist.

Ansonsten steht bei mir am Anfang sowieso immer die vollständige 
Peripherie-Initialisierung, auch wenn sie nur den reset-Zustand nochmal 
schreibt. Was sowas im Bootlader zu suchen hat??
Steht es in der Applikation, kann ich es dort rausschmeissen, falls es 
mal eng wird mit dem Platz (kommt fast nie vor).

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
H.Joachim S. schrieb:
> Zeige mal EINEN AVR, der
> einen internen watchdog hat und dessen Reset kein vollwertiger Reset
> ist.

https://www.mikrocontroller.net/articles/AVR_Typen

Wie ich schon dem mit dem billigen Whiskey mitteilte:

WDRF überschreibt WDE.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Noch ne Idee:
Polyfuse in die VCC-Leitung, nen dicken Transistor, der VCC kurzschließt 
und die Brownout-Fuse setzen.

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
Wahrscheinlich ist brownout-Reset auch nicht gut genug :-)

Beitrag #5531975 wurde von einem Moderator gelöscht.
von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
Microchip selbst empfiehlt den Watchdogreset:
https://www.microchip.com/webdoc/AVRLibcReferenceManual/FAQ_1faq_softreset.html

Bisher hat es sich bei mir bewährt, mich an diese Empfehlungen zu 
halten, - vollkommen egal, was c-hater und andere Besserwisser mir 
erzählen wollen.

Beitrag #5532013 wurde von einem Moderator gelöscht.
von H.Joachim S. (crazyhorse)


Bewertung
1 lesenswert
nicht lesenswert
Thomas E. schrieb:
> Das WDRF überschreibt das WDE.

Und?
Darin siehst du irgendeinen sinnvollen Grund, im bootlader-Programm die 
gesamte Peripherie auf Reset-Zustand zu setzen und mit jmp 0 neu zu 
starten statt das Hündchen mal kläffen zu lassen?

Beitrag #5532045 wurde von einem Moderator gelöscht.
von Joachim B. (jar)


Bewertung
-3 lesenswert
nicht lesenswert
Klugscheisser schrieb:
> asm("jmp 0x0000");
>
> fiele mir da ein... könnte gehen

ich mache es so nach einem Tipp aus dem Forum
1
    else if( !strcmp(serial_in_command, "reset") )
2
    { // "reset"
3
      delay(250);
4
      {asm("ldi r30,0"); asm("ldi r31,0"); asm("ijmp");}
5
    } // if( !strcmp(serial_in_command, "reset") )

dummerweise erkenne ich dann aber nicht ob PowerOnReset oder Reset per 
command
1
  // ---------------- init ---------------- 
2
//http://www.atmel.com/images/doc8059.pdf
3
  if(MCUSR&(1<<PORF))
4
  { MCUSR&=~(1<<PORF);
5
    Serial.println(F("Erststart pow"));
6
  }
7
  if(MCUSR&(1<< EXTRF))
8
  { MCUSR&=~(1<< EXTRF);
9
    Serial.println();
10
    Serial.println();
11
    Serial.println();
12
    Serial.println(F("RESET"));
13
    Serial.println(F("-----"));
14
  }

von avr (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Joachim B. schrieb:
> ich mache es so nach einem Tipp aus dem Forum

Ja, das ist sogar noch schlechter als der direkte Jump. Braucht doppelt 
so viel Speicherplatz und ist genausowenig ein richtiger Reset.

von Joachim B. (jar)


Bewertung
-3 lesenswert
nicht lesenswert
avr schrieb:
> Ja, das ist sogar noch schlechter als der direkte Jump. Braucht doppelt
> so viel Speicherplatz

wieviel ist doppelt das in Bytes?
Statt 2 6 oder 12?

mag ja sein das es mehr braucht, aber nennenswert?

avr schrieb:
> und ist genausowenig ein richtiger Reset.

das bemerkte ich auch, aber es funktioniert, das Init aller Variablen 
und Ports obliegt dann mir!

Hast du ausser Kritik einen besseren Vorschlag?

Peter D. schrieb:
> Noch ne Idee:
> Polyfuse in die VCC-Leitung, nen dicken Transistor, der VCC kurzschließt
> und die Brownout-Fuse setzen.

für einen ESP aus einem LE33CV im TO92 genügte ein BC547, beide nahmen 
nicht übel, brownout hatte ich beim ESP nicht gesetzt oder ist nicht 
vorhanden?

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Harry L. schrieb:
> Microchip selbst empfiehlt den Watchdogreset:

Grr.  Ich hasse es, dass sie das avr-libc-Manual als ihr eigenes dort
ausgeben – selbstredend unter Verletzung der Lizenzbedingungen (die
eine Namensnennung erfordern).

Nein, nicht Microchip „empfiehlt“ da irgendwas, sondern das ist die
FAQ, die das avr-libc-Projekt im Laufe seiner Entwicklungszeit
zusammengetragen hat.  Diese enthält halt Tipps&Tricks.

Thomas E. schrieb:
> WDRF überschreibt WDE.

Dass, und dass WDRF überhaupt stehen bleibt, sind doch aber die einzigen
Dinge, die bei einem Watchdog-Reset eben vorsätzlich nicht geändert
werden.  Es ist ansonsten ein kompletter Reset.

Aus ebendiesem Grunde sollte man in jedem Programm, welches den Watchdog
benutzt (oder im Falle des Bootloaders: welches damit rechnen muss, dass
es vom Watchdog-Reset gestartet worden ist), als allererste Amtshandlung
WDRF zurücksetzen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Joachim B. schrieb:
> das Init aller Variablen und Ports obliegt dann mir!

Ports ja, Variablen nein – zumindest nicht beim üblichen C-Startup.
Der löscht bzw. initialisiert die Variablen selbstredend, und natürlich
wird der abgearbeitet (irgendwann), nachdem man über Adresse 0 anfängt.
Wie sonst sollte es bei einem normalen Reset denn funktionieren?  Ein
Reset reinitialisiert zwar die IO-Ports, aber er fasst nicht den RAM
an.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> für einen ESP aus einem LE33CV im TO92 genügte ein BC547

War aber eher als Scherz gemeint.
Beim AVR tut es der Watchdogreset einwandfrei, um in den Bootloader zu 
kommen.
Der Bootloader weiß ja, welche IO-Register er angefaßt hat (z.B. UART) 
und muß nur diese zurück setzen, bevor er die Applikation anspringt.

Man kann sogar den Watchdog weiterhin durch die Applikation benutzen. 
Der Bootlader löscht MCUSR.WDRF und WDTCR.WDE nur dann, wenn er auch 
eine neue Applikation lädt. Ansonsten läßt er sie unverändert.

von Thomas E. (Firma: Thomas Eckmann Informationst.) (thomase)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Dass, und dass WDRF überhaupt stehen bleibt, sind doch aber die einzigen
> Dinge, die bei einem Watchdog-Reset eben vorsätzlich nicht geändert
> werden.  Es ist ansonsten ein kompletter Reset.

Ja, aber nur ansonsten. Und nicht, wie hier behauptet wurde exakt das 
selbe wie ein Hardware- oder Power-On-Reset.

Jörg W. schrieb:
> als allererste Amtshandlung
> WDRF zurücksetzen.

Und nicht nur das. Der Watchdog muß auch abgeschaltet oder im laufenden 
Programm regelmäßig bedient werden. Aber das sind ja alles keine 
Unterscheide. Dafür brüstet man sich dann damit, daß man am Anfang des 
Programms in seiner ganzen Paranoia sowieso alle Register auf default 
setzt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Thomas E. schrieb:
> Aber das sind ja alles keine Unterscheide.

Hat das irgendwo jemand bestritten?

Es ist und bleibt dennoch ein vollständiger Hardware-Reset.  Auch ein
POR oder Reset via Pin setzt schließlich seine jeweils eigenen
Flags in MCU[C]SR.

Dass WDRF ein WDE impliziert, ist übrigens nicht pauschal bei allen
AVRs der Fall: bei älteren war das noch nicht so (ATmega16, ATmega128).
Hat man als Sicherheits-Feature erst später nachgezogen.

von avr (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Joachim B. schrieb:
> Hast du ausser Kritik einen besseren Vorschlag?

Dein Code ist equivalent zu jmp 0 wollte ich dir damit sagen. Das ist 
ungefähr so wenn ich dir vorschlage statt x += 2; x++; x++; zu 
schreiben.

Der Watchdog bleibt die sicherste Variante. Jeder (und das war bisher 
jeder in diesem Thread), der den Jump bevorzugt und davor nicht die 
Interrupts deaktiviert, hat Race Conditions nicht bedacht und bisher 
wohl Glück gehabt.

Und ich finde es fahrlässig, hier möglichen Anfängern solche Tipps zu 
geben. Wer weiß was er tut, kann allen möglichen Murks auf dem 
Controller machen. Aber wer meint, ein jmp 0 wäre ein Reset, der hat 
irgendwann einen zerschossenen Stackpointer. Und da ich mir keine 
Gedanken darüber machen will, was noch alles schief gehen kann, bleibe 
ich beim Watchdog.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-1 lesenswert
nicht lesenswert
avr schrieb:
> Controller machen. Aber wer meint, ein jmp 0 wäre ein Reset, der hat
> irgendwann einen zerschossenen Stackpointer.

 Was hat das damit zu tun ?
 ATMEL:
1
All user programs must initialize the SP in the Reset routine (before subroutines
2
or interrupts are executed).

 Egal wie und was den RESET ausgelöst hat oder ob es nur ein Sprung zum
 RESET-Vektor war.

: Bearbeitet durch User
von avr (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Marc V. schrieb:
> before subroutines
> or interrupts are executed

Sogar Atmel schreibt es indirekt. Was hast du daran nicht verstanden? 
Was könnten Race Conditions mit dem setzen des Stack-Pointers zu tun 
haben?

Ja, auch du hast bisher Glück gehabt.

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
avr schrieb:
> Dein Code ist equivalent zu jmp 0 wollte ich dir damit sagen.

dachte ich schon, sah man ja auch im Code
{asm("ldi r30,0"); asm("ldi r31,0"); asm("ijmp");}

warum das 0 laden auf 2 ASM Befehle aufgeteilt wurde, keine Ahnung, 
solange mache ich AVR noch nicht und Assemler für AVR noch weniger.
Ich dachte das evtl. direkte 16-Bit loads nicht gehen.

> Der Watchdog bleibt die sicherste Variante.

wie lernte ich gerade erst?
Arduino old bootloader der Watchdog schlägt schneller zu als der 
Bootloader es verhindern kann?

von Karl K. (karl2go)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> ich mache es so nach einem Tipp aus dem Forum

Vorher noch Interrupts per CLI sperren.

von avr (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Joachim B. schrieb:
> warum das 0 laden auf 2 ASM Befehle aufgeteilt wurde, keine Ahnung,

Das geht nicht anders. Aber das sind 3 16bit Befehle, statt einem 32bit 
Befehl. Ich finds jedensfalls komisch wie man auf die Idee kommt einen 
jmp 0 so umzuschreiben.

Joachim B. schrieb:
> Arduino old bootloader der Watchdog schlägt schneller zu als der
> Bootloader es verhindern kann?

Abgesehen, davon dass ich die Qualität von Arduino-Software 
grundsätzliche bezweifle, kann man auch den Watchdog langsamer 
einstellen. Wenn man quasi-proprietäre Software nutzt (denn welcher 
Arduino-User ändert Bibliotheken und Bootloader ab), dann ist man eben 
eingeschränkt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Marc V. schrieb:
> All user programs must initialize the SP in the Reset routine (before
> subroutines
> or interrupts are executed).

Neuere AVRs erledigen dies nach einem Reset in der Hardware. Das ist
dann entsprechend in den Defaultwerten der Register SPL/SPH auch so
ausgewiesen.

Bei älteren war das nicht der Fall, weshalb bspw. der Startup-Code der
avr-libc die Stackpointer-Initialisierung generell vornimmt.

avr schrieb:
> kann man auch den Watchdog langsamer einstellen

Nach einem Watchdog-Reset fällt er allerdings automatisch auf den
kürzesten Wert (ca. 15 ms) zurück, denn das entsprechende Register
wird durch den Reset sehr wohl auf seinen Initialwert gesetzt.
Innerhalb dieser Zeit muss man daher WDRF gelöscht haben und den
Watchdog entweder abgeschaltet oder zumindest auf eine längere Zeit
programmiert haben.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-3 lesenswert
nicht lesenswert
avr schrieb:
> Was hat das damit zu tun ?
>  ATMEL:All user programs must initialize the SP in the Reset routine
> (before subroutines
> or interrupts are executed).

> Sogar Atmel schreibt es indirekt. Was hast du daran nicht verstanden?

 Und was hast du am obigen ATMEL Zitat nicht verstanden ?

 Wenn man (du) es falsch macht, dann ist es absolut egal wie und was
 den RESET ausgelöst hat.

 SP wird weder beim RESET (egal welchen) noch beim JMP 0 initialisiert,
 somit ist deine Aussage, dass jmp 0 einen zerschossenen Stackpointer
 bedeuten kann aber ein RESET nicht, absoluter Blödsinn.
 Auch wenn als initial value RAMEND steht - das gilt nicht für alle und
 kann beim nächsten Modell wieder anders sein.

avr schrieb:
> Ja, auch du hast bisher Glück gehabt.

 Nein, du hast Glück gehabt, vorausgesetzt du hast überhaupt jemals
 was mit AVR zu tun gehabt.

: Bearbeitet durch User
von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-3 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Neuere AVRs erledigen dies nach einem Reset in der Hardware. Das ist
> dann entsprechend in den Defaultwerten der Register SPL/SPH auch so
> ausgewiesen.
1
 All user programs must initialize the Stack Pointer (SP) in the Reset
2
 routine (before subroutines or interrupts are executed).

 Obiges Zitat stammt aus 328PB DaBla, auch wenn als Initialwert
 RAMEND angegeben ist.

 Die dazu nötigen 2 Befehle sind bestimmt nicht die Ursache für
 schlechte, riesige und langsame Programme, deswegen...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Obiges Zitat stammt aus 328PB DaBla, auch wenn als Initialwert
>  RAMEND angegeben ist.

Ja, weil das bei Chipdesignern nicht anders läuft als bei
Softwareentwicklern: neue Versionen (des Datenblatts) werden aus
bestehenden Versionen durch copy&paste erzeugt.

Damit hält sich solche eine Aussage auch dann, wenn sie eigentlich
gegenstandslos geworden ist.

Es bleibt trotzdem einer der Unterschiede zwischen einem JMP 0
und einem Reset (egal aus welcher Quelle).

Andererseits (s.o.) erledigt der Startupcode das normalerweise ohnehin,
insofern ist dieser Unterschied praktisch bedeutungslos.

von Zempel (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Auweia...was habe ich denn da angerichtet? War doch nur eine ganz 
harmlose Frage...

Fakt ist: der Reboot mit dem Watchdog funktioniert, der ganze Code dazu 
besteht aus

   wdt_enable(WDTO_30MS);
   for (;;);

Dass der neu gestartete Bootloader/die neu gestartete Andwendung auf 
Grund irgend welcher nicht initialisierter Register (oder was auch 
immer) Probleme hätten, wäre mir dabei nicht aufgefallen...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Zempel schrieb:
> Dass der neu gestartete Bootloader/die neu gestartete Andwendung auf
> Grund irgend welcher nicht initialisierter Register (oder was auch
> immer) Probleme hätten, wäre mir dabei nicht aufgefallen.

Was für einen ATmega benutzt du denn?

Mit einem ältlichen ATmega8, ATmega16 oder ATmega128 (die es ja auch 
alle in einer aktuellen A-Variante gibt) wirst du in der Tat keinerlei 
Probleme haben. Das mit dem nach dem Reset noch aktiviert bleibenden 
Watchdog betrifft neuere AVRs.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-3 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Mit einem ältlichen ATmega8, ATmega16 oder ATmega128 (die es ja auch
> alle in einer aktuellen A-Variante gibt) wirst du in der Tat keinerlei
> Probleme haben. Das mit dem nach dem Reset noch aktiviert bleibenden
> Watchdog betrifft neuere AVRs.

 Und kann nur mit ISP wieder zurechtgebogen werden - Bootloader ist
 einfach nutzlos.

 Optiboot ist besser, funktioniert immer und ist kürzer.
 Link: https://github.com/Optiboot/optiboot

von Joachim B. (jar)


Bewertung
-1 lesenswert
nicht lesenswert
Marc V. schrieb:
>  Optiboot ist besser, funktioniert immer und ist kürzer.

na na na, leider nicht, jedenfalls nicht default mit 115K2 auf dem 
Arduino mit 16 MHz.

Am Kabel JA bedingt mit mehreren Versuchen, mit wUSB und LANport 400 von 
sharkoon eben nicht!
Dort half nur den Optiboot auf 57K6 herabzusetzen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Marc V. schrieb:
> Jörg W. schrieb:
>> Mit einem ältlichen ATmega8, ATmega16 oder ATmega128 (die es ja auch
>> alle in einer aktuellen A-Variante gibt) wirst du in der Tat keinerlei
>> Probleme haben. Das mit dem nach dem Reset noch aktiviert bleibenden
>> Watchdog betrifft neuere AVRs.
>
>  Und kann nur mit ISP wieder zurechtgebogen werden

ISP hilft übrigens gar nichts, wenn der Fall eintritt, sofern man
nicht eine Firmware flasht, die WDRF rücksetzt.  Auch nach dem ISP
(welches ein Pin-Reset beinhaltet) bleibt es nämlich gesetzt … nur
Power-on hilft dagegen.

> - Bootloader ist
>  einfach nutzlos.
>
>  Optiboot ist besser

Was genau ist Optiboot?

Ein Bootloader.

Ach?!

Dann ist es also auch nutzlos?

Widersprichst du dir nicht gerade selbst?

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Und kann nur mit ISP wieder zurechtgebogen werden -

Schwachsinn!
Wenn der WDT in Software aktiviert wurde, kann man ihn auch per Software 
wieder abschalten.

Du meinst die WDT Fuses!
Da hast du recht....
Das geht nur per externem Programmieradapter.
Hat aber auch nichts direkt mit dem WDT zu tun, sondern betrifft alle 
Fuses.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-5 lesenswert
nicht lesenswert
Jörg W. schrieb:
> ISP hilft übrigens gar nichts, wenn der Fall eintritt, sofern man
> nicht eine Firmware flasht, die WDRF rücksetzt.  Auch nach dem ISP
> (welches ein Pin-Reset beinhaltet) bleibt es nämlich gesetzt … nur
> Power-on hilft dagegen.

 Stromversorgung wird beim ISP einstecken normalerweise abgeschaltet.

> Ach?!
>
> Dann ist es also auch nutzlos?
>
> Widersprichst du dir nicht gerade selbst?

 Warum dieser missglückter Versuch sarkastisch zu sein ?

 Nein, ich widerspreche mir nicht selbst, alles eine Frage der
 Zeit - wie schnell und ob überhaupt der BL WDT zurücksetzt...
 Die meisten BL tun das nicht - Optiboot wurde aber entsprechend
 umgeschrieben.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-4 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Marc V. schrieb:
>> Und kann nur mit ISP wieder zurechtgebogen werden -
>
> Schwachsinn!
> Wenn der WDT in Software aktiviert wurde, kann man ihn auch per Software
> wieder abschalten.

 Nein, dein Geschrei ist Schwachsinn.
 Wenn jeder Bootloader das tun würde, hätten wir nicht die Geschichte
 mit endlosem Watchdog RESET.
 Ergo, die meisten (AVR) Bootloader tun das nicht (Bitte den feinen
 aber entscheidenden Unterschied zwischen nicht tun und nicht können
 bemerken) und erst dann sinnlos rumschreien.

 P.S.
 Wie schon oben geschrieben:
 Optiboot wurde aber entsprechend umgeschrieben.

: Bearbeitet durch User
von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Entweder verstehst du mich wirklich nicht, oder du tust so als ob...
Ich weiß nicht, was schlimmer ist.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Marc V. schrieb:

>  Stromversorgung wird beim ISP einstecken normalerweise abgeschaltet.

Warum denn das?

Hab' ich noch nie gemacht (und ich habe viele Jahre lang beruflich AVRs 
programmiert).  Gut, wir haben später eher kein ISP sondern JTAG 
benutzt, aber da blieb das JTAGICE in der Regel die ganze Zeit 
angesteckt. Oft haben wir auch die Zielsysteme vom Büro aus programmiert 
und debuggt, die im Labor rumstanden, ohne dass wir überhaupt einmal am 
Tag dahin gelaufen wären.

Das Prinzip bleibt aber auch bei JTAG dasselbe: der JTAG-Reset setzt die 
anderen Reset-Bits nicht zurück.

>> Widersprichst du dir nicht gerade selbst?
>
>  Warum dieser missglückter Versuch sarkastisch zu sein ?

Weil ich die Aussage „Bootloader sind Mist, Optiboot ist besser“ für
unsinnig halte.

Nur, weil du mal einen Bootloader kennst, der damit ordentlich umgehen 
kann und (mindestens) einen, der es nicht kann, ist das kein Grund für 
irgendwelche Verallgemeinerungen.

Es hätte weniger nach Marketing-Blafasel geklungen, wenn du einfach 
geschrieben hättest: „Optiboot ist ein Bootloader, der das ordentlich 
handhaben kann.“

von CK (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zempel schrieb:
> wdt_enable(WDTO_30MS);
>    for (;;);

Besser:
1
cli();
2
wdt_enable(WDTO_30MS);
3
for (;;);

Auch wenn es unwahrscheinlich (schlechte Praxis) ist, dass in irgend 
einer ISR der Watchdog beeinflusst wird.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-3 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Es hätte weniger nach Marketing-Blafasel geklungen, wenn du einfach
> geschrieben hättest: „Optiboot ist ein Bootloader, der das ordentlich
> handhaben kann.“

Marc V. schrieb:
> Nein, ich widerspreche mir nicht selbst, alles eine Frage der
>  Zeit - wie schnell und ob überhaupt der BL WDT zurücksetzt...
>  Die meisten BL tun das nicht - Optiboot wurde aber entsprechend
>  umgeschrieben.
>

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-6 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Marc V. schrieb:
>
>>  Stromversorgung wird beim ISP einstecken normalerweise abgeschaltet.
>
> Warum denn das?

 Weil man sonst die Dinger mit ISP Programmer ausliefern müsste.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Marc V. schrieb:
> Jörg W. schrieb:
>> Marc V. schrieb:
>>
>>>  Stromversorgung wird beim ISP einstecken normalerweise abgeschaltet.
>>
>> Warum denn das?
>
>  Weil man sonst die Dinger mit ISP Programmer ausliefern müsste.

Diese Aussage verstehe ich nicht.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-5 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Marc V. schrieb:
>> Jörg W. schrieb:
>>> Marc V. schrieb:
>>>
>>>>  Stromversorgung wird beim ISP einstecken normalerweise abgeschaltet.
>>>
>>> Warum denn das?
>>
>>  Weil man sonst die Dinger mit ISP Programmer ausliefern müsste.
>
> Diese Aussage verstehe ich nicht.

Jörg W. schrieb:
> programmiert).  Gut, wir haben später eher kein ISP sondern JTAG
> benutzt, aber da blieb das JTAGICE in der Regel die ganze Zeit
> angesteckt.

 Ein Modul hat (normalerweise) nur ISP Anschluss eingebaut.
 Um dieses Modul neu zu programmieren, muss man einen entsprechenden
 Programmer jedesmal anschliessen oder einen fest einbauen.
 ISP bedeutet nur, dass der uC nicht rausgenommen werden muss, ist
 aber nicht gleichbedeutend mit hotplug, also sollte man die
 Stromversorgung schon abschalten.
 Es kann auch sein, dass SD-Card oder SPI-Display angeschlossen ist.
 Das muss alles vorher getrennt werden.
 Deswegen (und auch sonst) sollte man die Stromversorgung vorher
 abschalten.

 Und um die Diskussion nicht unnötig zu vertiefen - ja, man kann es
 auch anders machen und nein, ich habe nichts dagegen und ja, ein
 anständiger ISP-Programmer muss Tristate Ausgänge haben...

von avr (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Marc V. schrieb:
> SP wird weder beim RESET (egal welchen) noch beim JMP 0 initialisiert,
>  somit ist deine Aussage, dass jmp 0 einen zerschossenen Stackpointer
>  bedeuten kann aber ein RESET nicht, absoluter Blödsinn.

mal ganz nebenbei, es ist immer wieder lustig, wie du dich hier 
blamierst - nein, eigentlich ist es traurig.

Damit wir uns nicht falsch verstehen:
- SP wird (auch nach deiner Aussage) im Startup code inistialiert
- Durch den jmp 0 OHNE deaktivieren der Interrupts kann ein Interrupt 
zwischen dem 16-bit Writes auf SP stattfinden (das nennt man übrigens 
auch Race Condition)
- Der Interrupt manipuliert den Stackpointer und überschreibt damit das 
Hilfsregiser für den 16-Bit Zugriff
- Der 16-bit Write schreibt ein anderen Wert in SP
(irgendwann später)
- Stackoverflow

Wenn du das verstanden hast, darfst du wieder antworten. Der Unterschied 
ist, dass bei einem Watchdog-Reset die Interrupts deaktiviert sind. Ein 
Watchdog-Reset ohne Interruptsperre tut im schlimmsten Fall gar nichts. 
Ein JMP ohne cli führt dagegen im Worst-Case zu komplett undefiniertem 
Verhalten (bis zum Überschreiben des eigenen Programms).

von Naja (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Ergänzend zum "Jump":
Die ganze Peripherie wird nicht zurückgesetzt. Ich wette darauf, dass 
viele Programmierer das nicht oder nicht richtig im Init-Code 
berücksichtigen. Man "ferkelt" einfach Registerwerte über irgendeinen 
Ausgangszustand. Meist klappt das prima. Wenn man Pech hat, läuft das 
Programm erst nach einigen Erweiterungen "etwas instabil". Den 
Zusammenhang mit dem "Jump" hat man dann aber vergessen. Viel Spaß beim 
Fehlersuchen!

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-4 lesenswert
nicht lesenswert
avr schrieb:
> mal ganz nebenbei, es ist immer wieder lustig, wie du dich hier
> blamierst - nein, eigentlich ist es traurig.

 Tja, dasselbe wollte ich eigentlich dir schreiben...

> Damit wir uns nicht falsch verstehen:
> - SP wird (auch nach deiner Aussage) im Startup code inistialiert
> - Durch den jmp 0 OHNE deaktivieren der Interrupts kann ein Interrupt
> zwischen dem 16-bit Writes auf SP stattfinden (das nennt man übrigens
> auch Race Condition)

 Usw, usw.
 Deswegen hat ATMEL einen komischen Befehl, nämlich CLI.

 Aber nein, du musst unbedingt eine Situation konstruieren, wo jemand
 ohne CLI nach RESET-Vektor springt.

 Warum sollte er das tun?
 Irgendwie mit dir verwandt?

von avr (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Marc V. schrieb:
> Deswegen hat ATMEL einen komischen Befehl, nämlich CLI.

Und warum erwähnst du das dann nicht? Doch nicht etwa vergessen - oder 
doch?

Marc V. schrieb:
> Aber nein, du musst unbedingt eine Situation konstruieren, wo jemand
>  ohne CLI nach RESET-Vektor springt.
>
>  Warum sollte er das tun?
>  Irgendwie mit dir verwandt?

Dann darfst mal zählen wie oft das Wort CLI in diesem Thread vorkam 
bevor ich Race Conditions erwähnte.

Und auch du selbst schreibst kein Wort davon, im Gegenteil: Du stempelst 
es als Blödsinn ab.

Marc V. schrieb:
> SP wird weder beim RESET (egal welchen) noch beim JMP 0 initialisiert,
>  somit ist deine Aussage, dass jmp 0 einen zerschossenen Stackpointer
>  bedeuten kann aber ein RESET nicht, absoluter Blödsinn.

von Marc V. (Firma: Vescomp) (logarithmus)


Bewertung
-3 lesenswert
nicht lesenswert
avr schrieb:
> Und auch du selbst schreibst kein Wort davon, im Gegenteil: Du stempelst
> es als Blödsinn ab.
1
 Jeder Sprung nach RESET-Vektor ohne cli vorher ist mehr oder
2
 weniger Blödsinn.
3
4
 Die Annahme, dass der Sprung nach 0x00 mit RESET gleichzusetzen ist,
5
 ist auch Blödsinn.
6
7
 Die Annahme, dass man sich nur nach RESET auf entsprechender Adresse
8
 befinden kann, ist genauso Blödsinn.
9
10
 Die Annahme, dass auch in Zukunft SP bei allen AVRs nach RAMEND
11
 zeigen wird, ist Blödsinn hoch 3.

 Aber natürlich darf ein Experte wie du voraussetzen, dass der Sprung
 nach RESET Vektor ohne jeden Grund erfolgte und das derjenige, der
 das programmiert hat, überhaupt keine Ahnung von ATMEL-uC hat, noch
 nie etwas von cli und sei gehört hat und ganz einfach aus Spass und
 Unwissenheit so etwas macht.

 Und es darf sich natürlich um keinen Tiny mit 256Byt oder noch weniger
 RAM handeln...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Naja schrieb:
> Ich wette darauf, dass viele Programmierer das nicht oder nicht richtig
> im Init-Code berücksichtigen.

Muss man auch nicht, denn selbstverständlich kann man sich erstmal drauf
verlassen, dass das, was im Datenblatt steht, so funktioniert.  Alle 
IO-Register komplett mit ihren Initialwerten zu befüllen, ist 
verplemperter Flash.

Es ist in diesem Falle Sache desjenigen, der den Bootloader verfasst, 
dass er vor dem Sprung all die Peripherie zurücksetzt, die er angefasst 
hat.  Er sollte das ja eigentlich wissen …

von Naja (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Soweit sehe ich das genauso.

Ich meine was anderes:
Bei einem "Jump" führt der Controller keinen richtigen Reset aus und die 
Initialwerte aus dem Datenblatt stehen daher eben nicht in den 
Peripherieregistern. Im eigenen Init-Code (Bootloader bzw. 
Hauptprogramm) geht man aber (normalerweise) von den Initialwerten aus.
Auch ein simples Nullsetzen der Peripherieregister durch eigenen Code 
würde nicht dem Verhalten eines richtigen Resets entsprechen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Naja schrieb:
> Bei einem "Jump" führt der Controller keinen richtigen Reset aus und die
> Initialwerte aus dem Datenblatt stehen daher eben nicht in den
> Peripherieregistern.

Ja.

Aus dem Grund muss derjenige, der den Jump nach 0 macht, vorher
die Initialwerte wieder einstellen.  Er sollte ja wissen, was er
verbogen hat.

von Naja (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ok, dann ja.

Man muss dann aber an jede verwendete Peripherie denken und die 
ordentlich runterfahren. Der Aufwand steigt und fehlerträchtig ist es 
auch.
Das würde ich nur machen, wenn ich es müsste. Beispielsweise der 
RAM-Inhalt oder Teile vom Peripheriezustand erhalten bleiben sollen. 
Hoffentlich nie :-)

von Zempel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Zempel schrieb:
>> Dass der neu gestartete Bootloader/die neu gestartete Andwendung auf
>> Grund irgend welcher nicht initialisierter Register (oder was auch
>> immer) Probleme hätten, wäre mir dabei nicht aufgefallen.
>
> Was für einen ATmega benutzt du denn?

Es ist ein ATMega382P

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Zempel schrieb:
>> Was für einen ATmega benutzt du denn?
>
> Es ist ein ATMega382P

ATmega328P, vermute ich. Der hat aber in der Tat ein WDRF-Bit, welches
automatisch WDE aktiviert.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Ich meine mich zu erinnern, dass die I²C Peripherie sich derart 
aufhängen kann, dass man nur noch mit einem Reset (nicht jump to 0) 
wieder heraus kommt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ich meine mich zu erinnern, dass die I²C Peripherie sich derart
> aufhängen kann, dass man nur noch mit einem Reset (nicht jump to 0)
> wieder heraus kommt.

Das würde ich allerdings als Bug in der Hardware ansehen: wenn man
TWE auf 0 setzt, sollte sich dort eigentlich alles in den
Ausgangszustand zurücksetzen (so ist es auch beschrieben).

von Zempel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> ATmega328P, vermute ich. Der hat aber in der Tat ein WDRF-Bit, welches
> automatisch WDE aktiviert.

Ja, genau, 328 meinte ich :-)

Um diesen länglichen Thread noch mal zusammenzufassen: dieses WDRF-bit 
führt dazu, dass Optiboot nicht sich selbst, sondern sofort die 
Applikation startet?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Zempel schrieb:
> dieses WDRF-bit führt dazu, dass Optiboot nicht sich selbst, sondern
> sofort die Applikation startet?

Das WDRF-Bit führt dazu, dass nach einem Watchdog-Reset ca. 15 ms später 
sofort wieder ein solcher ausgelöst wird, sofern nicht die Software 
dieses Bit (und das dadurch ebenfalls gesetzte WDE-Bit) relativ zügig 
löscht.  Wenn nach dem Reset ein Bootloader erstmal angeworfen wird, ist 
es folglich seine Aufgabe, diese Aktion auszuführen *).  Offensichtlich 
ist nicht jeder Bootloader so geschrieben worden, dass er dies 
berücksichtigt, aber Optiboot wurde genannt als einer, der es kann.

*) Einzige Ausnahme: der Bootloader fragt sofort nach dem Reset 
irgendein Hardware-Pin ab, bspw. einen Jumper, und springt danach sofort 
die eigentliche Applikation an weil er merkt, dass er jetzt nicht aktiv 
werden soll.  Die paar CPU-Takte gehen schnell genug, als dass man dann 
das WDRF- und WDE-Gefummel auch der regulären Applikation überlassen 
darf.

von Zempel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
OK, jetzt habe ich es verstanden - Danke!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.