Hallo ich habe einen Arduino Uno und wollte darauf ein Sketch hochladen darin waren ein paar Bibliotheken enthalten für TFT Touchscreen usw. Das hat auch wunderbar funktioniert mir gefiel dann die Schrift nicht und ich habe eine Font Bibliothek eingefügt. Beim Hochladen hat dann irgendwas nicht funktioniert und seit dem Leuchtet nur noch die Power LED und die L LED. Kann es sein das mein Programm zu groß war und der Bootloader mit überschrieben wurde. Oder ist das so nicht möglich? Ich habe leider nicht auf die größe geachtet und kann jetzt leider auch nicht mehr nachgucken weil das Programm schon wieder umgeändert worden ist.
Keiner schrieb: > Kann es sein das mein Programm zu groß war und der > Bootloader mit überschrieben wurde. Oder ist das so nicht möglich? Kann eigentlich nicht sein. Der Bootloader ist am Anfang vom Flash, die größe wird über die FUSES eingestellt. Macht die Ardunio IDE von sich aus. Jedoch ist nicht auszuschliessen, dass evtl. etwas anderes bei der Übertragung schief gelaufen ist. Außer du hast nicht über USB mit dem Bootloader dein Sketch hochgeladen, sondern mit einem externen Programmer.
:
Bearbeitet durch User
Kann man denn den Bootloader dadurch schrotten wenn was schief läuft??
Keiner schrieb: > Kann man denn den Bootloader dadurch schrotten wenn was schief > läuft?? Möglich ist alles, auch wenn es eher komisch wäre. Ich nutze den Bootloader leider nicht (wenn ich mal was mit Arduino mache). Falls du noch ein Ardunio hast, dann nutze den doch als ISP Programmer und flash dir auf den UNO wieder den Bootloader.
Aktuell habe ich keinen hier aber ist bestellt. Der Verkäufer meinte nur ob ich den Bootloader überspielt habe aber ich war eigentlich der Meinung das es so gar nicht geht
Adam P. schrieb: > Der Bootloader ist am Anfang vom Flash Nein, bei den Mega-AVR8-Arduinos ist er am Anfang des Bootloaderbereichs. Dieser wiederum liegt selber aber am Ende des Flashs, nicht am Anfang. Und deswegen ist es (zumindest theoretisch) natürlich durchaus möglich, den Bootloader zu überschreiben, wenn die Anwendung zu groß wird. Allerdings wird beim Arduino typisch das das Schreib-Lockbit für den Bootloaderbereich aktiviert, was genau dies wirkungsvoll verhindert. Der Bootlader bleibt also erhalten. Aber natürlich ist die Anwendung dann unvollständig, was zu beliebigen Fehlfunktionen führen kann. Spätestens nach einem Power-Cycle sollte man aber wieder im Bootloader landen.
Das ist möglich und das passiert, beim herum Probieren mit Marlin ist mir das auch schon passiert, knapp drüber und der Bootloader war gekillt. Beim AVR liegt der Bootloader am Ende vom FLASH und kann nicht geschützt werden, dafür muss der Bootloader-Code schon selber sorgen. Edit: okay, das stimmt nicht, es gibt Lock-Bits mit denen verhindert werden kann das SPM in den Boot Loader Bereich schreibt, nur sind die Chips üblicherweise nicht gelockt. Kann auch gut sein das es Arduino-Bootloader gibt die dafür nicht anfällig sind. Bei ARMs liegt der Bootloader am Anfang vom FLASH und kann zumindest bei einigen Derivaten wie ATSAMC/ATSAMD gegen einfaches Überschreiben geschützt werden.
:
Bearbeitet durch User
Adam P. schrieb: > Kann eigentlich nicht sein. Dem stimme ich zu. Adam P. schrieb: > Der Bootloader ist am Anfang vom Flash, Dem nicht. Er liegt am Ende. Keiner schrieb: > Oder ist das so nicht möglich? Es ist bei einem UNO nicht möglich, dass der Bootloder sich selber zerstört. Rudolph R. schrieb: > Das ist möglich und das passiert, beim herum Probieren mit Marlin ist > mir das auch schon passiert, knapp drüber und der Bootloader war > gekillt. > Beim AVR liegt der Bootloader am Ende vom FLASH und kann nicht geschützt > werden, dafür muss der Bootloader-Code schon selber sorgen. > Kann auch gut sein das es Arduino-Bootloader gibt die dafür nicht > anfällig sind Auch bei einem Arduino Mega ist das nicht möglich. Klarer: Ich habe keine Ahnung, welche Böcke ihr da schießt. Aber eins weiß ich ganz genau: Ihr buddelt auf der falschen Baustelle. c-hater schrieb: > Allerdings wird beim Arduino typisch das das Schreib-Lockbit für den > Bootloaderbereich aktiviert, was genau dies wirkungsvoll verhindert. Der > Bootlader bleibt also erhalten. Aber natürlich ist die Anwendung dann > unvollständig, was zu beliebigen Fehlfunktionen führen kann. Spätestens > nach einem Power-Cycle sollte man aber wieder im Bootloader landen. So ist es. Wobei die IDE einen anschreit, wenn das Programm zu groß wird.
Soweit ich weiß, reagiert der Flash Speicher empfindlich auf instabile Stromversorgung. Unter ungünstigen Umständen können sogar Daten verloren gehen, während man ausschließlich lesend darauf zugegriffen hat. Die Brown-Out Detection (dazu gibt es eine Fuse) sollte das zuverlässig verhindern. Aber manchmal hat man gute Gründe, sie nicht zu aktivieren.
Stefan ⛄ F. schrieb: > Die Brown-Out Detection (dazu gibt es eine Fuse) in der Arduino-IDE? Die Fuses kann ich eigentlich nur mit einem Programmer über ISP setzen. Oder irre ich mich in diesem Punkt?
Erwin D. schrieb: > Die Fuses kann ich eigentlich nur mit einem Programmer über ISP setzen. > Oder irre ich mich in diesem Punkt? Das stimmt. Wenn man mit der Arduino IDE den Bootloader "brennt" müsste der Brown-Out Detector automatisch mit aktiviert werden. Worum es mir eigentlich ging ist, darauf hinzuweisen, das selbst der BOD kein 100% sicheres Mittel ist, Flash-Verluste bei instabiler Stromversorgung zu verhindern.
Arduino Fanboy D. schrieb: >> Oder ist das so nicht möglich? > Es ist bei einem UNO nicht möglich, dass der Bootloder sich selber > zerstört. > > Auch bei einem Arduino Mega ist das nicht möglich. Das ist ja mal eine mutige Ansage, Du kennst alle verschiedenen Optiboot Varianten die so im Umlauf sind? Es sollte nicht so sein, richtig. Ich hatte das mit einem Ender3 Board, also einem ATMega1284P. Bootloader wieder drauf, alles wieder gut. Was ich hier an Arduinos so herum liegen habe sind Seeduinos, weil ich die geschenkt bekommen habe. Damit habe ich mal probier und in PlatformIO Arduino code erzeugt der mit 31204 Bytes etwas zu lang war. PlatformIO interessiert das noch nicht, das geht offenbar davon aus das der Bootloader nur 512 Bytes lang ist. Flash: [==========] 96.7% (used 31204 bytes from 32256 bytes) Das wird geschrieben und erst beim Verify wird ein Fehler festgestellt. Schön, der Bootloader-Bereich von dem Seeduino ist wohl geschützt. Leider bekomme ich das Ding aus irgendeinem Grund mit dem AtmelICE nicht ausgelesen. So als ob ISP bei dem M328P ausgeschaltet wäre. Nicht mal ein Chip-Erase funktioniert, seltsam. Aber ganz offensichtlich ist da schon mal kein Bootloader mit 512 Bytes drin. avrdude: verifying ... avrdude: verification error, first mismatch at byte 0x7800 0xff != 0x6f avrdude: verification error; content mismatch Damit ist der Bootloader in diesem Uno Clone 2k groß.
Stefan ⛄ F. schrieb: > Worum es mir eigentlich ging ist, darauf hinzuweisen, das selbst der BOD > kein 100% sicheres Mittel ist, Flash-Verluste bei instabiler > Stromversorgung zu verhindern. Ist mir persönlich noch nicht passiert, aber es gibt ja bekanntlich nichts, was es nicht gibt :-)
Rudolph R. schrieb: > Das ist ja mal eine mutige Ansage, Du kennst alle verschiedenen Optiboot > Varianten die so im Umlauf sind? Natürlich! Es gibt nur einen einzigen offiziellen Bootloader für den Mega. Da hat sich nie was dran geändert. Gleiches gilt für den UNO. Ich will nicht bezweifeln, dass du mit irgendwelchen modifizierten Boards, oder Eingenanfertigungen Probleme hast. Aber mit den originalen hat das nichts zu tun. Stefan ⛄ F. schrieb: > Worum es mir eigentlich ging ist, darauf hinzuweisen, das selbst der BOD > kein 100% sicheres Mittel ist, Flash-Verluste bei instabiler > Stromversorgung zu verhindern. Schön, wenn du meinst, dass das so ist. Aber mit dem Bootloader hat das nichts zu tun. Es ist ein Fakt, dass dieser sich nicht selbst überschreiben/löschen kann. Wenn denn die Fuses richtig stehen....
Erwin D. schrieb: > Ist mir persönlich noch nicht passiert Das ist noch nie jemandem passiert. Er erzählt vom EEPROM. Da lässt sich dieser Fehler mit einem ausreichend grossen Kondensator und entsprechend langsamem Zusammbruch der Versorgungsspannung ohne BOD zuverlässig reproduzieren.
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Schön, wenn du meinst, dass das so ist. > Aber mit dem Bootloader hat das nichts zu tun. Ja und? Der TO wollte wissen, was möglicherweise passiert ist. Ist es ein Fehler, dabei etwas weiter über den Tellerrand zu schauen? Muss ich mit jetzt auch noch an den Aussagen zum Bootloader festbeißen, nur weil ein paar wenige andere Personen das tun?
Stefan ⛄ F. schrieb: > Der TO wollte wissen, was möglicherweise passiert ist. Ist es ein > Fehler, dabei etwas weiter über den Tellerrand zu schauen? Ja, aber doch nicht so weit, wie du.... Das von dir beschriebene Problem "kann" mit dem EEPROM auftreten, wenn BOD falsch oder gar nicht gesetzt ist. Das das bei korrekt gesetztem BOD auch beim lesen des Flashes passiert, ist gänzlich neu für mich. Das Datenblatt hält sich da auch bedeckt. Oder kannst du da auf einen Eintrag verweisen? Von daher, befürchte ich, dass dir da die Fantasie aus dem Ruder gelaufen ist. Siehe: Stefan ⛄ F. schrieb: > Worum es mir eigentlich ging ist, darauf hinzuweisen, das selbst der BOD > kein 100% sicheres Mittel ist, Flash-Verluste bei instabiler > Stromversorgung zu verhindern. Ja, eine unsaubere Versorgung, verursacht Resets. Aber doch keine Flash Verluste im laufenden Betrieb. Glaubst du da wirklich dran? Belege? Oder sprichst du über irgendwelche anderen µC, als AVRs?
Arduino Fanboy D. schrieb: > Oder kannst du da auf einen Eintrag verweisen? Jemand mit Dr. Titel der Beruflich Schaltungen für die KFZ Industrie entwickelt wies mich darauf hin, dass das auch mit FLASH passieren kann, nachdem es mir mit dem EEPROM passiert ist und ich das ganz überraschend fand. Außerdem hatte ich mal ein Modem, dessen Flash Speicher (da war es noch ein separater Chip) spontan Teile seines Inhaltes verlor. Das könnte so ein Fall gewesen sein.
Alles klar! Bei irgendeinem ungenannt gebliebenen µC, kann das nach Hörensagen passieren. Und dein Modem hat einen Defekt, oder ist schlampig gebaut. Kann ja sein ..... Keiner schrieb: > Hallo ich habe einen Arduino Uno
Arduino Fanboy D. schrieb: > Bei irgendeinem ungenannt gebliebenen µC, kann das nach Hörensagen > passieren. Es ging um einen AVR, konkret um einen Xmega128D3. > Und dein Modem hat einen Defekt Nach Austausch des Flash Speichers lief es wieder für einige Jahre, bis ich es nicht mehr brauchte. > oder ist schlampig gebaut. Kann ja sein ..... das möchte ich nicht behaupten. Es war ein Produkt der Firma Dr. Neuhaus. Falls dir das was sagt.
Stefan ⛄ F. schrieb: > Nach Austausch des Flash Speichers lief es wieder für einige Jahre, bis > ich es nicht mehr brauchte. Also, dass ein Flash einen Defekt hat, kann ich mir schon vorstellen. Wäre auch nicht der erste defekte Flash, der mir über den Weg läuft. Aber das hat dann nichts damit zu tun, dass AVRs bei unsauberer Versorgung ihren Flash Inhalt Zerrütten. Das sind zwei völlig unterschiedliche Probleme. Wirf sie in einen Topf, wenn dir das richtig erscheint. Aus meiner Sicht ist das allerdings arg irrational. Stefan ⛄ F. schrieb: > Es ging um einen AVR, konkret um einen Xmega128D3. Habe da mal etwas hinterhergesucht, und kann keine gleichlautenden Berichte finden. Auch in den Errata nicht. Da finden sich bei den Xmega schon einige Einträge zum EEPROM, aber nicht zu spontanen Flash Verwirrungen. Kann man das reproduzieren? Sicher, dass dein Dr, nicht irgendeinen Bock geschossen, oder sich geirrt, hat? ------ Nein, ich will keine Antworten auf die Fragen. Denn ich weiß mittlerweile dass du nicht bereit bist den Rückwärtsgang einzulegen. Und deine Fantasiewelt gönne ich dir. Auch wenn es mich etwas stört, dass du den Kram als Realität verkaufst. Wenn du möchtest, dann kann ich ja mal einen Lehrgang mit dir durchziehen, wie man den Wahrheitsgehalt von Annahmen und Behauptungen halbwegs objektiv einschätzen/beurteilen kann. Stefan ⛄ F. schrieb: > Ist es ein > Fehler, dabei etwas weiter über den Tellerrand zu schauen? Meistens ja! Denn hinter dem Tellerrand befindet sich unbekanntes Gebiet. Nicht wissen usw. Und daraus kann man NICHTS ableiten. Schon gar nicht Tipps/Beurteilungen usw.
Stefan ⛄ F. schrieb: > Jemand mit Dr. Titel der Beruflich Schaltungen für die KFZ Industrie > entwickelt wies mich darauf hin, dass das auch mit FLASH passieren kann, > nachdem es mir mit dem EEPROM passiert ist und ich das ganz überraschend > fand. Jetzt mal nur am Rande...ich schätze die Beiträge von Stefan sehr und möchte ihm an dieser Stelle sagen, dass er sich sicher nicht hinter einer "Dr.-Authorität" verstecken muß! Bei mir galt und gilt nach wie vor höchstes Misstrauen, wenn der Doktor "einschreitet". Natürlich kommts auch auf den Doktor selbst an :-) Gruß Rainer
Arduino Fanboy D. schrieb: > Denn hinter dem Tellerrand befindet sich unbekanntes Gebiet. > Nicht wissen usw. Sofort alle Forschung einstellen! GEFAHR!
c-hater schrieb: >> Der Bootloader ist am Anfang vom Flash > > Nein, bei den Mega-AVR8-Arduinos ist er am Anfang des > Bootloaderbereichs. Dieser wiederum liegt selber aber am Ende des > Flashs, nicht am Anfang. Arduino Fanboy D. schrieb: > Adam P. schrieb: >> Der Bootloader ist am Anfang vom Flash, > Dem nicht. > Er liegt am Ende. Ja sorry, war etwas unüberlegt und zu schnell... Aber sollte der Linker nicht trotzdem ein Fehler werfen, bzgl. kein Platz im Flash?
Arduino Fanboy D. schrieb: > Kann man das reproduzieren? Wie gesagt, mein Fall auf dem AVR betraf das EEPROM, und ja es war reproduzierbar mit einer schlechten Stromversorgung. In dem Zuge wurde *mir* gesagt, dass das auch der FLASH Speicher Inhalte verlieren kann, wenn die Stromversorgung schlecht ist. Das wiederum ist mir noch nicht reproduzierbar passiert. Da gab es nur den einen Fall mit dem Modem, wo der Auslöser des einmaligen Fehlers unbekannt ist. > Nein, ich will keine Antworten auf die Fragen. > Denn ich weiß mittlerweile dass du nicht bereit bist > den Rückwärtsgang einzulegen. Was soll das werden? Aus meiner Sicht scheinst du mal wieder sehr darauf erpicht zu sein, Fehler in meinen Aussagen zu entdecken. Tatsächlich führt deine einseitige Sichtweise dazu, dass du den Sinn meiner Aussagen verdrehst und mir dann für deine Verdrehten Bedeutungen niedere Absichten unterstellst. Kannst du das mal bitte sein lassen? Um das hier nochmal für dich eindeutig klar zu stellen: Ich habe nicht behauptet dass der FLASH Speicher Daten verlieren kann. Das kam von dem erwähnten Dr. Man wird ja wohl noch zitieren (bzw. Informationen weiter geben dürfen) ohne gleich ein schlechter Mensch zu sein! Ich würde dir gerne Ersatz für die fehlenden Tassen in deinem Schrank schicken. Mache mal eine Liste und schicke mir deine Postanschrift.
Stefan ⛄ F. schrieb: > Kannst du das mal bitte sein lassen? Nein! Begründung folgt. Stefan ⛄ F. schrieb: > Was soll das werden? Aus meiner Sicht scheinst du mal wieder sehr darauf > erpicht zu sein, Fehler in meinen Aussagen zu entdecken. Tatsächlich > führt deine einseitige Sichtweise dazu, dass du den Sinn meiner Aussagen > verdrehst und mir dann für deine Verdrehten Bedeutungen niedere > Absichten unterstellst. Seit Monaten/Jahren, erwische ich dich immer mal wieder mit Behauptungen/Lügen, welcher an den Haaren herbeigezogen sind. Nicht nur! In den weitaus meisten Fällen liegst du richtig. Ich schätze deine Kompetenz. Oft, stimme ich dir zu. Und sei es auch nur, in dem ich still mitlese und dabei nicke. Auch schon ein paar mal öffentlich, wenn du mit einer korrekten Argumentation auf Widerstand gestoßen bist. Aber: Du machst Projektionsfehler. Ganz grobe Schnitzer. Welche dann dazu führen, dass deine Argumentationen, die Kausalketten, defekt sind. Zwischen Ursache und Wirkung, gibt es einen Kausalzusammenhang. Du neigst dazu, wenn dir dieser nicht bekannt ist, ihn mit deiner Fantasie dahin zu malen. Dieses gemalte Fantasiebild, das projizierst du auf die Realität. Was du dann siehst, ist eine Mischung aus Realität und Einbildung. Und diese plapperst du hier im Forum raus. Dabei ist es dir scheiß egal, wie groß der Wahrheitsgehalt ist. Für dich ist er hoch, denn du sagst ja nur, was du siehst. Beispiel: Die Behauptung, dass es gute Gründe gibt, dass Arduino kein Board mit einem Tiny85 herausgebracht hat. z.B. Sowas interessiert mich. Arduino ist ein Teil dessen, mit dem ich mich beschäftige. Solche Gründe, warum das Arduino nicht tun sollte, sind mit nicht bekannt. Dabei kenne ich einige Gründe, warum Arduino das tut, was es tut. Aber den nicht. Also frage ich nach. Ich frage dich dann. Denn du hast ja die Behauptung aufgestellt, dass es gute Gründe gibt. Üblicher weise eierst du dann ein wenig rum, wirfst mir vor, dich in die Pfanne hauen zu wollen.... Aber dann kristallisiert sich raus, Du kennst die Gründe gar nicht. Die Realität sieht eher so aus: Du hättest "gute Gründe", wenn du Arduino wärst, kein solches Board zu produzieren. Siehst du, was ich meine? Du projizierst deine Gründe, auf die Arduinos. Obwohl die höchst vermutlich nie sowas gesagt haben, oder je dran gedacht. Das ist dir aber vollkommen egal. Die Gründe gibt es in deiner Fantasie, und das reicht dir, um sie hier raus zu blähen. Deine Projektion überdeckt die Realität, und wird hier als Wahrheit von dir verkauft. Bedenke: Ich glaube nicht, dass unbedarfte in der Lage sind dieses sofort zu erkennen. Und hier im Forum haben wir es mit Unbedarften zu tun. Nicht alle, aber einige nimmst du so auf die Schippe. Ich bezeichne das mal, als unbeabsichtigtes Lügen und Verarschen. Ja, unbeabsichtigt. Ein Serientäter ohne Absicht. Stefan ⛄ F. schrieb: > Ich habe nicht > behauptet dass der FLASH Speicher Daten verlieren kann. Naja... Stefan ⛄ F. schrieb: > Soweit ich weiß, reagiert der Flash Speicher empfindlich auf instabile > Stromversorgung. Unter ungünstigen Umständen können sogar Daten verloren > gehen, während man ausschließlich lesend darauf zugegriffen hat. > > Die Brown-Out Detection (dazu gibt es eine Fuse) sollte das > zuverlässig verhindern. Aber manchmal hat man gute Gründe, sie nicht zu > aktivieren. In dem Augenblick kann ich nur dich fragen! Da ist noch kein Dr. im Spiel. Da ist nur deine Behauptung. Das das schreiben vom Flash, eine stabile Versorgung benötigt... Unwidersprochen. Steht auch so im Datenblatt. > Unter ungünstigen Umständen können sogar Daten verloren > gehen, während man ausschließlich lesend darauf zugegriffen hat. Das hat sich jetzt als Hörensagen herausgestellt. Der Versuchsaufbau ist für mich nicht reproduzierbar. Die Kausalkette ist unvollständig, und damit kaputt. Natürlich betrifft mich das! Ich arbeite tagtäglich, seit es (bezahlbare) Flash gibt, mit solchen Speichern. Natürlich frage ich nach, wie du darauf kommst. Das willst du mir zum Vorwurf machen, dass ich Behauptungen hinterfrage, die mich und meine tägliche Arbeit betreffen? Stefan ⛄ F. schrieb: > Kannst du das mal bitte sein lassen? Nein! Behauptungen, welche mich betreffen hinterfrage ich. Ich will dann Fakten sehen. > Die Brown-Out Detection (dazu gibt es eine Fuse) sollte das > zuverlässig verhindern. Aber manchmal hat man gute Gründe, sie nicht zu > aktivieren. Das ist auch so ein Dingen... Welche Gründe gibt es, BOD nicht zu aktivieren, wenn man sich doch so mit hoher Wahrscheinlichkeit Fehlfunktionen einhandelt. Und seien es auch nur zerrüttete EEPROM Inhalte. Der einzige Grund, der mir da spontan einfällt: Dummheit. Stefan ⛄ F. schrieb: > Lege dich doch mit dem Dr. an, nicht mir mir! Kein Interesse mich mit irgendwem anzulegen. Und doch: Das ist wieder so eine irrationale Projektion! Ich kenne weder den Dr., noch ist er irgendwie für mich erreichbar. In deiner Fantasie/Projektion sollte ich mich lieber mit dem Herrn unterhalten. Eigentlich eine gute Idee! Nur sieht die Realität anders aus. Ich habe keine Chance. Ich gebe dir den Rat: Überprüfe deine Projektionen sorgfältiger. ---------------- Percy N. schrieb: > Arduino Fanboy D. schrieb: >> Denn hinter dem Tellerrand befindet sich unbekanntes Gebiet. >> Nicht wissen usw. > > Sofort alle Forschung einstellen! GEFAHR! Auch du hast was ganz wichtiges nicht verstanden! Natürlich sollte man sich schon etwas Mühe geben seinen Horizont zu erweitern. Was dann dazu führt, dass der Tellerrand weiter nach draußen wandert. Aber über den Rand hinweg ins Unbekannte zu schauen, und aus dem Unbekanntem dann Begründungen/Verhalten und so ein Zeugs abzuleiten ist Unsinnig. Das führt zu irgendwelche wirren Verschwörungstheorien und vergleichbaren Blödsinn. Beispiel: https://youtu.be/W9qH5lbs96M Da kann man das Tellerrand Paradox erleben.
Arduino Fanboy D. schrieb: > Welche Gründe gibt es, BOD nicht zu aktivieren, wenn man sich doch so > mit hoher Wahrscheinlichkeit Fehlfunktionen einhandelt. Und seien es > auch nur zerrüttete EEPROM Inhalte. > Der einzige Grund, der mir da spontan einfällt: Dummheit. Da ploppt bei mir sofort eine Frage auf: Warum hat der Hersteller die BOD als Fuse angelegt und nicht fest implementiert? Also scheint es doch Gründe zu geben, sie nicht zu verwenden. Welche das sind, weiß ich auch nicht. Aber ich möchte es gern wissen. Hast du eine Antwort?
Arduino Fanboy D. schrieb: > Seit Monaten/Jahren, erwische ich dich immer mal wieder mit > Behauptungen/Lügen, welcher an den Haaren herbeigezogen sind. Ich habe das also schon korrekt erkannt. Du hast mich auf dem Kieker, und das schränkt deine Sicht ein.
BOD verbraucht Strom, und BOD kann nur mit wenigen Stufen umgehen, der Prozessor hingegen je nach Stromquelle auch mit anderen Spannungen stabil laufen. Und: ich bin eigentlich davon ausgegangen, das der Bootloader die zu schreibende Adresse prüft und sich nicht selbst überschreibt, unabhängig der Fuses. Andere Bootloader (auch auf anderen Architekturen) machen das, aber ich hab mir den Optiboot nie angesehen und das auch nicht getestet.
:
Bearbeitet durch User
Erwin D. schrieb: > Warum hat der Hersteller die BOD als Fuse angelegt und nicht fest > implementiert? Also scheint es doch Gründe zu geben, sie nicht zu > verwenden. Welche das sind, weiß ich auch nicht. Aber ich möchte es gern > wissen. > Hast du eine Antwort? Der Brown-Out Detektor braucht Strom. Bei Geräten, die lange mit Batterien laufen sollen will man ihn eventuell deaktivieren.
Stefan ⛄ F. schrieb: > Erwin D. schrieb: >> Warum hat der Hersteller die BOD als Fuse angelegt und nicht fest >> implementiert? Also scheint es doch Gründe zu geben, sie nicht zu >> verwenden. Welche das sind, weiß ich auch nicht. Aber ich möchte es gern >> wissen. >> Hast du eine Antwort? > > Der Brown-Out Detektor braucht Strom. Bei Geräten, die lange mit > Batterien laufen sollen will man ihn eventuell deaktivieren. Das leuchtet ein. Natürlich. Also ist es doch nicht nur Dummheit ;-)
Stefan ⛄ F. schrieb: > Ich habe das also schon korrekt erkannt. Du hast mich auf dem Kieker, > und das schränkt deine Sicht ein. Dann hast du meinen Text nicht verstanden. Also nochmal klar: Wenn du Dinge "Berichtest" welche mich betreffen, dann überprüfe ich sie und übernehmen sie nicht einfach in mein Weltbild. Wenn mir da Diskrepanzen auffallen, frage ich nach bzw. berichte ich sie dir. Ja, das darfst du persönlich nehmen, wenn du das möchtest. Mache ich aber bei anderen auch so, was du gerne ignorieren darfst. Du bist da also niemand besonderes für mich, nur eben sehr auffällig und leicht überführbar. ------------ Stefan ⛄ F. schrieb: > Der Brown-Out Detektor braucht Strom. Bei Geräten, die lange mit > Batterien laufen sollen will man ihn eventuell deaktivieren. Das kann man auch beim Eintritt in den Schlafmodus tun. Egal wie die Fuses stehen. (bei allen AVR?) Und im Schlaf wird man auch kein EEPROM bespielen, oder FLASH beschreiben. Außerhalb des Schlafmodus, fällt der BOD Verbrauch sowieso nicht auf. Gerade im Batteriebetrieb ist BOD recht wichtig, damit man sich eben das EEPROM nicht schreddert. ------------- Jens M. schrieb: > Und: ich bin eigentlich davon ausgegangen, das der Bootloader die zu > schreibende Adresse prüft und sich nicht selbst überschreibt, unabhängig > der Fuses. Nein, der Bootloader prüft da nix. Es sind die LOCK Fuses, welche verhindern, dass der Bootloader sich selber löscht.
Arduino Fanboy D. schrieb: > Gerade im Batteriebetrieb ist BOD recht wichtig, damit man sich eben das > EEPROM nicht schreddert. Weil du gerade das Argument von Stefan entkräftet hast, möchte ich dich nochmals fragen, warum der Hersteller die BOD mittels Fuse abschaltbar gemacht hat. Dein Argument von oben (Dummheit) kann es wohl nicht sein.
Jede Funktion sollte irgendwie abschaltbar sein. Wir hatten einen Controller im Einsatz (keinen Atmel), bei dem die Corespannung beim Löschen von Flash-Blöcken so sehr gezappelt hat, dass die BOD auslöste und den Bootloader in den Reset schickte. Workaround und spätere Empfehlung des Herstellers im Errata Sheet war dann keine BOD im Bootloader, aktive BOD in der Applikation. Vor solchen Problemen ist kein Hersteller sicher, daher will man möglichst flexibel sein.
Arduino Fanboy D. schrieb: > Natürlich sollte man sich schon etwas Mühe geben seinen Horizont zu > erweitern. > Was dann dazu führt, dass der Tellerrand weiter nach draußen wandert. Also den Tellerrand mit sich herumschleppen? Das erinnert mich an eine Formulierung von F. J. Strauß.
Percy N. schrieb: > Also den Tellerrand mit sich herumschleppen? Das erinnert mich an eine > Formulierung von F. J. Strauß. Und mich erinnert das an Kurt (sorry, böses Wort)
Erwin D. schrieb: > Weil du gerade das Argument von Stefan entkräftet hast, möchte ich dich > nochmals fragen, warum der Hersteller die BOD mittels Fuse abschaltbar > gemacht hat. Dein Argument von oben (Dummheit) kann es wohl nicht sein. Lass gut sein. Hier weiter nach zu bohren führt nur zu noch mehr persönlichen Angriffen die niemandem helfen.
Erwin D. schrieb: > Und mich erinnert das an Kurt (sorry, böses Wort) So pflegt jeder seine eigenen mehr oder minder traumatischen Erinnerungen ... https://youtu.be/Y_t1KLtK0KI
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Lass gut sein. Hier weiter nach zu bohren führt nur zu noch mehr > persönlichen Angriffen die niemandem helfen. Stefan, ich möchte überhaupt niemanden angreifen. Mich hat es einfach interessiert und deshalb hab ich diese Frage gestellt. Ganz ohne Hintergedanken. Und mittlerweile sind ja schon einige Argumente genannt worden, aufgrund derer nicht ersichtlich ist, wer nun recht hat und wer nicht.
Arduino Fanboy D. schrieb: > Kein Interesse mich mit irgendwem anzulegen. bezweifel ich, mich nimmst du gerne! Stefan halte ich zu Gute das er seine offensichtlichen Fehler einsieht. Das kann ich akzeptieren, mich nervt nur sein Helfersyndrom wo er immer wieder bei unklarer Ausgangslage helfen möchte wo man nicht helfen kann. Da versuche ich immer weniger zu helfen, denn mit unklarer Wunschvorstellung können nur 90% - 100% aller vorgeschlagenen Hilfen ins Leere laufen. Bei dir hatte ich letztens auch wieder Gepöbel zu mir entdeckt, aber wenigstens offen und nie hinterrücks, aber ich sehe nur was geschrieben wird. Also halten wir doch fest, normalerweise kann bei Arduino der Bootloader nicht überschrieben werden ohne ISP, aber wir kennen nicht alle Umstände, mittlerweile habe ich hier 2 nano die stottern, kann an anderem liegen das untersuche ich noch, auch nanos kann man überflashen wenn die seit Jahren als Aufbau immer wieder neu programmiert werden und andere Fehler können auch eintreten.
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Das kann man auch beim Eintritt in den Schlafmodus tun. Egal wie die > Fuses stehen. (bei allen AVR?) Die P-Typen können so konfiguriert werden, daß sie das selbständig tun.
Stefan ⛄ F. schrieb: > Arduino Fanboy D. schrieb: >> Seit Monaten/Jahren, erwische ich dich immer mal wieder mit >> Behauptungen/Lügen, welcher an den Haaren herbeigezogen sind. > > Ich habe das also schon korrekt erkannt. Du hast mich auf dem Kieker, > und das schränkt deine Sicht ein. Das liegt auch ein bisschen an dir selbst. Du kommst hier schon das eine oder andere Mal mit irgendwelchen Behauptungen, die tatsächlich an den Haaren herbeigezogen sind. Ich erinnere nur an deine Ausführungen zum Debuggen mit der Waschmaschine. Aber darum soll es jetzt gar nicht gehen. Daß du ein ausgeprägtes Helfersyndrom hast, haben auch schon andere Leute festgestellt. Vielleicht solltest du dich da mal ein wenig zurücknehmen: Du mußt nicht für alles eine Erklärung liefern. Das aktuelle Thema kann niemand erklären. Wie so oft sitzt auch hierbei wahrscheinlich das Problem wieder einmal vor dem PC. Da hat irgend jemand Mist gebaut, kann sich nicht mehr erinnern, was das genau war und hofft jetzt auf Hilfe. Die kann ihm in diesem speziellen Fall aber keiner geben. Zum Thema deines unbekannten Dr. als zitierfähige Referenz: Ich hatte vor gar nicht so langer Zeit eine Schaltung vorliegen, die nur mit Atmega 328P lief, nicht aber mit Atmega 328. Ich behauptete natürlich, daß das totaler Unsinn sei. Das war auch etwas auf Arduino-Basis. Aber mit eigener Hardware. In der Software, die mir im Quelltext vorlag, waren so elementare Fehler drin, daß ich fast meine Tastatur gefressen habe, als ich das gesehen habe. Da gab es nur noch eines: Ein bisschen Reverse Engineering, die Schaltung hatte ich nicht vorliegen, und komplett neu schreiben. Seitdem läuft das auf allen AVR, die über die benötigte Peripherie verfügen. Der Experte, der das verzapft hat, ist Professor und Rektor einer TH.
Also... Unerklärliche Flash Desaster, bei aktiviertem Brownout wären der total GAU. Wenn sich das bewahrheiten würde ..... Bisher sprechen meine Erfahrungen klar dagegen. Das gehört zu den Dingen die nicht auftreten können/dürften. Das würde die µC Familie zum Tode verurteilen. Freiwillig in ein Gerät einbauen, welches mit X% Wahrscheinlichkeit in der Garantiezeit kaputt geht? Nein! In der Industrie? Ganz Sicher nicht. Einen solchen Wackelkandidaten setzt man nicht freiwillig ein, wenn es gleichwertige/bessere Alternativen gibt. Die Preisfrage ist ja: Wie hoch ist die Wahrscheinlichkeit, dass der Flash Inhalt "erodiert", ohne dass ein konkreter Defekt vorliegt? Da spielt das Alter eine Rolle, die Betriebsstunden, die Temperatur, die Anzahl Löschungen. Und so weiter. Wo ist da der Verfall durch Spannungsschwankungen trotz BOD unterzubringen. Mit wie viel Prozent trägt das zur Ausfallwahrscheinlichkeit bei? Die Ausfallwahrscheinlichkeit von AVR ist bei mir bisher NULL. OK, den ein oder anderen habe ich schon gemeuchelt. Aber da wars immer ich. ------------------- Zu der Frage, soll man Brownout abschalten? Ist mir egal. Aber dumm am abgeschaltetem Brownout ist halt, dass alles passieren kann! Der µC darf jeglichen Unsinn bauen, wenn man ihn außerhalb der Spezifikation betreibt. Ich finde, das ist ein Punkt, welcher klar hervor sticht. Als gültigen Kompromiss, finde ich es toll, den Brownout abzuschalten, wenn es in den Tiefschlaf geht. Man könnte einen AVR wählen, welcher das kann. Oder muss eben mit den Folgen/Risiko leben. So, das war eine Meinungsäußerung, welche keinesfalls Anspruch auf absolute Objektivität erhebt. Auch keine Religion/Doktrin. Und sowieso... Meinungen darf es viele geben. Ich selber haben manchmal durchaus mehrere Meinungen zu einem Thema. Die dürfen sich ruhig widersprechen. Aber, zum Glück, gibt es nur eine einzige Realität. Eine! Die können wir nicht, oder nur eher winzige Aspekte davon, wahrnehmen. Auch die immer wieder aufpoppende Frage, oder Priestertreffen, welche Sprache ist die beste? Ist mir egal! Vor und Nachteile findet man bei jeder. Ich unterhalte mich gerne über die verschiedenen Aspekte einer solchen Sprache. Es gibt Fakten, eben die, die den Sprachstandard betreffen, oder auch den konkreten Compiler/Assembler. Die muss man nicht bewerten, wenn man diese Dinge nicht selber erfindet. Und dann gibt es Meinungen dazu. z.B. ich finde C++ doof, weil ich OOP doof finde. Und dutzende mehr. Aber zu sagen, dass C++ Mist ist, nur weil man keine OOP oder Zeiger mag, hat in einem Forum nix zu suchen, denke ich mal. Fakten muss/kann/sollte man auf ihren Wahrheitsgehalt prüfen. Aber nicht einteilen in gut, böse oder was auch immer. Wenn mir Himbeereis nicht schmeckt, dann ist das so. Wenn mir einer Himbeereis aufs Auge drücken will, och nöö... Aber bei jeder Gelegenheit rausposaunen, wie scheiße doch Himbeereis schmeckt. Wie beschissen das ist. Nöö... Himbeereis ist ein Fakt! ---- Und wenn ein Stefanus, oder ein jar, oder irgendwer anders Quatsch erzählt, ins besondere Meinungen als Fakten verkaufen will, gibts Gegenwind. Arduino basher stehen da übrigens ganz weit oben auf der Liste! (aber das wisst ihr ja schon)
Arduino Fanboy D. schrieb: > Ich selber haben manchmal durchaus mehrere Meinungen zu einem Thema. Die > dürfen sich ruhig widersprechen. Arduino Fanboy D. schrieb: > Und wenn ein Stefanus, oder ein jar, oder irgendwer anders Quatsch > erzählt, ins besondere Meinungen als Fakten verkaufen will, gibts > Gegenwind. alles klar :) Arduino Fanboy D. schrieb: > In der Industrie? Ganz Sicher nicht. > > Einen solchen Wackelkandidaten setzt man nicht freiwillig ein, wenn es > gleichwertige/bessere Alternativen gibt. Das MUSS der Beweis sein das man NIE Schrott verkauft bekommt! [/IRONIE]
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Und wenn ein Stefanus ... Meinungen als Fakten verkaufen > will, gibts Gegenwind. Wenn ich begriffe wie "ich glaube", "eventuell", "es könnte sein", "mir ist mal passiert", "jemand hat gesagt" ... benutze, reagierst du genau so pampig. Alles was nicht deinem Kenntnisstand entspricht, scheint für dich derart inakzeptabel zu sein, dass man betroffenen Personen unverzüglich das Maul stopfen muss. Du geht da aus meiner Sicht mit einem Eifer vor, wie die Zeugen Jehovas mit ihrer einzig wahren Wahrheit. Ich habe nichts dagegen, dass man unterschiedliche Meinungen gegenüberstellt. Mir gefällt die persönlich herablassende Art nicht, wie du es machst.
Stefan ⛄ F. schrieb: > Mir gefällt die persönlich herablassende Art nicht, wie > du es machst. Das ist eine Meinung/Einstellung, und darum gestehe ich sie dir auch zu. Den Wahrheitsgehalt darfst du selber analysieren. z.B. könntest du dich mal prüfen wie du auf sanfte Kritik reagierst. Hier ein Beispiel, wie ich sanfte Kritik zum Einsatz bringe: Arduino Fanboy D. schrieb: > Ich vermute das solltest du nochmal überdenken... Es hat dann noch ein paar Beiträge gedauert, bis Falk das dann wirklich getan hat. Aber er hat es getan. Eine solche Kommunikation ist mit dir, meiner Erfahrung nach, eher nicht möglich. Ich glaube so langsam, dass ein freundlicher Hinweis, in deinem Empfinden, ein Nachweis für eine Aggression des Gegenübers ist. Auch schon einfache Nachfragen landen in der Schublade. Du hast ganz offensichtlich große Probleme damit, den Wahrheitsgehalt deiner eigenen Aussagen zu überprüfen. Du hast große Probleme damit, wenn andere, z.B. ich, deine Aussagen auf den Wahrheitsgehalt überprüfen. Wie kann das sein? Ich vermute, dass du dich sehr stark mit deinen Aussagen identifizierst. So wird dann eine Kritik an der Sache, oder auch nur ein Nachfrage, zu einer aggressiven Attacke auf deine Person. Du scheinst da wenig Unterscheid zu machen. Stefan ⛄ F. schrieb: > Worum es mir eigentlich ging ist, darauf hinzuweisen, das selbst der BOD > kein 100% sicheres Mittel ist, Flash-Verluste bei instabiler > Stromversorgung zu verhindern. Hier im Forum haben einige kompetente Leute mitgelesen. Bisher habe ich noch nicht gesehen, dass dir einer zugestimmt hat. Bisher habe ich nichts in den offiziellen Dokus gefunden. Bisher noch nicht erlebt. OK, das ist kein unschlagbarer Beweis. Aber ein Indiz. Stefan ⛄ F. schrieb: > Die Brown-Out Detection (dazu gibt es eine Fuse) sollte das > zuverlässig verhindern. Das "sollte" impliziert die Möglichkeit, dass sich das Flash eben doch bei aktiviertem BOD ändert. Das betrifft mich und meine Arbeit. Ganz konkret. Angela Merkel sollte keine Reptiloidin sein Die Eliten sollten kein Kinderblut trinken Flash sollte seinen Inhalt nicht verlieren, trotz BOD Die Erde sollte nicht flach sein. Hinter jedem dieser Sollte steht ein "ist sie aber doch" oder eine abgeschwächte Form davon "Beweise doch das Gegenteil", "Lege dich mit dem Dr. an" Dieses ist meine Meinung: Deine Ansage, die mit dem Flash Verlust, ist bei den närrischen Verschwöhrungstheorien einzuordnen. Warum du das tust? Kann ich nur vermuten..... Es liegt in der Natur des Menschen, Angst zu haben. Und aus Mangel an rationalen Ängsten, werden irrationale geschaffen. Du hast eine diffuse Angst vor dem Flash Verlust, und möchtest sie hier im Forum verbreiten. Da dir das nicht schmeckt, wenn man dir da einen Stock in die Speichen schiebt, was ich durchaus verstehen kann, ist es völlig ok, wenn du mich als deinen Feind betrachtest.
Arduino Fanboy D. schrieb: > Hier im Forum haben einige kompetente Leute mitgelesen. > Bisher habe ich noch nicht gesehen, dass dir einer zugestimmt hat. Sachlich hat er hier vollkommen Recht. Natürlich kann ein amoklaufender µC beliebige Schäden anrichten, also auch Flash überschreiben. Er funktioniert ja in dieser Situation nicht mehr normal, also gilt auch keine der normalen Regeln mehr. Und das passiert auch tatsächlich und jeder kann es leicht provozieren. Einfach BOD deaktivieren und eine Versorgung anschließen, bei der man die Geschwindigkeit des Spannungsabfalls kontrollieren kann. Es ist dann ziemlich einfach, Flash-Korruption zu provozieren. Die Wahrscheinlichkeit dafür hängt übrigens offensichtlich in hohem Maße davon ab, ob und wie viele SPM-Instruktionen im Code enthalten sind. Passende Bitmuster in Datenbereichen im Flash genügen allerdings auch. Aber selbst die vollständige Abwesenheit solcher Bitmuster in Code und Daten kann den Flash nicht vollständig schützen, der GAU wird nur deutlich unwahrscheinlicher. Und, um auch gleich noch die Frage zu klären, warum man den BOD im Deepsleep bei vielen Devices abschalten kann: Im Deepsleep steht der Takt des internen Oszillators still. Genau dieser Takt treibt aber auch den NVM-Controller. Ohne Takt->keine Aktion. Blöderweise ist aber auch dieser Mechanismus nur eine Wahrscheinlichkeits-Sache. Denn der abstürzende Controller kann den Takt "versehentlich" aktivieren. Aber nach den Gesetzen der Wahrscheinlichkeit ist es eben wesentlich unwahrscheinlicher, dass dies passiert und dann auch noch die restlichen Bedingungen zusammenkommen, die eine Flash-Korruption bewirken.
c-hater schrieb: > Natürlich kann ein amoklaufender µC beliebige Schäden anrichten, also > auch Flash überschreiben. Er funktioniert ja in dieser Situation nicht > mehr normal, also gilt auch keine der normalen Regeln mehr. > > Und das passiert auch tatsächlich und jeder kann es leicht provozieren. > Einfach BOD deaktivieren und eine Versorgung anschließen, bei der man > die Geschwindigkeit des Spannungsabfalls kontrollieren kann. Es ist dann > ziemlich einfach, Flash-Korruption zu provozieren. Das wissen wir alle! (glaube ich) Steht auch mehr oder weniger im Datenblatt so. Spezifikationen, nennt sich das, glaube ich... ;-) Beim Betrieb, außerhalb der Spezifikation, sind alle Gräueltaten zu erwarten. Stefan ⛄ F. schrieb: > Worum es mir eigentlich ging ist, darauf hinzuweisen, das selbst der BOD > kein 100% sicheres Mittel ist, Flash-Verluste bei instabiler > Stromversorgung zu verhindern BOD ist eben ein Weg/Mittel/Werkzeug, die Spezifikationen einzuhalten. Ein Grund weniger für den Amoklauf. Es gibt noch genügend weitere! Es gilt 2 Sachen zu unterscheiden: Amoklaufende Software, welche dann Flash manipulieren Ein Verlust des Flashes rein durch Spannungsschwankungen trotz aktiviertem BOD
Arduino Fanboy D. schrieb: > Es gilt 2 Sachen zu unterscheiden: > Amoklaufende Software, welche dann Flash manipulieren > Ein Verlust des Flashes rein durch Spannungsschwankungen trotz > aktiviertem BOD Nein, das stimmt nicht wirklich. Ein wegen Spannungsmangel abstürzender Controller generiert sich seinen Code ja quasi selber, auf verschiedenen Ebenen. Zum einen kann der Flash nicht fehlerfrei gelesen werden, zum anderen kann der Instruktionsdekoder Mist bauen oder irgendwelche Gatter in der Buslogik können wild hin- und herschalten. Das ist ja genau das Problem: in einem abstürzenden Controller kann ALLES schief gehen und vieles davon passiert quasi- oder sogar wirklich zufällig. Das ist die eine Seite der Sache. Die andere ist, dass es in der Praxis fast immer zu Situationen kommen wird, in denen die Versorgung getrennt/zugeschaltet wird oder werden muss. Und damit ist nunmal zwangsläufig verbunden, dass eigentlich verbotene Spannungsbereiche der Versorgung durchlaufen werden. In unserem Universum kann nämlich nichts instantan geschehen. Das Schadpotential ist also grundsätzlich immer vorhanden, man kann nur Wahrscheinlichkeiten minimieren.
c-hater schrieb: > Das Schadpotential ist also grundsätzlich immer vorhanden, man kann nur > Wahrscheinlichkeiten minimieren. Ein Mittel um dieser Wahrscheinlichkeit Grenzen aufzuerlegen ist BOD. Wie hoch schätzt du die Wahrscheinlichkeit, dass ein Flashverlust, trotz korrekt aktiviertem BOD, auf Grund von Spannungsschwankungen, auftritt? Andere Gründe für den Amoklauf, zB. Programmfehler, mal außen vor gelassen. Denn, dass ein Amoklauf Schaden anrichten kann, da sind wir uns einig.
Arduino Fanboy D. schrieb: > Du hast ganz offensichtlich große Probleme damit Könntest du dich vielleicht um deine eigenen Probleme kümmern und nicht mit deiner Küchentischpsychologie hier auf andere Leute losgehen? Das ist ja furchtbar.
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Wie hoch schätzt du die Wahrscheinlichkeit, dass ein Flashverlust, trotz > korrekt aktiviertem BOD, auf Grund von Spannungsschwankungen, auftritt? Ist mir noch nie passiert. Insofern schätze ich mal mutig 0,01%.
900ss D. schrieb: > Könntest du dich vielleicht um deine eigenen Probleme kümmern Auch wenn es dich nicht kümmert... Aber Flash Versager wären schon ein/mein Problem. Stefan ⛄ F. schrieb: > Ist mir noch nie passiert. Insofern schätze ich mal mutig 0,01%. Mir auch noch nicht!
Ich schätze ja sehr das hier mir zwischen den ganzen Post auch geholfen wird aber mal ganz ehrlich so wie hier miteinander umgegangen wird bzw. Diskussionen geführt werden nervt. Ich habe 3 Fragen gestellt und in allen 3 werden irgendwelche " Kriege" geführt. PS: Bootloader war defekt neu aufgespielt und das Teil läuft
Sebastian schrieb: > Bootloader war defekt neu aufgespielt und das Teil läuft Dann wäre als nächstes die "Problemsoftware" erneut auf den Arduino zu laden, gucken, ob es den wieder zerlegt. Wie schon weiter vorne geschrieben: Die A*-IDE kennt das Board und wird bei Überschreitung der Größe die Compilierung abbrechen, damit dürfte es niemals zu einem Überschreiben des Bootloaders kommen. Mir ist ein Überschreiben noch nie passiert, aber man soll ja niemals Nie sagen :-) Wurde aber gebastelt, anderer Bootloader, falsche Fuses oder falscher Boardtyp ausgewählt, kann ich mir sowas vorstellen. Hast Du die boards.txt verändert? Benutzt Du einen Bootloader, der nicht von Arduino veröffentlicht wurde? Hast Du evtl. ein schlechtes USB-Kabel, was Aussetzer fabriziert?
Möchte hier nur ein paar meiner eigenen Erfahrungen kundgeben. Da man bei importierten Arduino Bords nie weiß welcher Bootloader vom Hersteller installiert wurde, spiele ich grundsätzlich bei Einsatz einer neuen Bord einen Standard, geprüften Optiboot-BL der keine Probleme mit Sleep bzw dem Wachhund hat. Mir ist schon einigemal aufgefallen, daß die meisten Chinabord Nanos und Pro-Minis mit dem Watchdog nicht richtig Ball spielen und sich der Bootloader in einer Loop aufhängt aus der alleine nicht mehr herauskommt. Die besprochenen Probleme hier sind mir noch nicht passiert. Ich habe seit einigen Jahren einige dieser Bords im Dauereinsatz und bisher noch keine Ausfälle erleben müssen, was aber nicht unbedingt viel heissen muß, weil der Teufel bekanntlich in den Details steckt. Was Zuverlässigkeit betrifft kann ich mich auch bei den Chinabords nicht beklagen. Ausfälle hatte ich bei keiner Bord. Ich achte aber im Betrieb immer auf industrielle Gesichtspunkte bezüglich Qualität der Versorgung und externe (Schutz) Beschaltung und habe noch nie Anomalitäten im laufenden Betrieb erleben müssen. Mikrocontroller scheinen an sich extrem zuverlässig sein. Wir hatten ausser einem PIC EEPROM problem in zwanzig Jahren bei unseren Produkten null Ausfälle (so weit bekannt) außer einem Fall wo die FW versehentlich das EEPROM wiederholt laufend beschrieben hatte und die Anwendung nach einigen Monaten Betrieb eventuell fehlerhaft wurde. Auch bei mir hatte ich noch keinen einzigen Ausfall erleben müssen. In meiner Wetterstation laufen PICs schon zwanzig Jahre ohne irgendwelche Ausfälle. Was das Programmieren des FLASH mittels BL betrifft fanden sich die seltenen erlebten Probleme immer vor dem Monitor und Tastatur. Einen BL habe ich mir mit AVRDude noch nie zerschossen. Man muß allerdings darauf achten, daß im boards.txt korrekte Angaben bezüglich des verwendeten Bootloaders gemacht worden sind und tatsächlich wissen wie groß der BL tatsächlich ist. Fehlerhafte Angaben dort können möglicherweise Probleme deswegen verursachen und eine korrekte FLASH Size Berechnung vor dem Programmieren verhindern. Inwieweit fehlerhafte Angaben den BL beschädigen können ist mir etwas unklar. So weit ich mich jetzt erinnern kann lässt sich in den Fuse-Einstellungen der BL Bereich eigentlich festlegen und sollte deshalb geschützt sein. Aber da müsste ich jetzt das Datenblatt diesbezüglich lesen um da sicher zu sein... An sich wäre es am Besten den gewählten Bootloader anhand des mitgelieferten Source Codes daheim selber zu kompilieren und die Eckdaten verifizieren um Überraschungen bei den Fuse-Einstellungen und Anwenden zu vermeiden. Dann kann jan auch die Einstellungen im boards.txt File nachprüfen. Man muß es ja nur einmal machen.
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.