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!
Der einzig saubere Weg ist ein Watchdog-Reset zu forcieren. Nur dann werden die Hardware-Register neu initialisiert.
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...
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
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.
Habe ich immer per Watchdog gemacht. Einfach und zuverlässig. Spricht irgendetwas dagegen?
> 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.
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.
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.
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.
> 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.
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.
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.
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?
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.
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.
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.
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.
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).
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.
Noch ne Idee: Polyfuse in die VCC-Leitung, nen dicken Transistor, der VCC kurzschließt und die Brownout-Fuse setzen.
Wahrscheinlich ist brownout-Reset auch nicht gut genug :-)
Beitrag #5531975 wurde von einem Moderator gelöscht.
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.
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.
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 | }
|
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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?
Joachim B. schrieb: > ich mache es so nach einem Tipp aus dem Forum Vorher noch Interrupts per CLI sperren.
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.
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.
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
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...
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.
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...
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.
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
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.
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?
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.
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.
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
Entweder verstehst du mich wirklich nicht, oder du tust so als ob... Ich weiß nicht, was schlimmer ist.
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.“
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.
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. >
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.
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: > 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...
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).
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!
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?
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.
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...
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 …
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.
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.
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 :-)
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
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.
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.
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).
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?
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.
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.