Archiv verlassen und diese Seite im Standarddesign anzeigen : Was ist der Unterschied zwischen eeprom und flash ???
Ich bin zwar kein Neuling in elektronik.
Doch eine Sache bleibt mir unklar:
Viele microcontroler haben flash speicher und auch eeprom.
Beim Nachschlagen wird Flash speicher meistens als anderer Typ von eeprom beschrieben.
Wo ist da dann der Unterschied ???
Danke in vorraus.
slm
Hallo slm
Ich weis nicht wie weit du in die Details gehen möchtest, aber Flash und EEPROM sind 2 ganz verschiedene Speichertechnologien und es gibt historsche Gründe für die Koexistenz.
Den Flash Speicher muß man sich ursprünglich als Ersatz für für Masken-programmierten Speicher, sprich ROM, sprich read only memory, oder auch dem EPROM, sprich "electrical programmable Read Only memory".
Die billigste Variante des Speichers auf einem IC sind die ROMS, also Maskenprogrammierte Speicher. Hier ist die höchste Dichte zu erreichen, und da in der Halbleiter-Herstellung Fläche gleich Kosten ist, also die billigste. Der Nachteil ist sollte man den Speicherinhalt ändern müssen, so kann man seinen gesamten Bestand verschrotten. Trotzdem hat man z.B. in der Automobil-Zulieferindustrie sehr lange auf diesen Speicher gesetzt, obwohl man damit unflexibel war, da es sich über die riesigen Stückzahlen rechnete. Brauchte ein solches Programm einen Speicher für einstellbare Parameter, so hat man dafür EEPROM verwendet. Brauchte vielmehr Fläche, erlaubte aber eine hinreichende Anzahl von Schreib- Löschzyklen, da man da in der Regel mit sehr wenig Speicher auskommt war die große Fläche verschmerzbar.
Das Gegenstück zum PROM oder ROM, ist der EPROM, sozusagen der ROM für die kleinen und mittleren Stückzahlen. Hat man ein teuereres Gehäuse mit Fenster genommen, so konnte man diesen Speicher durch das Aussetzen einer UV-Strahlung löschen, ansonsten ohne Fenster in der Serie konnte man das Bauteil einmalig programmieren und lag von den Kosten zwischen einem ROM oder PROM und dem EPROM mit Fenster. EPROM steht für erasable programmable read only memory.
Beim Flash Memory brauchte man lange Zeit eine zusätzliche Spannugsversorgung um das Flash löschen, bzw. Schreiben zu können. Auch war/ist der Fertigungsprozess schlecht kompatibel mit dem für die kombinatorische Logik, also dem uC. Es dauerte sehr lange bis die großen Halbleiter-Hersteller uC mit Flash-Memory zu einem Preis herstellen konnte der sie für z.B. die Automobilbranche akzeptabel machen konnte. Außerdem war auch das Thema Zuverlässigkeit ein kritisches Thema. Über Jahre war es klar, das wer zuerst zu einer Massenfertigung von uC mit Flash mit der erforderlichen Zuverlässigkeit und zu den passenden Kosten herstellen konnte seine Stellung als Lieferant sicherte.
Heute ist der Prozess ausgereift und wird immer weiter forciert. Die Spannung für die Programmierung, bzw. Löschung wird z.B. bei den mega AVR auf dem IC erzeugt und heisst daher "self-programming", also selbst programmierend".
Hallo Hellmut,
vielen dank fuer Deine ausführliche Beschreibung.
Die Frage nach dem Unterschied bleibt aber weiterhin offen.
Mal als Beispiel:
Der ATmega128 hat 128KBytes flashspeicher UND 4 KBytes eeprom.
Die 128KBytes Flashspeicher sind in-system programmierbar.
Ich gehe mal davon aus das der Flashspeicher genauso wie beim P89C51RD controler (mcs51 mit 64Kbytes flash) vom Microcontrolerprogramm selbst beschrieben kann.
Warum dann auch noch die 4Kbytes eeprom wenn ich schon 128 KBytes flash zu verfügung habe?
Sind sie schneller oder öfters zu beschreiben?
Bitte noch mal um Rat
Stephan
Hallo slm
Bei einem eeprom kann jede Speicherzelle einzeln gelöscht und mit einem
neuen Wert beschrieben werden.
Das ist bei flashspeicher nicht möglich. Hier muß immer ein ganzer
Bereich gelöscht werden.
Viele Controller können auch ihren eigenen Speicher nicht selbst beschreiben.
MfG
Sandro
Hallo Stephan
Aus historischen Gründen erhalten sich immer wieder Techniken, die gäbe es sie nicht, man auch ohne sie auskäme. Im Detail trifft das was Sandro sagt zu, aber sicher könnte man in den meisten Fällen damit leben. Langsam sind beide Techniken, deshalb haben die Controller ja auch RAM, der aber eben flüchtig ist, sprich fällt der Strom aus ist der Inhalt flöten. Aber erlaube mir doch eine Rückfrage, warum ist es dir wichtig den Unterschied zu wissen?
Wie hier schon gesagt, Flash und EEROM sind beide nicht flüchtig, beide lösch und wiederbeschreibbar, und beide nicht beliebig häufig zu beschreiben. Das EEROM sogar noch weniger wieder beschreibbar.
Zum Ablegen gelegentlich zu pflegender Daten eignen sich beide, ich käme ohne EEROm aus, nich jedoch ohne RAM.
Hi Hellmut
In meiner Applikation muss ich benutzterspezifische Daten speichern.
Zur Zeit benutzte ich dafür eine Batterie gepufferte sram.
Ob ich jetzt nonvolatile sram, flash oder eeprom dafür Anwende ist eigentlich schnuppe.
Wenn auch der Kostenfaktor wie auch das Leiterplattenlayout eine Rolle spiel.
Mir geht es um grundlegende Klarheit, weil in den Datasheets hin und her zwischen eeprom, flash und sogar flash eeprom geredet wird.
Um Entscheidungen zu treffen muss ich die Vorzuege wie auch die Nachteile der jeweilige Technologie wissen. Fehlentscheidungen kosten vor allem ein viel Zeit für eine Neuentwicklung.
Um vorweg zu nehmen benutzte ich eine "teure" Batterie gepufferte sram und kein eeprom weil diese auch eine Echtzeituhr beinhaltet die ich brauche.
Stephan
Hallo Stephan
Also, lass uns das konkret hin bekommen:
1. Wieviele Daten, Bytes, möchtest du ablegen?
2. Wie häufig musst du diese verändern?
Also während eines Programmlaufes mehrmals, einmal, gelegentlich?
Trifft deine Aussage hier unter 2. für alle Daten zu?
3. Müssen die Daten dauerhaft gespeichert werden, sprich auch nach dem Ausschalten?
Da du zur Zeit ein Batterie gepufertersw SRAM verwendest soll es also nicht flüchtig sein!
Um dir auch ein wenig Refrenzmaterial zu geben, schaue dir bei Atmel die Tabelle an mit allen Controllern und der Auflistung z.B. wieviel Flash, wieviel SRAM, wieviel EEROM, Timer usw. jeder Controller hat.
In den Flash Speicher würde ich Programm Kode ablegen,
in das SRAM die Laufzeit-Variablen,
in das EEROM einige nur gelegentlich zu verändernden Benutzerspezifische Daten.
In den Flash Speicher würde ich Tabellen und andere größere Datenbestände ablegen die doch regelmäßig verändert werden.
Hierzu ein Beispiel aus meiner Praxis:
Ich verwende einen mega8 um die Impulslängen der Signale des Empfängers und des Multiprop-Dekoders meiner f14 von robbe zu dekodieren.
Im Flash lege ich eine Kopie der Impulslängen-Tabelle und anderer Steuergrößen ab, die ich als "default" bezeichne. Nach einem Neustart erlauben diese Werte einen default betrieb.
In das SRAM tuhe ich eine Kopie dieser Tabelle, die im Betrieb gepflegt wird. Dort stehen immer die letzten Impulslängen für jeden Kanal, der mega8 vergleicht eine neu gemessene Impulslänge mit dem Wert dort. Sollte der Benutzer über die Funkfernsteuerung einen geänderten Wert übertragen, so erkennt das Programm dieses durch Vergleich, pflegt die Daten in der Tabelle im SRAM und sendet per I2C die veränderten daten z.B. an eine Motorsteuerung.
Für das EEROM habe ich bisher keinen Bedarf und habe es auch nicht genutzt. Du siehst also, das SRAM enthält jene Daten die sehr variabel sind, das Flash jene die ich nur seltener ändere.
Ach, ein grund fällt mir gerade für das EEROMein. Man kann bei den Controllern über sogenannte Fusebits den Inhalt des Flash vor Auslesen und verändern schützen. In diesem fall könnte das Flash also nicht zur Speicherung der "default Information dienen und das EEROM wäre die Alternative.
Ich hoffe diese Information hilft dir jetzt besser.
Wie hier schon gesagt, Flash und EEROM sind beide nicht flüchtig, beide lösch und wiederbeschreibbar, und beide nicht beliebig häufig zu beschreiben. Das EEROM sogar noch weniger wieder beschreibbar.
Es ist genau umgekehrt. Das EEprom lässt sich wesentlich häufiger beschreiben ( 100 000 mal im Gegensatz zum 1 000 bis 10 000 mal beim Flash Speicher ).
Viele der "alten" AVRs konnten außerdem ihren Flashspeicher nicht selbst beschreiben, daher war das Eeprom die einzige Möglichkeit Daten dauerhaft zu speichern.
Für die Anwendung die du beschrieben hast nimmt man deswegen auch normalerweise das EEprom ;-) Im Flash legt man eigentlich keine Variablen ab. Wenn es mal zu einem Fehler im Programm kommt hat man so eine wunderbare Möglichkeit das das gespeicherte Programm mal eben überschrieben wird...
MfG Kjion
Hallo Kjion
Danke für die Korrektur. Aber das Ablegen eines "default" Werte-Satzes ist doch im Flash sinnvoller als im EEROM, da dort viel mehr Speicher verfügbar ist, und 1000 bis 10000 Zyklen geht sicher weit über die Anzahl der male wo man seine "defaults ändert! Ansonsten für Laufzeitvariable ist aber das das SRAM sicher geeigneter als das EEROM?
Ja klar, für Variablen ist das SRAM da. Das beschreiben des EEproms würde zum einen viel zu lange dauern und man würde schnell an die Grenzen der Beschreibbarkeit kommen, also völlig ungeeignet dafür ...
Große Datentabellen kann man natürlich im Flash Speicher ablegen, nur normalerweise ändert man nicht mehr so viel daran.
MfG Kjion
Hallo Stephan
Ich hoffe auch gerade der Beitrag von Kjion hat dir geholfen
Hallo Helmut
Die Sache ist natürlich etwas komplizierter als ich es oben geschildert habe.
Ich benutze zurzeit den P89C51RD von Phillips mit 512 KB interne extra Ram und 64KB flash code speicher (kein eeprom).
Meine Applikation hat auch etwas verzwicktes.
Abgesehen den benutzterspezifische Daten und den Programmvariablen sind im nicht flüchtige Speicher etwa 1KB.
Das Programm selbst hat eine Codegröße von knapp 60KB.
Den Stack habe ich freigehalten, da zwei Tasks geschedult wird.
Der scheduler läuft nach round robin prinzip.
Beim Taskswitchen werden die Stacks jeweils in interne extra ram hin und her kopiert.
Dabei muss noch hin und her geschaltet werden zwischen interne extra ram und externe extra ram (batterie gepufferte Ram). Beide Tasks muessen auf die gleichen Daten zugreifen (Semaphore) und der Watchdog muss auch noch bedient werden. Was bei der Laufzeit nicht so einfach ist da ein haufen Gleitkommenzahlen sowie unsigned long Zahlen berechnet werden muessen. Und und und...
Um auf den Punkt zu komme, pfeifft mein controller aus dem letzten Loch.
Alles klappt auch ganz gut und ich glaube nicht das man da noch vielmehr rauszuholen ist.
Leider hat Phillips die Produktion diesen Controler eingestellt.
Er ist zwar noch erhältlich und mein Lager ist noch voll, aber ich bin vorrausschauend für einen Ersatz der natürlich noch mehr auf den Kasten haben soll damit ich ihn noch mehr zupacken kann.
Mfg Stephan
PS:
Eure Infos haben mir eine ziemliche Klarheit verschafft.
Danke
Stephan
... da ein haufen Gleitkommenzahlen sowie unsigned long Zahlen berechnet werden muessen. Und und und...Ich weiss natürlich nicht was genau das Ding machen soll, aber bist du dir sicher daß du nicht auf Gleitkommazahlen verzichten kannst?
Man kann doch eigentlich immer mit Festkommazahlen arbeiten, und die kann der µC sehr viel schneller verarbeiten.
Was meinst Du mit Festkommazahlen???
Zahlen mit einer festen Anzahl an Nachkommastellen.
Natürlich gibt es dafür keine eigenen Variablentypen, das ist aber auch nicht nötig.
Nehmen wir mal an du willst eine vom AD-Wandler gemessene Spannung auf 3 Nachkommastellen genau speichern / verarbeiten,
dann kannst du diesen Wert doch einfach mit 1000 multiplizieren und in einer Int-Variable speichern. (Du rechnest also nicht mit V sondern mit mV)
So braucht der Controller nurnoch ganz normale Integer-Arithmetik,
was bei Controllern ohne FPU (Floating Point Unit) natürlich einen ordentlichen Geschwindigkeitsvorteil bringt.
Man muss natürlich aufpassen, daß man nicht zwei Variablen miteinander verrechnet, die nicht zusammen passen...
Also z.B. wenn in der einen Variable eine Spannung in V abgelegt ist und in der anderen in mV,
muss man zuerst eine von beiden entsprechend anpassen. (z.B. den Wert aus der "V" Variable in mV umrechnen)
kurz gesagt: du musst aufpassen, daß die Anzahl der Nachkommastellen passt.
Ich gebe dir vollkommen recht. Meine Überlegungen gingen damals auch in diese Richtung.
Aber dann hätte ich das ganze Programm nochmal umschreiben muessen was ursprunglich von einem PC104 kann. Das war mir dann doch zuviel arbeit, schließlich ging es auch sehr gut ohne.
michi8725
24.03.2005, 10:01
Hallo zusammen also ich stehe genau vor dem selben Problem. Was empfiehlt ihr mir für einen Speicher zu verwenden?
Ich benutze einen PIC 18F452 mit folgenden Speichern:
Flash: 32 Kbytes
RAM: 1536 bytes
Data EEPROM: 256 Bytes
Bei meinem Projekt geht es um eine Türsteuerung mit Zugangscodes
Ich hab folgende 2 Teile die ich in einen Speicher unterbringen muss:
1) Über einen Mastercode(der fest programmiert ist) können neue Codes hinzugefügt und gelöscht werden. Es wird eine Liste z.B. mit 10 Zugangscodes geben die bei jeder eingabe eines codes überprüft werden müssen. Die Codes dürfen natürlich nicht flüchtig sein. Welchen Speicher soll ich da verwenden?
2) Die Türsteuerung beinhaltet einen Real Clock Timer wenn man sich mit einem Code anmeldet liest der PIC das Datum aus dem RCT verknüpft dies mit dem Benutzername(Zugangscode) und legt diesen String, oder was auch immer es dann sein wird in eine Liste ab. Diese Liste beinhaltet immer die letzten 50 Türöffnungen. Wo soll ich diese Liste anlegen? Flüchtig/nicht Flüchtig? wie soll ich das mit der Liste lösen? den speicher immer eins nachschieben und die bei 50 Fallen raus?
Gruss Michael
1) die Codes kommen ins EEPROM (da sie sich zwar ändern können, aber nur relativ selten)
2) ob flüchtig oder nicht musst du wissen...
im Normalbetrieb würde ich hier auf keinen Fall ins EEPROM schreiben,
da sich die Liste ja immer ändert wenn Jemand seinen Code eingegeben hat.
(das muss also auf jeden Fall im RAM gespeichert werden)
Falls die Daten wirklich nicht verloren gehen dürfen,
musst du bei einem Stromausfall die ganze Liste in irgendeinen nichtflüchtigen Speicher kopieren.
Bei einer so langen Liste könnte es im EEPROM allerdings etwas eng werden.
Wenn der Platz nicht reicht kannst du dem Gerät ja einen eigenen Akku spendieren und die Daten im RAM lassen
(oder du hängst noch ein externes EEPROM dran)
michi8725
24.03.2005, 11:19
ja ok stimmt ist eigentlich das einfachste.
Weisst du wie ich das Problem mit der Liste lösen kann? Das die Strings immer wieder eins nach "rutschen" wenn ein neuer kommT?
Übrigens gib es von Reichelt den M48T02, mit 2KB nichtflüchtiger sram und eine RTC.
Weisst du wie ich das Problem mit der Liste lösen kann? Das die Strings immer wieder eins nach "rutschen" wenn ein neuer kommT?Dazu musst du nur einen sog. Ringspeicher realisieren.
Das ist ein fester Speicherbereich (Array) auf den du mit Hilfe von zwei Zeigern zugreifst, wobei ein Zeiger auf das erste und einer auf das letzte Element zeigt.
Wenn du also einen neuen Wert erhälst, schreibst du ihn an die Speicherstelle auf die der Zeiger verweist, und inkrementierst ihn dann.
In welcher Sprache programmierst du den µC?
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.