wie oft kann man einen pic-prozessor programmieren? a) 1000 b) 1000000 c) 10^20
futz schrieb: > wie oft kann man einen pic-prozessor programmieren? Das kann dir keiner so genau sagen. Die garantierte Mindestzahl an Programmierzyklen verrät üblicherweise der Hersteller. Lösungen a) und c) treffen bestimmt nicht zu
futz schrieb: > wie oft kann man einen pic-prozessor programmieren? Kann man in seinem Datenblatt nachlesen.
Wolfgang schrieb: > Lösungen a) und c) treffen bestimmt nicht zu bestimmt ist unbestimmt man kann weniger und mehr programmieren, die Frage ist nur ab wann das Programm nicht mehr ankommt oder drin bleibt :)
LDSD! (RTFM ist blöd, weil 'F' außer für Nerds und andere Verklemmte doch eher was Schönes ist) Was der Hersteller garantiert, steht beim PIC (und auch bei AVR) auf der ersten Seite des Datenblatts. Guckst du! Ob es auch 1,01...10 mal so oft funktionieren KÖNNTE, ist völlig schnurz und piepe (scheißegal), weil man sich nicht drauf verlassen kann! PUNKT, FERTIG UND AUS DIE MAUS.
Joachim B. schrieb: > man kann weniger und mehr programmieren, die Frage ist nur ab wann das > Programm nicht mehr ankommt oder drin bleibt :) Zu Programmieren gehört zumindest, dass nach dem Schreiben in den Flash auch ein Verify funktioniert.
Hi Nicht direkt hauen ;) Trotzdem sei es mir doch gewährt, meine µC so oft zu brennen, wie mir beliebt? Wenn das Brennen scheitert, kann ich den Rechenknecht immer noch in die ewigen Jagdgründe meiner Mülltonne verfrachten. Und, seit Euch sicher, KEINER hier (oder sonst wo) zählt die Programmier-Zyklen mit. Bis auf ein paar tausend µC, Die für das Allgemeinwohl tot geflasht wurden, wird die Anzahl Nirgends bekannt sein. Wenn's geklappt hat, wunderbar! Wenn nicht Fehlersuche - zu 99,999% (vll. ein paar 9er mehr) wird Spannung, Takt oder Kontakt 'falsch' gewesen sein - wegschmeißen geht da aber immer noch, will hier Keinem vorschreiben, wie lange Er Seinen µC behalten muß ;) MfG und 'jeweils ein Bit breit Flash im µC Platz' ... oda so
:
Bearbeitet durch User
Wolfgang schrieb: > Zu Programmieren gehört zumindest, dass nach dem Schreiben in den > Flash auch ein Verify funktioniert. Und nach 10 Jahren sollte das Programm möglichst auch noch im Flash sein. Im worst case auch noch bei erhöhter Umgebungstemperatur. Je öfter eine Speicherzelle geschrieben wird, desdo mehr leckt die Gateisolation, da beim Durchtunneln der Gateisolation zum Floatingate eben auch eine Materialmigration im atomaren Maßstab stattfindet. Es kann durchaus sein, das du für Labortests den Flash auch 10 oder 100x soviel, wie garantiert beschreiben kannst, aber dann ist auf ihn nicht viel mehr Verlass, als auf Birkenrinde ;-)
Na klar zähl ich auch nicht mit. Aber wenn ich 1/4 Jahr lang täglich 50 neue Prog-Versionen in den µC schiebe, sind das unter 5000. Und wenn es in einem halben Jahr (10.000 Flashs) immer noch nicht fuktioniert, ist es doch egal, ob der µC da noch mitmacht... DAS WIRD NIX! Somit erschien mir die Frage eher als "was geht denn nu?", oder "hat meiner mehr geschafft, als deiner?". - Also Unsinn.
Der ATmega8 kann laut Datenblatt zehntausend mal neu beschrieben werden, das Flash RAM hunderttausend mal. Es wird also für die meisten Aufgaben knapp reichen. Steht übrigens auf der allerersten Seite des Datenblattes.
Danke. Im Datenblatt sehe ich aber trotzdem keine Angabe darüber. Thomas E. schrieb: >> PUNKT, FERTIG UND AUS DIE MAUS. > > Genau. Genau.
Wolfgang schrieb: > Zu Programmieren gehört zumindest, dass nach dem Schreiben in den > Flash auch ein Verify funktioniert. sicher? ich erlebe fast täglich das Programmiertes nicht verfiziert wird, sei es in Programmen oder Webinterfaces wo man 40 Zeichen 3-zeilige Eingabemasken hat die auf Adressaufkleber nicht übernommen werden. Dann schreibe sollte verfiziert werden :)
:
Bearbeitet durch User
futz schrieb: > Im Datenblatt sehe ich aber trotzdem keine Angabe darüber. Dann musst du mal einen Prozessor nenne. Sonst kann dich keiner mit der Nase auf die Zeile stoßen.
Patrick J. schrieb: > Und, seit Euch sicher, KEINER hier (oder sonst wo) zählt die > Programmier-Zyklen mit. Na, ein bißchen schon. Mein Versionierungs- und Quelltextsicherungsprogramm zählt bei jedem Compilieren und dem damit verbundenen Speichern immer eins hoch. Und da ich fast ausschließlich im Debug-Modus arbeite, erhalte ich dadurch auch eine zumindest einigermaßen brauchbare Aussage darüber, wie oft der Controller geflasht wurde. Die Deadline von 10000 Zyklen bei den AVRs habe ich allerdings noch nie auch nur annähernd erreicht. Auch nicht bei großen Projekten, an denen ich monatelang gesessen habe und die immer wieder rausgekramt und geändert wurden.
Hi, Wolfgang schrieb: > futz schrieb: >> wie oft kann man einen pic-prozessor programmieren? > > Das kann dir keiner so genau sagen. Die garantierte Mindestzahl an > Programmierzyklen verrät üblicherweise der Hersteller. > > Lösungen a) und c) treffen bestimmt nicht zu Was der Controllerhersteller angibt ist, bis auf ganz wenige Ausnahmen, nicht die garantierte Zahl, sondern die üblicherweise zu erwartende Zahl an Schreibvorgängen ohne nennenswerten Funktionsverlust. Die Wahrscheinlichkeit das genau der Controller den man gerade verwendet diese Zahl durchhält ist sehr hoch. Aber es ist dennoch immer möglich das man jetzt genau diesen einen von tausenden Controllern erwischt hat der schon beim dritten mal wiederbeschreiben das Zeitliche segnet. Wobei es gibt ja eine ganze Reihe von Pic Controllern wo man die möglichen Schreibzyklen wirklich absolut genau festlegen kann... Alle "C" typen mit Ausnahme von des 16C83 und 16C84 sowie den Controllern mit JW als Suffix. Da ist die Zahl der möglichen Programmiervorgänge ziemlich exakt "EINS". (Wenn man genau nimmt statistisch ein Hauch unter 1 durch einige wenige DOA Controller) Aber auch wenn viele davon noch beziehbar sind ist das Technik von Vorgestern ;-) Und das die Lösung "a" (1000 Schreibvorgänge) für Pic Controller nicht zutreffend ist, darauf solltest du nicht wetten - die Wette würdest du verlieren! Denn das ist genau die Zahl die Microchip für seine ersten Flash Typen im Datenblatt angibt. (PIC16F84 OHNE A!) http://www.microchip.com/wwwproducts/en/PIC16F84 Interessanterweise ist dessen Vorgänger, der noch mit EEPROM Programmspeicher ausgestattet war, mit einer Million Schreibzugriffen gelistet. Ich habe damals in meiner jugendlichen Naivität (gerade im ersten LJ in der Ausbildung zum KE-Inf mit den PICs angefangen) mir deshalb tatsächlich darum Sorgen gemacht und extra getrennt zwischen den paar PIC16C84 die ich hatte und den schon leichter/billiger zu beschaffenden PIC16F84. Experimentiert mit dem 16C Type, wenn es dann lief kam in die fertige Schaltung der 16F. Aber ich habe nie einen kaputtgeflasht, dafür ettliche auf anderen Weg gekillt. Aber auch diese Varianten der Flash Technologie sind völlig veraltet. Schon dessen Nachfolger der 16F84A wird mit 10k Schreibvorgängen beworben. Jetzt, FAST 20 Jahre später, sind die aktuellen Typen wie der 16f1459 immer noch bei 10k Schreibvorgängen für den normalen Programmspeicher und 100k Schreibvorgängen (hier tatsächlich mit der Bemerkung Minimum) für einen kleinen Teil des Flashspeichers der zwar als Programmspeicher genutzt werden kann, aber in erster Linie als Ersatz für den EEPROM speicher dienen soll. Interessanterweise wird vorne auf dem DS nur noch mit den 100k geworben. DAs der größte Teil des Flash-Speichers immer noch bei "nur" 10k ist steht erst ganz hinten klein in den technischen Daten... Thomas E. schrieb: > Die Deadline von 10000 Zyklen bei den AVRs > habe ich allerdings noch nie auch nur annähernd erreicht. Auch nicht bei > großen Projekten, an denen ich monatelang gesessen habe und die immer > wieder rausgekramt und geändert wurden. Durch "normale" Entwicklungs- oder auch Updatevorgänge wird wohl heute niemand der es nicht ganz gezielt darauf anlegt auch nur in die Nähe der typischen Werte kommen. Von einem automatisierten Stresstest abgesehen müsste man dazu schon Jahrelang nicht nur mit praktisch einem einzigen Controllertyp arbeiten sondern auch noch immer genau denselben Controller durchgehend für alle Projekte benutzen (Ohne das der zwischendurch durch andere Dinge beschädigt wird) Aber die Zahl ist dennoch alles andere als Unwichtig und es ist schon sehr wichtig die bei vielen Dingen im Hinterkopf zu haben: Immer mehr Controller mit "self Write" Fähigkeiten haben gar keinen EEprom Speicher für nichtflüchtige Zwischenspeicherung mehr. Wo man früher den EEProm (mit 1M bis 10M an zu erwartenden Schreibvorgängen vor Funktionsverlust) genutzt hat wird heute einfach der noch freie Teil des Programmspeichers genutzt. Wenn dann periodisch Werte durch das Programm nichtflüchtig im Speicher abgelegt werden kann das je nach Intervall bei ungünstiger Implementierung schon nach kurzer Zeit den Flash zerschießen. Bei einer Speicherung pro Stunde ist dann bereits nach einem Jahr und zwei Monaten im Betrieb die Zahl überschritten. Da haben sich Anfangs so einige mit ins Knie geschossen. Die Werte einfach periodisch Weggeschrieben. Selbst bei 1x die Minute würde das ein PIC mit EEPROM Datenspeicher rund 20Jahre bei geringfügig neueren Controllern auch 200 Jahre mitmachen. Also wurden die Werte nur einfach weggeschrieben. Jede Schutzmaßnahme war verschwendete Zeit/Programmspeicher. Schließlich wurden viele dieser Programme ursprünglich sogar noch in ASM für mit EPROM und RAM geizende Controller geschrieben. Dann wurde der Controller auf was aktuelles umgestellt, die Programmroutine unverändert beibehalten und noch in der Gewährleistungszeit sind die Geräte ausgefallen... Dumm gelaufen! 10k ist also nicht wirklich viel. Auch die 100k des kleinen "hochzuverlässigen" Bereichs in einigen neuen Controllern ist verglichen mit den 10M bei den nicht ganz so alten Pics mit EEPROM Speicher nicht wirklich viel. Wenn man also nicht nur Kalibrierdaten die sich vielleicht alle paar Monate nach Neukalibrierung mal ändern oder sogar nur einmalig "im Werk" erzeugt werden wegspeichern muss sondern mit periodischen Schreibzugriffen im nichtflüchtigen Speicher arbeiten will sollte man sich bei Flash schon sehr sorgfältig überlegen zu wievielen Schreibvorgänen es kommen könnte und ab einer gewissen Häufigkeit dann wie man das gut implementiert. Die erforderlichen Maßnahmen können dann von einer einfachen Überprüfung ob überhaupt ein Schreibzugriff nötig ist (keine Änderung im Vergleich zum alten Wert) bis hin zu einem komplexen wear Leveling Algorithmus gehen. Gruß Carsten
:
Bearbeitet durch User
Carsten S. schrieb: > Was der Controllerhersteller angibt ist, bis auf ganz wenige Ausnahmen, > nicht die garantierte Zahl, sondern die üblicherweise zu erwartende Zahl > an Schreibvorgängen ohne nennenswerten Funktionsverlust. > ... > Aber es ist dennoch immer möglich das man jetzt genau diesen einen von > tausenden Controllern erwischt hat der schon beim dritten mal > wiederbeschreiben das Zeitliche segnet. Wie viele von einer Million Controllern fallen denn nach drei mal Programmieren aus, wenn der Hersteller im Datenblatt bspw. angibt "100,000 write Flash endurance (minimum)" - wohlgemerkt "minimum". Kennst du dazu belastbare, statistische Auswertungen? Ein Hersteller wird sich hüten, Produkte rauszuschicken, von denen er weiss, dass eine nennenswerte Anzahl die als "minimal" genannte Angabe von Zyklen nur zu einem Bruchteil erreicht.
Angehängte Dateien:
-
SLAA392-Figure2.png
12 KB
Gerald B. schrieb: > Und nach 10 Jahren sollte das Programm möglichst auch noch im Flash > sein. Im worst case auch noch bei erhöhter Umgebungstemperatur. Manche Hersteller verraten auch, wie sich die Temperatur auswirkt, wie man das testen kann, und wann man den Flash regelmäßig neu schreiben sollte, z.B.: http://www.ti.com/lit/pdf/slaa392 http://www.ti.com/lit/pdf/slaa334 Und zwischen den Flash-Zellen verschiedener Herstellern gibt es keine großen Unterschiede.
:
Bearbeitet durch User
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.