Hallo Kann mir einer vlt. sagen wie oder woran man erkennen kann wie oft einen Atmege-Baustein geflasht wurde oder wie oft man ihn noch flashen kann?
Du musst das Flashregister auslesen. Da steht es drin.
Kann man nicht sagen. Man kann aber den Flash testen, ob alle Bits
richtig gesetzt oder gelöscht wurden (verify).
> wie oft man ihn noch flashen kann?
Das kann Dir keiner sagen, denn es dürfte eine ziemlich extreme
Exemplarstreuung geben. Der Hersteller garantiert nur eine
Mindestanzahl.
Paul schrieb: > Du musst das Flashregister auslesen. Da steht es drin. Glaube ich nicht. In welchem Kapitel des Datenblatts oder Manual steht das?
Hallo, das Problem ist, die Abnützung des Flashs steigt mit der Temperatur. Wenn der Kontroller bei 0 Grad Celsius immer programmiert wird hält er ewig und bei +85 Grad Celsius nur ein kleiner Bruchteil davon. Gruß Sascha
Hallo, einfache Frage, hoffe aber trotzdem auf eine ausführliche Antwort (mit Quellenangabe): Warum ist das so ? mfg Bastler
Avrdude schreibt einen Zähler ins Flash. Kann man abschalten und wenn da vorher Müll drinsteht, dann wird der Zähler auch nur Müll enthalten. Den Rest glaube ich ohne Quellenangabe nicht.
Svenska schrieb: > Avrdude schreibt einen Zähler ins Flash. Kann man abschalten und wenn da > vorher Müll drinsteht, dann wird der Zähler auch nur Müll enthalten. Halb richtig ist auch falsch. Man kann AVRDude per Kommandozeilenoption anweisen, einen Zähler im EEPROM - genauer gesagt in den letzten vier Bytes des EEPROM - zu verwalten. Wenn man diese Option verwendet, sagt einem AVRDude beim flashen auch gleich, der wievielte Durchgang das aktuell ist. Details sind im Manual nachzulesen für die Optionen -Y und -y XL
Axel Schwenke schrieb: > Details sind im Manual nachzulesen für die Optionen -Y und -y In Jörgs Ankündigung Beitrag "AVRDUDE 6.0 freigegeben" steht
1 | - The erase cycle counter (formerly options -y / -Y) has been |
2 | removed. |
Für ein Projekt nimmt man einen µC, und flasht den, so oft man will. Man setzt diesen dann natürlich nicht mehr im Endprodukt ein. Denn Flash verschleißt ja, die Eigenschaften werden mit jedem Flash-Vorgang schlechter. Wenn man einen µC bspw. 10.000 mal flashte, dann hält er die Langzeitdaten eben höchst wahrscheinlich nicht mehr so gut, wie ein nagelneuer. Das bemerkt man sofort natürlich nicht. Aber wie lange braucht man, um nur 1000 mal zu flashen? Wenn das jede halbe Stunde ist, hat man das in 500 Stunden, also ca. 3 Wochen. Wenn man jetzt noch seinen Feierabend und die Schlafenszeit abzieht, braucht man ungefähr 9 Wochen dafür. Also es ist nicht so leicht, mal 10.000 Flash-Zyklen schnell zusammen zu bekommen. An einem Board programmierte ich zum Test mal eine Endlosschleife, in der der µC selbst Daten ins Flash schreibt, und wieder aus liest. Am Feierabend vergaß ich ausgerechnet an dem Tag, den Strom abzuschalten, und so flahte es am nächsten Tag noch. Da war aber auch noch nichts passiert. Es ist aber ratsam, besser seine Software sorgfältig zu machen, und nicht bei einer geringsten Änderung immer alle zwei Minuten schnell wieder zu flashen. Das ist meistens nur Ergebnis durch schnelles Probieren, keine seriöse Arbeit. Nach lesen kann man die Dinge über Flash schon alleine nur in Wikipedia.
Sascha schrieb: > Wenn der Kontroller bei 0 Grad Celsius immer programmiert wird hält er > ewig und bei +85 Grad Celsius nur ein kleiner Bruchteil davon Meistens sind die 10000 Zyklen, von denen hier so oft gesprochen wird, der garantierte Wert bei erhoehter Temperatur, z.B. bei 85 Grad. Z.b. beim STM32F072 steht 10 kcycles Minimum zwischen -40 und +105 Grad.. Also, keine uebergrossen Bedenken bei wiederholten Flashzyklen beim Debuggen...
Uwe Bonnes schrieb: > Also, keine uebergrossen Bedenken bei wiederholten Flashzyklen beim > Debuggen... Für den PIC12F675 auf dem PICkit1 kaufte ich mal 5 Stück nach. Auch weil sie auf dem Steckbrett für kleine Aufgaben so schön praktisch sind. 7€ für alle 5, dafür kriegste in der Kneipe kaum drei Pils. Da denke ich gar nicht mehr über Flash-Zyklen nach. Wo und wie schnell die drei Pils hin gehen, darüber denke ich überhaupt gar nicht. Wenn er hin ist, kommt einer der 5 nach gekauften zum Einsatz. Anfangs zierte ich mich ja auch noch etwas. Anstatt dem 12F675 hätte ich besser mal auch noch drei 16F676 dazu genommen. Die haben eigentlich nur 6 I/O mehr als der 12F675, braucht man gelegentlich, und den kann das PICkit1 gerade auch noch.
Hallo, Sascha schrieb: > Hallo, das Problem ist, die Abnützung des Flashs steigt mit der > Temperatur. > Wenn der Kontroller bei 0 Grad Celsius immer programmiert wird hält er > ewig und bei +85 Grad Celsius nur ein kleiner Bruchteil davon. Ich behaupte das Gegenteil! Für die Retention gilt: Die Ladung vom Floating Gate fließt über Defekte in der isolierenden Oxidschicht ab, deswegen folgt der Ladungsabfluss einer klassischen Kinetik und kann durch die Arrhenius-Gleichung beschrieben werden. Im Wesentlichen bedeutet das: Je niedriger die Temperatur desto weniger Ladungsabfluss, desto länger die Lebensdauer der gebrannten Information. Kalt = Lange Retention Aus genau den selben Gründen wird um so mehr Ladung in der Oxidschicht akkumuliert, je niedriger die Temperatur beim Schreiben / Löschen ist. Akkumulierte Ladung in der Oxidschicht kann zu neuen Defekten führen und damit zu einer verringerten Lebensdauer der geschriebenen Information oder sogar zum Kippen gelöschter Bits, so dass die entsprechenden Zellen dann als defekt gelten müssen. Höhere Temperatur beim Schreiben / Löschen führt dagegen zu einem beschleunigten Abfluss der Ladungen aus den Defekten (Charge Traps) und somit sinkt die Wahrscheinlichkeit, dass sich genug Ladung sammelt um neue Defekte zu bilden. Kalt = Stärkere Zerstörungen beim Schreiben / Löschen Ein Flash sollte also am besten 1. Warm geschrieben werden 2. Nach dem Löschen ein bisschen liegen um die charge traps zu leeren 3. Kalt gelagert / betrieben werden Das maximiert die Anzahl der möglichen Schreibzyklen und die Retentionsdauer. Oder? vlg Timm
:
Bearbeitet durch User
…erkennen ? Nein Man muss extern mitzaehlen… Bei EEPROMS zaehlt man doch auch oft mit wieviele Schreibvorgänge schon erfolgt sind. Wer etwas wissen will muss sich nur darum bemühen.
Arsenico schrieb: > Bei EEPROMS zaehlt man doch auch oft mit wieviele Schreibvorgänge schon > erfolgt sind. Wer tut das? Definiere "oft". Denn das Blöde am Mitzählen ist, dass das Zählregister selber ja wohl am heftigsten beansprucht ist...
Wilhelm F. schrieb: > An einem Board programmierte ich zum Test mal eine Endlosschleife, in > der der µC selbst Daten ins Flash schreibt, und wieder aus liest. Am > Feierabend vergaß ich ausgerechnet an dem Tag, den Strom abzuschalten, > und so flahte es am nächsten Tag noch. Da war aber auch noch nichts > passiert. Siehe Beitrag "Re: [ATMega] Programm aus externem EEprom laden" (und folgend): Stephan B. schrieb: > Nach ziemlich genau 10h Durchlauf mit ca. 256 pagewrites pro 5 Sekunden > (1.843.200 pagewrites total) treten vereinzelt erste Lesefehler auf.
Hatte man das bei Turbo Pascal 3 nicht "Overlay" genannt? ;-)
Azubi schrieb: > Kann mir einer vlt. sagen wie oder woran man erkennen kann wie oft einen > Atmege-Baustein geflasht wurde oder wie oft man ihn noch flashen kann? Was bei einigen AVRs mal ging (von dem ich auch weiss): Man konnte erkennen, ob die Fusebit mind. 1 mal seit Werkeinstellungen programmiert wurden. (Also quasi die Erkennung ob ein Chip neu ist oder nicht) Die unbenutzten Bits der EFuse kippten dann von 1 auf 0 und liessen sich auch nicht mehr ruecksetzen. MfG
Stephan B. schrieb: > Wilhelm F. schrieb: >> An einem Board programmierte ich zum Test mal eine Endlosschleife, in >> der der µC selbst Daten ins Flash schreibt, und wieder aus liest. Am >> Feierabend vergaß ich ausgerechnet an dem Tag, den Strom abzuschalten, >> und so flahte es am nächsten Tag noch. Da war aber auch noch nichts >> passiert. > > Siehe Beitrag "Re: [ATMega] Programm aus externem EEprom laden" (und folgend): > > Stephan B. schrieb: >> Nach ziemlich genau 10h Durchlauf mit ca. 256 pagewrites pro 5 Sekunden >> (1.843.200 pagewrites total) treten vereinzelt erste Lesefehler auf. Fast zwei Millionen, ja das ist schon so einiges! Bei mir waren es vielleicht ein paar Tausend. Und zwar war das folgendermaßen: Zum Test hatte ich einen LPC2000-er von NXP. Ungefähr einmal pro Minute flashte ich eine Page, auch nur mit 256 Werten, schrieb da sich ändernde Bitmuster hinein. Z.B. bei jedem Vorgang jedes Byte um 1 hoch zählen. Am HyperTerminal wollte ich es sehen, was da passiert. So einen Block von 256 Bytes ließ ich als Schnappschuß über die serielle Schnittstelle ans Terminal aus geben. Bei 16 Zeilen zu je 16 Bytes sieht man da leicht, wenn ein Byte nicht stimmt. Ich wollte auch nur ein paar Minuten lang wenige Ausgaben sehen, um zu schauen, ob meine Programmierung da richtig arbeitete, und dann wieder abschalten. Aber dann kam was dazwischen, was mich von dieser Sache ablenkte. Dann Feierabend, PC abgeschaltet, nur das Netzteil des Boards nicht. Wenn ich für drei Wochen in Urlaub gegangen wäre, hätte an meinem Arbeitsplatz auch niemand was bemerkt, oder angerührt. Wenn hier bei mir ein PIC12F675 fliegen geht, dann wird einfach ein neuer bestückt. Sind doch bloß 1,20€. Mit dem EEPROM darauf machte ich bislang nichts, ich glaube er hat 128 Bytes oder gar 256. Aber zum Schreiben in EEPROM macht man da auch eine Vergleichsroutine in die Schreibfunktion: Wenn das Byte schon gleich ist, wird es nicht geschrieben. Das beschleunigt eine Schreiberei auch noch, wenn man einen Block schreibt.
Wilhelm F. schrieb: > Aber zum Schreiben in EEPROM macht man da auch eine Vergleichsroutine in > die Schreibfunktion: Wenn das Byte schon gleich ist, wird es nicht > geschrieben. Das beschleunigt eine Schreiberei auch noch, wenn man einen > Block schreibt. Atmel hat da auch einige Vorschlaege dazu: Zum Einen einen Ringpuffer mit Sequenznummer - einfach um alle Stellen des EEPROMs zu benutzen und so die Haltbarkeit zu verteilen. Andererseits spezielle Routinen die nicht nur Veraenderungen detektieren (und nur dann schreiben), sondern auch pruefen ob Bits von 0 zu 1 gekippt werden muessen. Wenn dies nicht der Fall ist, wird der pageerase eingespart. MfG Stephan
Stephan B. schrieb: > Atmel hat da auch einige Vorschlaege dazu: Zum Einen einen Ringpuffer > mit Sequenznummer - einfach um alle Stellen des EEPROMs zu benutzen und > so die Haltbarkeit zu verteilen. Ja, sicher. Es gibt da eine Menge Überlegungen und Vorgehensweisen. Sowas habe ich sogar schon in 25 Jahre alten Büchern. Man kann Datensätze im Kreis herum schreiben, wenn man den Speicher als Ring sieht, und sie mit einem Gültigkeitsindex versehen, wenn man etwas Platz hat. Nur zum Beispiel.
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.