Forum: Mikrocontroller und Digitale Elektronik AVR: Lebensdauer des Flash-Speichers


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
Moin!

Ich hab mal eine Frage ob jemand Erfahrungswerte dazu hat. Merkt man den 
bevorstehenden Ausfall irgendwie, etwa wenn das Programm den Flash als 
"großen EEPROM" benutzt?

Oder wie oft kann man einen AVR neu flashen, also Änderungen am Programm 
vornehmen? Ich glaube zwar nicht, daß ich die 20.000mal, die im 
Datenblatt stehen, jemals erreiche... aber man weiß ja nie. Wenn man 
doch mal sehr viel an einem Programm testet und ihn dauernd neu 
beschreibt, wie sehr leidet der µC darunter und wie machen sich Ausfälle 
evtl. frühzeitig bemerkbar?

Kann man einen µC mit 20.000 oder mehr Flash-Zyklen noch zuverlässig 
einsetzen oder besteht dann ein erhöhtes Ausfallrisiko durch Bitfehler 
im Programm?

von abc. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

20.000 mal schreiben geht garantiert. Wenn du über die 20k Zyklen 
kommst, bist du außerhalb der Spec.. Da heisst es dann: kann 
funktionieren, muss aber nicht.

Die Frage, wie viele male bei deinem Chip wirklich gehen, wird dir hier 
keiner beantworten können. Da hilft leider nur ausmessen (Brennen, 
Rücklesen Vergleichen), allerdings ist der Chip dann hinüber. Und du 
hast dann keine belastbare Aussage, wie oft das beim nächsten Chip 
funktinonieren wird. Vor allem dann nicht, wenn der aus einer anderen 
Prod.Charge stammt.

Kurzum: bleib unter den 20k Zyklen, oder nimm' ein externes eeprom.

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Wenn man
> doch mal sehr viel an einem Programm testet und ihn dauernd neu
> beschreibt, wie sehr leidet der µC darunter und wie machen sich Ausfälle
> evtl. frühzeitig bemerkbar?

Wenn man beim AVRDUDE das Verify einschaltet, dann würde man irgendwann 
einen  Fehler bekommen weil Programm != Flash.

Fieserweise könnten die Flash Zellen auch "weich" werden, und so nach 
einiger Zeit den Inhalt verlieren.

Aber Du kannst Dir mal ausrechnen wie lange das dauern würde, ehe Du 
beim normalen Entwickeln auf 20k Programmierzyklen kommst. Meistens geht 
vorher was anderes kaputt, z.B. der Programmierstecker... ;-)

von Jim M. (turboj)


Bewertung
0 lesenswert
nicht lesenswert
Eventuell ist bei den üblicherweise angegbenen 10k-20k Zyklen ein 
gehöriger Sicherheitsaufschlag drauf (für 85°C Temperatur z.B).

Im LPC1768 Datenblatt steht beispielsweise min 10k, typisch 100k Zyklen 
(bei 25°C) drin.

von Michael U. (amiga)


Bewertung
1 lesenswert
nicht lesenswert
Hallo,

Jim M. schrieb:
> Aber Du kannst Dir mal ausrechnen wie lange das dauern würde, ehe Du
> beim normalen Entwickeln auf 20k Programmierzyklen kommst. Meistens geht
> vorher was anderes kaputt, z.B. der Programmierstecker... ;-)

das sind doch bei täglich 10x neu flashen noch nicht mal ganz 5 1/2 
Jahre... ;-)

Gruß aus Berlin
Michael

: Bearbeitet durch User
von Lutz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Kann man einen µC mit 20.000 oder mehr Flash-Zyklen noch zuverlässig
> einsetzen oder besteht dann ein erhöhtes Ausfallrisiko durch Bitfehler
> im Programm?

Auf einem Infineon-Seminar wurde diese Problematik mal behandelt. Danach 
kann man den Flash-Speicher weit über die garantierten Zyklen hinaus 
programmieren aber die nötige Dauer zur Programmierung einer Zelle 
steigt mehr und mehr an und der Langzeitspeichererhalt sinkt. Das ist 
also ein schleichender Prozess.

Lutz

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
Na wenn man das Programm für ein Teil entwirft und dieses oft auf dem 
Controller testet bzw. es für debug-Zwecke mit leichten Modifikationen 
immer neu schreibt, braucht man den Programmieradapter gar nicht erst 
abklemmen... Bei manchen Fehlern kommen da schnell einige Schreibzyklen 
zusammen.

Ein Fehler beim Verify ist klar, das war's dann für den Controller... 
daß Zellen irgendwann "weich" werden ist meine Befürchtung und deswegen 
diese Fragen hier. Ob man so einen "ausgiebig getesteten" Controller 
hinterher (wenn das Programm fertig ist) durch einen frischen ersetzen 
sollte oder ob das egal ist.

von Stephan B. (matrixstorm)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Ben

Vor vielen vielen Monden habe ich das mal ausprobiert:

Ab Beitrag "Re: [ATMega] Programm aus externem EEprom laden"

MfG

von Gerhard O. (gerhard_)


Bewertung
2 lesenswert
nicht lesenswert
Ich verschleißtestete mal vor Jahren den internen EEPROM in einem PIC 
18F452. Der soll dem Datenblatt nach 1e6 Schreib Zyklen aushalten. Der 
FLASH soll 1e5. Das Test Programm brachte es auf 14e6 Schreibzyklen im 
EEPROM bevor Fehler auftraten. Die Fehler betrafen auch links und rechts 
einige benachbarte unbeschriebene Speicherzellen. Langfristig würde ich 
mich bei Millionen von Schreibvorgängen dann auch nicht mehr darauf 
verlassen wollen auch wenn sie anfangs noch richtig funktionieren. FRAM 
ist da mit 1e15 Schreibvorgängen deutlich überlegener.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Ob man so einen "ausgiebig getesteten" Controller
> hinterher (wenn das Programm fertig ist) durch einen frischen ersetzen
> sollte oder ob das egal ist.

Ich sage ja...
Auch wenn ich bei noch keinem AVR das Flash tot programmiert habe, 
kommen mir keine gebrauchten Test-AVR in die endgültige Schaltung.

von Max D. (max_d)


Bewertung
0 lesenswert
nicht lesenswert
Ich hab von meinen "Lieblingstypen" (t85, t44, m88) jeweils ein 
"Debuggingopfer". Das kommt in die zu entwickelnde Schaltung rein und 
frisst da die Schreibzyklen. Wenn das Proggi steht wird der Käfer 
getauscht und der "jungfräuliche" Controller einmalig gebrannt.
Diesen Luxus kann man sich mit DIPs ja leicht gönnen. Bei SMD sieht das 
anders aus, aber da würde ich u.U. eh 1-2 Testplatinen planen, weil 
irgendwann im Entwicklungsverlauf kommt man mal mit einer höheren 
Spannung an einen Pin (z.B. wenn im Multi die Kabel noch im 
Amperebereich stecken) und dann ist der uC futsch.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Max D. schrieb:
> Ich hab von meinen "Lieblingstypen" (t85, t44, m88) jeweils ein
> "Debuggingopfer". Das kommt in die zu entwickelnde Schaltung rein und
> frisst da die Schreibzyklen. Wenn das Proggi steht wird der Käfer
> getauscht und der "jungfräuliche" Controller einmalig gebrannt.

Das halte ich für wenig sinnvoll und mache es folglich auch anders. 
Selbst bei großen Programmen habe ich noch nie mehr als vielleicht 100 
Flash-Zyklen gebraucht. Das ist so deutlich von den garantierten 10.000+ 
(und auch den früher nur 1000) Zyklen weg, daß ich genau gar keine 
Skrupel habe, den µC danach mit dem finalen Programm in der Schaltung zu 
lassen. Zumal es ja nur Hobby ist und demzufolge alles Einzelstücke.

Ich hätte im Gegenteil Bedenken, das "Debuggingopfer" dann doch mal aus 
Versehen irgendwo zu verbauen. Oder ich würde mir bei einer Fehlfunktion 
meiner Schaltung Gedanken machen, ob vielleicht mein Opferchip jetzt 
gerade die Hufe hochgerissen hat.

Der einzige Weg, wie man beim Entwickeln realistisch die Lebensdauer des 
Flash knacken kann, ist Debuggen per debugWIRE mit Breakpoints. Denn für 
einen Breakpoint wird da das Flash modifiziert. Und natürlich, wenn man 
das Flash als EEPROM mißbraucht. Aber das ist dann ja eigene Dummheit.

von Arrhenius (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Moin!

> Kann man einen µC mit 20.000 oder mehr Flash-Zyklen noch zuverlässig
> einsetzen oder besteht dann ein erhöhtes Ausfallrisiko durch Bitfehler
> im Programm?

Kannst ja mal eine Page 20k beschreiben und über die Winterzeit auf 'n 
Ölbrenner lagern..

von Manfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
>> Wenn das Proggi steht wird der Käfer getauscht
>> und der "jungfräuliche" Controller einmalig gebrannt.
> Das halte ich für wenig sinnvoll und mache es folglich auch anders.
> Selbst bei großen Programmen habe ich noch nie mehr als vielleicht 100 
Flash-Zyklen gebraucht.

Meine Arduino-Software zähle ich hoch, die meldet sich mit Datum & 
laufender Nummer, entweder auf dem Display und / oder der seriellen 
Schnittstelle. Da ich es nicht von Beginn an so gemacht habe, ist es bei 
nur drei Projekten nachvollziehbar.

Das eine ist bei 378, die anderen sind bei 152 und 162 angekommen. Egal, 
auch das ist weit genug weg von der Spezifikation und ich sehe keinen 
Grund, die ICs zu wechseln.

von Stephan B. (matrixstorm)


Bewertung
0 lesenswert
nicht lesenswert
Hallo

Die ATmegas und ATXmegas machen kein wear leveling im Flash, d.h. die 
Adress-Seitenzuordnung ändert sich nicht.
Der Flash wird zudem seitenweise gelöscht und beschrieben (SPM_PAGESIZE) 
- es verschleißen also nur solche Seiten.
Nutzt man Teile des Flash also als NVM und belässt die Adressbereiche 
gleich und PAGESIZE aligned, muss man keine Angst haben das der 
Programmcode korruped...
Korruptionen im als "EEPROM" zweckentfremdenden Bereich kann man mit 
fehlererkennenden Codes / CRCs detektieren - ggf. dann auf andere freie 
Bereiche ausweichen...

Ausserdem sind Bitdefekte im Flash nur 0-Werte die eigentlich mal 
1-Werte waren - ggf. kann man mit dieser Information noch anders gegen 
mitigieren...

: Bearbeitet durch User
von michael_ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael U. schrieb:
> das sind doch bei täglich 10x neu flashen noch nicht mal ganz 5 1/2
> Jahre... ;-)

Hast du da auch Freitag, Samstag, Sonntag, Krankheit, Feiertage, Urlaub, 
usw. mit beachtet :-)

von Max D. (max_d)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Das halte ich für wenig sinnvoll und mache es folglich auch anders.
> Selbst bei großen Programmen habe ich noch nie mehr als vielleicht 100
> Flash-Zyklen gebraucht. Das ist so deutlich von den garantierten 10.000+
> (und auch den früher nur 1000) Zyklen weg, daß ich genau gar keine
> Skrupel habe, den µC danach mit dem finalen Programm in der Schaltung zu
> lassen. Zumal es ja nur Hobby ist und demzufolge alles Einzelstücke.

Mein Aufwand den Käfer zu tauschen ist Sekunden und dafür bin ich 
beruhigt, dass ich die besten Chancen auf einen langen Erhalt der 
Programmierung habe. Zumal die Kombination 20k Zyklen + 10 Jahre lagern 
in der Praxis der Großkunden eher selten vorkommt und daher von dem 
Hersteller evtl. etwas stiefmütterlich behandelt werden könnte.

> Ich hätte im Gegenteil Bedenken, das "Debuggingopfer" dann doch mal aus
> Versehen irgendwo zu verbauen. Oder ich würde mir bei einer Fehlfunktion
> meiner Schaltung Gedanken machen, ob vielleicht mein Opferchip jetzt
> gerade die Hufe hochgerissen hat.

Das "Opfer" ist dick mit weißen Edding markiert um Fehleinbau zu 
verhindern. Desweiteren dürfte es weit jenseits der 20k Zyklen eine 
"retention time" von den paar Minuten haben um das Proggi zu testen. 
Meistens verlier oder grill (wobei da AVRs ja echt hart im Nehmen sind) 
ich den Käfer eh lange bevor der auch nur 10k knacken dürfte.

von Klaus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Max D. schrieb:
> Mein Aufwand den Käfer zu tauschen ist Sekunden

Du bist aber wirklich gut im Auslöten. Ich bin da eher ungeschickt und 
reiß auch schon mal ein Pad ab. Daher vermeide ich das Tauschen von 
Chips.

MfG Klaus

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
>> Mein Aufwand den Käfer zu tauschen ist Sekunden
> Du bist aber wirklich gut im Auslöten.

Bei DIP mit Fassung muss man nicht löten...

von Klaus (Gast)


Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> Bei DIP mit Fassung muss man nicht löten...

Meinst du jetzt DIP in Wackelkontakt ist besser als ein paar Tausend 
Programmierzyklen eingelötet?

MfG Klaus

von René F. (therfd)


Bewertung
0 lesenswert
nicht lesenswert
Das Problem an sich ist eigentlich nicht das flashen sondern die 
Datenerhaltung, mit jeder Programmierung nimmt die Lebensdauer weiter 
ab, die Chiphersteller spezifizieren wie lange die Daten auf dem Chip 
erhalten bleiben solange eine gewisse Anzahl an Flash-Cycles eingehalten 
wird. Wir führen im Labor regelmäßig Langzeit-Flash-Orgien durch (Loop 
„Flashen -> Verify“) und bis jetzt war noch nie ein Chip so stark 
zerflasht das er das darauf folgende Verify nicht bestanden hätte. In 
kritischen Bereichen wie der Automotive Industrie wird auch mit Margin 
Levels gearbeitet um die Programmierung zu bewerten.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
Danke euch für die ganzen Antworten und Anregungen.

Zeigt mir auf jeden Fall, daß doch einige Leute Überlegungen in die 
gleiche Richtung anstellen. Ich denke dann werd ich nach dem Testen auch 
einen frischen Controller in die Schaltung einsetzen.

Auch wenn die AVRs wirklich hart im Nehmen sind, es nutzt mir nichts 
wenn der IC zwar das Verify übersteht, aber nach ein paar Monaten 
Alzheimer bekommt.

Bei meinen Schaltungen (außer den "in der Produktion gebauten") sind 
auch alle µCs gesockelt. Erstens verstecke ich da gerne sowas wie 
Entstörkondensatoren im Sockel (da kommt man problemlos nahe an die 
Pins) und falls man doch mal einen µC zerbombt 40 Pins wieder 
rauspopeln... Nee!!

von Klaus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Bei meinen Schaltungen (außer den "in der Produktion gebauten") sind
> auch alle µCs gesockelt.

Und da stellt sich mir die Frage, was passiert wahrscheinlicher: ein Bit 
im Flash kippt oder ein Pin vergammelt im Sockel. Und ein wirklich guter 
Sockel ist leicht teurer als der µC.

MfG Klaus

von Curby23523 N. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was ist eigentlich das ursprüngliche Problem? Nach der Entwicklung 
verwendet man sowieso immer jungfräuliche Chips für neue Boards.

Ich habe eher die Befürchtung, dass du irgendwelche Daten in hohen Raten 
im Flash / EEprom abspeicherst und deswegen die Frage stellst. Das wäre 
der falsche Ansatz.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
> Meinst du jetzt DIP in Wackelkontakt ist besser als ein paar Tausend
> Programmierzyklen eingelötet?

Die wackeln erst nach einigen zig Steckzyklen, und so oft sollte man ein 
IC nicht auswechseln müssen. Wenn doch -> Textool Sockel.

Ich habe mit den teureren runden "gedrehten" Fassungen schlechtere 
Erfahrungen gemacht, als mit den normalen.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
Also normalerweise vergammeln keine Pins im Sockel. Da muß man sich 
schon Mühe geben und das Ding extrem schlecht behandeln, damit das 
passiert. Regelmäßig duschen oder so... Ich hatte noch nie 
Kontaktprobleme mit gesockelten µCs.

Das ursprüngliche "Problem" geht dahin, daß ich bei meiner AlarmSau sehr 
viel auf dem Controller selber teste, da ich mich erst mit dem GSM-Modul 
anfreunden muß bzw. musste. Ich weiß nicht wieviele Tausend 
Schreibzyklen der µC durch die ganze Testerei und Fehlersuche beim 
Entwurf der GSM-Funktionen in die Fresse bekommen hat ... gefühlt waren 
es einige. Ich habe auch neue USART-Subroutinen für das Ding geschrieben 
(mehrere Puffer) damit ohne Flusssteuerung keine Daten verlorengehen. 
Die sind am Anfang auch nicht perfekt gelaufen. Assembler ist cool, aber 
zum Debuggen braucht man eben länger.

Inzwischen ist das Grundgerüst von dem Programm aber fertig, das Ding 
kann mit der Hardware umgehen, SMS senden und empfangen (bzw. darauf mit 
einem Statusbericht reagieren). Die Hauptschleife mit der Verbindung zum 
Terminal läuft auch (z.B. periodische Statusmeldungen auf dem 
Terminal-Display). Die Programmierung des Terminals war ein Witz 
dagegen. Jetzt kommt "nur noch" die Benutzerführung bzw. menügesteuerte 
Konfiguration. Das ist nochmal eine Ecke Code und mehr Text, aber das 
wird der Controller schon noch überstehen.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Das ursprüngliche "Problem" geht dahin, daß ich bei meiner AlarmSau sehr
> viel auf dem Controller selber teste, da ich mich erst mit dem GSM-Modul
> anfreunden muß bzw. musste. Ich weiß nicht wieviele Tausend
> Schreibzyklen der µC durch die ganze Testerei und Fehlersuche beim
> Entwurf der GSM-Funktionen in die Fresse bekommen hat ... gefühlt waren
> es einige.

Das ist ein "Problem", wegen der "gefühlten" Anzahl. Man neigt dazu, 
grob daneben zu schätzen. Ich finde es schade, daß avrdude die Anzahl 
der Programmierzyklen nicht mehr im EEPROM verwalten kann (Option -y). 
Wenn man das alles aus einem Makefile heraus macht, dann kann man sich 
abhelfen, indem man den Zähler in einem eigenen File hält und in der 
Regel für das Flashen hochzählt. Z.B. so:
1
# Program the device.
2
flash: $(TARGET).hex cycles.txt
3
  $(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FLASH)
4
  @expr `cat cycles.txt` + 1 > cycles.txt
5
  @echo -n "number of flash cycles: "
6
  @cat cycles.txt
7
8
cycles.txt:
9
  @echo 0 > cycles.txt

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
Yep da hast Du höchstwahrscheinlich Recht. Vielleicht sinds real "nur" 
ein paar hundert Schreibzyklen. Schade, daß es da nirgendwo einen Zähler 
im AVR-Studio oder auf dem IC selber gibt.

Vielleicht baue ich beim nächsten Programm bzw. nächsten frischen 
Controller mal eine Funktion an den Start, die eine Checksumme vom 
Programm errechnet und einen Zähler im EEPROM hochzählt wenn sich die 
Checksumme geändert hat.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Das gleiche Programm drüber Flashen zählt aber auch als 1 Zyklus.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
Yep, aber das sollte verschwindend selten vorkommen. Selbst wenn man 
beim Debuggen nur ein einziges Register verändert oder eine einzelne 
Ziffer, fällt das schon bei einer einfachen Prüfsumme auf.

Wenn ich mit dem Programmer einen Reset erzeugen möchte oder so, flashe 
ich auch nicht das gleiche Programm drüber, sondern lese die 
Chipsignatur aus. Das erzeugt auch einen Reset.

Ich würde die Methode nicht "exakt" nennen, aber "genau genug".

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
> Meinst du jetzt DIP in Wackelkontakt ist besser als ein paar Tausend
> Programmierzyklen eingelötet?

Ich weiß nicht, was du mit "DIP in Wackelkontakt" meinst - billige 
Breadboards vielleicht?

Wir reden hier von vielleicht 3 Steckzyklen im Sockel (IC rein, 
Entwicklung, IC raus, neuer IC rein, fertig), das kann so ein Sockel 
problemlos ab.

von Manfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Also normalerweise vergammeln keine Pins im Sockel. Da muß man sich
> schon Mühe geben und das Ding extrem schlecht behandeln, damit das
> passiert. Regelmäßig duschen oder so... Ich hatte noch nie
> Kontaktprobleme mit gesockelten µCs.

Du kaufst anständige Sockel?

Und da kommt der Grund:
Klaus schrieb:
> Und ein wirklich guter Sockel ist leicht teurer als der µC.

Ich habe genug DIL-Sockel gesehen, die schon fast aus Tüte heraus 
Aussetzer fabrizieren, dafür aber billig sind.

In ganz schlechter Erinnerung ist mir eine Commodore-Floppy 3040 für 
damals mehrere tausend DM, da habe ich tatsächlich alle Sockel 
gewechselt und danach keine Abstürze mehr gehabt.

von Soul E. (souleye) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Manfred schrieb:

> In ganz schlechter Erinnerung ist mir eine Commodore-Floppy 3040 für
> damals mehrere tausend DM, da habe ich tatsächlich alle Sockel
> gewechselt und danach keine Abstürze mehr gehabt.

Ahh, das waren noch Zeiten! Einzelfederkontakte mit Abstützung auf dem 
Plastikrahmen. Apple hat sowas auch verbaut, da musste man einmal im 
Jahr alle ICs in die Fassungen zurückdrücken. Die haben sich langsam 
rausgearbeitet.

Damals gab es den "two inch quick fix": Das Gerät 5,08 cm anheben und 
auf den Tisch fallen lassen. Das hat die meisten Wackelkontakte behoben. 
Gerade mit den alten CBM-Kisten in ihren Gusseisen-Gehäusen machte das 
Freude.

von Manfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
soul e. schrieb:
> Manfred schrieb:
>> In ganz schlechter Erinnerung ist mir eine Commodore-Floppy 3040 für
>> damals mehrere tausend DM, da habe ich tatsächlich alle Sockel
>> gewechselt und danach keine Abstürze mehr gehabt.
>
> Ahh, das waren noch Zeiten! Einzelfederkontakte mit Abstützung auf dem
> Plastikrahmen.

Du kennst die Sockel also ... dieser Scheißdreck ist noch heute am 
Markt!

> Damals gab es den "two inch quick fix": Das Gerät 5,08 cm anheben und
> auf den Tisch fallen lassen. Das hat die meisten Wackelkontakte behoben.

Habe ich nie gehört, aber nett :-)

> Gerade mit den alten CBM-Kisten in ihren Gusseisen-Gehäusen machte das
> Freude.

Ich hätte es mich trotzdem nicht getraut.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
> "two inch quick fix"
> Das hat die meisten Wackelkontakte behoben.
Oder für den vorzeitigen Feierabend gesorgt
wenn danach gar nichts mehr geht.

Also ich hatte ehrlich nie Problem damit, auch nicht bei meinem C64 und 
seiner Floppy. Allerdings kaufe ich für meine Platinen auch immer 
Präzisionssockel. Die paar Cent zu sparen macht für mich nicht so viel 
Sinn und in geprüften Schaltungen bzw. Serienproduktion würde ich den 
Controller aus Kostengründen vermutlich verlöten, bzw. dann ist es 
höchstwahrscheinlich sowieso eine SMD-Version.

Andere Frage, die passt hier gerade: Gibts auch Testsockel für SO-8 oder 
TQPF-44 (oder wie das heißt) oder so, wo man einen AVR nur kurz zum 
Programmieren reinschmeißen und hinterher einfach wieder entnehmen kann, 
um ihn dann programmiert irgendwo aufzulöten?

von Max D. (max_d)


Bewertung
0 lesenswert
nicht lesenswert
Ben B. schrieb:
> Andere Frage, die passt hier gerade: Gibts auch Testsockel für SO-8 oder
> TQPF-44 (oder wie das heißt) oder so, wo man einen AVR nur kurz zum
> Programmieren reinschmeißen und hinterher einfach wieder entnehmen kann,
> um ihn dann programmiert irgendwo aufzulöten?

Gibt es.
Einfach mal nach "TQFP44 ZIF" in aliexpress suchen. Der Chinese will so 
10-15€ haben.
SOP8 kostet knappe 5.

von René F. (therfd)


Bewertung
0 lesenswert
nicht lesenswert
Solche Sockel gibt es für die verschiedensten Bauformen, auch 
Kontaktierung von exposed Pads. Hersteller wären zum Beispiel 
Plastronics, Yamaichi und Enplas, Standardbauformen sind erschwinglich, 
exotischeres kann sehr schnell sehr teuer werden.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
Danke!

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




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

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