Hallo zusammen in die Runde. Ich bin neu hier und habe eine Frage zu den Bezeichnungen von Eprom`s. Da es für mich absolutes Neuland ist könnte es sein, das nochmal die ein oder andere Frage von mir kommt. Für eine Brandmeldeanlage möchte ich neue Eproms brennen zwecks Änderung der Kundendaten. Verbaut sind für Zusatztexte AM 27C64 und für Kundendaten NMC 27C64 Nun zu meiner Frage: Gibt es bist auf den Hersteller AM und NMC weitere Unterschiede? Es sind beides 12,5V Eproms. Ich hätte noch einige NMC 27C64BQ. Könnte ich diese auch nehmen. Irgendwie ist das mit den Bezeichnungen am Ende ( A , B , BQ , usw. ) sehr verwirrend Besten Dank Mario
> Nun zu meiner Frage: Gibt es bist auf den Hersteller AM und NMC weitere > Unterschiede? Beim auslesen im Geraet werden sie kompatibel sein wenn die Zugriffzeit stimmt. Beim programmieren waere es denkbar das jeder Hersteller seinen eigenen speziellen Brennalgorythmus verwendet und im schlimmsten Fall vergisst dann ein Eprom nach ein paar Monaten den Inhalt. In aller Regel sollte es aber funktionieren. Olaf
Mario W. schrieb: > Verbaut sind für Zusatztexte AM 27C64 und für Kundendaten NMC 27C64 Da sind bestimmt noch mehr Zahlen drauf, denn die 27CXX gibt es mit verschiedenen Zugriffszeiten (120ns, 150ns und höher). Ich würde die NMC Chips einfach mal ausprobieren.
Hallo Olaf Vergessen wäre aber schlecht. Ich werde es aber mal ausprobieren. Der Brenner kommet aber erst nächste Woche. Hallo Jim Ja die genau Bezeichnung Eprom für die Zusatztexte die lautet AM27C64-150DC 12,5V PGM 120297R
Wie schon geschrieben: funktionell sind die Hersteller egal, das Pinning und das elektrische Verhalten sind gleich, wenn die Zugriffszeiten stimmen. Den richtigen Programmieralgorithmus muss sich dein Programmer anhand der richtigen Typenbezeichnung raussuchen. Wobei die meisten 27C64 auch mit einem Standard Generic 27C64-Typen gehen sollten.
Hallo Wolfgang Das hört sich doch schon einmal gut an. Ich werde dann nächste Woche von meinem Erfolg oder Misserfolg berichten. Danke euch allen und schönes Wochenende
Das war irgendwann ein übles Wirrwarr mit den Programmieralgorithmen. Und man war/ist gut beraten, sich an die Herstellervorgaben zu halten. Man kann auch bei Programmiergeräten nicht unbedingt davon ausgehen, dass, wenn man die richtige Bausteinauswahl trifft, auch tatsächlich der richtige Algorithmus gewählt wird (wenn ich mich recht erinnere, hatte der erste Galep einen üblen Fehler bei Intel 27128). Und da kaum noch jemand Eproms benutzt, kann es auch durchaus länger dauern, bis ein solcher Fehler beim Programmiergerätehersteller ankommt. Auf den Hersteller selbst kommt es für deine Zielhardware nicht an, wenn die Zugriffszeit stimmt oder kleiner ist, funktionieren die alle.
Ich glaube mich an einen fast-brenn-algorithmus zu erinnern. Die Daten und Adressen repetitiv fuer eine Zeit (? 1ms .. 1us) anlegen und auslesen, ob's schon drin ist. Wenn man die Anzahl Schreib Zyklen ueberwacht, hat man eine Aussage ueber die Lebensdauer, Verbrauchtheit des Bausteins. Aeltere EEPROMs haben dann laenger gebraucht.
Hallo Auch euch beiden vielen Dank für die Antworten. Wie gesagt, ich werde Berichten wenn der Brenner da ist. Kommt aber erst nächste Woche. schönes Wochenende
Und genau in der Impulslänge lag das Problem, da haben viele was eigenes gekocht. Meist ging es dann so: -Zelle mit der vorgeschriebenen Impulszeit beschiessen -zählen, wieviele Schuss man dafür gebraucht hat, bis das erste Mal das korrekte Bitmuster gelesen werden konnte -dann nochmal nachbrennen, die einen mit der selben Anzahl der bishergebrauchten Programmierimpulse, andere mit der doppelten Anzahl, wahrscheinlich gabs auch welche mit 1,5facher Anzahl :-) Verschiedene fast/inteligent-Modes wurden eingeführt, um die Programmierzeiten im akzeptablen Rahmen zu halten. Irgendeiner kam auch mal auf die Idee, nicht einzelne Bytes zu fertig zu brennen, sondern den gesamten Speicher Zelle für Zelle mit kleinen Portionen zu befeuern und durch das Verteilen lokale Überhitzungen zu vermeiden. Stellte erheblich Anforderungen an das Programmiergerät und hat sich deshalb nie durchgesetzt. Ich glaube das war Hitachi. Die erste mehr oder weniger "Norm" waren knallharte 20ms pro Zelle, das war aber spätestens beim 64er kaum noch anzutreffen (8192*20ms=164s!), gut warm waren die dann auch, vielleicht kommt daher der Ausdruck "brennen" :-)
... eine kurze Leseprobe aus dem Franzis Elektroniktaschenbuch RPB 210 von Blank: Universeller EPROM-Programmer selbstgebaut Brennzeiten, Zugriffszeiten und Brennspannungen sind aber leider nicht immer gleich. Auf vielen EPROMs steht die Brennspannung aber hin und wieder drauf. Gruß Jobst
Tatsächlich, es waren 50ms. So kann die Erinnerung täuschen.... Das waren dann ja selbst für einen läppischen 2716 100s Programmierzeit, wie lästig.
H.Joachim S. schrieb: > Irgendeiner kam auch > mal auf die Idee, nicht einzelne Bytes zu fertig zu brennen, sondern den > gesamten Speicher Zelle für Zelle mit kleinen Portionen zu befeuern und > durch das Verteilen lokale Überhitzungen zu vermeiden. Das rührt noch aus Zeiten des greisen 2702 und 2708 mit 3 Betriebsspannungen und 26V Programmierspannung. Ab dem 2716 konnte man theoretisch mit einem einzigen 2 ms Impuls das Byte brennen. Da aus Kompartibilitätsgründen zu den alten Chips die Programmiergeräte die häppchenweise Programmierung mit mehreren Runden beherrschen mußten, bot sich dieses Verfahren auch bei den moderneren Typen an. Dazu kam dann noch die mögliche Zeitersparnis, wenn man nicht stumpf volle 2 ms programmierte, sondern in kleinen Häppchen programmierte und nachschaute, wann die Zelle ihren Inhalt hatte und noch eine Sicherheitsreserve nachschob.
H.Joachim S. schrieb: > Das waren dann ja selbst für einen läppischen 2716 100s Programmierzeit, > wie lästig. Ist aber, wie sich jetzt so langsam rausstellt, die haltbarste Methode. Ich hatte hier schon einige Probleme mit 27C256/27C512, die 'intelligent' gebrannt wurden und nach 20 Jahren vergesslich wurden, was bei den alten EPROMs in z.B. meinen 20-25 Jahre alten Boards mit 27C64 und 8031, die ich damals mit 50ms gebrannt habe, bis heute nicht passiert. Die o.a. EPROMs, die in den ersten Carcontrollern für E-Autos verbaut wurden, ersetze ich nun auch durch frisch mit 50ms gebrannte, denn wer will im Auto schon defekte Controller. Dauert zwar, aber ich muss ja nicht dabei sitzen.
Dürfte eher ein Problem der Strukturgrössen/Leckströme/Ladungsmengen sein als der eins der Brennmethode.
H.Joachim S. schrieb: > Dürfte eher ein Problem der Strukturgrössen/Leckströme/Ladungsmengen > sein als der eins der Brennmethode. Deswegen mögen es spätere CMOS-Typen auch nicht, mit 50 ms-Impulsen traktiert zu werden. Wer in Bezug auf Quickburn-Algorithmen zuviel Paranoia hat, der brennt halt zweimal. Das ist zwar nach Datenblatt nicht erlaubt, schadet aber in der Praxis nicht. Der eigentliche Programmiervorgang ist nach einer Runde beendet, da ja die Daten bereits beim ersten Versuch stimmen, das "Überbrennen" erfolgt aber trotzdem und erhöht so die Ladungsmenge im Gate. Aber nicht vergessen: heutige Flash-Speicher werden ebenfalls mit Quickburn-Algorithmen gebrannt! Das macht eine interne Statemachine, aber der Ablauf ist der gleiche.
Bitte 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.
