www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik M24C64 Eeprom schnell auslesen und beschreiben


Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

es geht wieder um das leidige Thema Eeprom ;-)

Beim EEPROM handelt es sich um das M24C64 von Mikrochip
Datenblatt -> 
http://www.datasheetcatalog.org/datasheet/stmicroe...

Das EEPROM kann mit einer maximalen Busclock von 400 kHz arbeiten. Die 
Schreibgeschwindigkeit für eine Page (32 Byte) ist mit 10 ms angegeben.

MEIN PROBLEM :
In diesem EEPROM liegt nun eine 7620 Byte lange Befehlssequenz. Ein 
Sequenzschritt besteht aus 3 Byte, also 7620 / 3 = 2540 
Sequenzschritten.

Ich will nun eine Routine schreiben, die EINEN Sequenzschritt in 0.5 ms 
abarbeitet. Wenn ich in eine Page nun 10 Sequenzschritte lege, belegt 
dies 30 Byte ...

LESEND wäre das sicherlich irgendwie machbar, aber diese 
Abarbeitungssgeschwindigkeit muss SYNCHRON mit der SCHREIB 
Geschwindigkeit laufen. Das hat den Hintergrund, dass diese Sequenz zur 
AUSGABE und zur AUFNAHME von Werten dient.

Und da liegt der Hase im Pfeffer vergraben...

30 Byte / 10 ms -> 3 Byte / 1 ms !
Das wäre also durchaus drin, wenn auch SEHR knapp ohne Spielraum.

Hat jemand eine Idee, wie man das Problem umgehen kann??

Ich dachte evtl. an einen "RAM-Puffer". Sprich, in einem 
Vor-Abarbeitungsschritt wird der KOMPLETTE Eeprom Inhalt ins RAM 
geladen. Und dann aus dem RAM heraus abgearbeiter.
Wäre natürlich ideal, geht aber leider nicht, da der zur Verfügung 
stehende RAM nicht groß genug ist.. im Moment würde ich die Hälfte etwa 
ins RAM bekommen.

Nur bringt dies leider nichts, da ich ja immer noch zu schnell 
"abarbeite" wie ich ins EEPROM schreiben kann.


Wäre wirklich toll, wenn jemand da eine Idee hätte!

Viele Grüße && Danke

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm ein Ferroram von Ramtron. Arbeitet wie ein EEPROM
hat aber quasi Null Schreibzeit.

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger wrote:
> Nimm ein Ferroram von Ramtron. Arbeitet wie ein EEPROM
> hat aber quasi Null Schreibzeit.

Danke für den Hinweis, werde mir den Baustein mal genauer ansehen.

Aber das EEPROM muss leider bleiben. Es handelt sich bei meinem Aufbau 
um ein FLEXIS Board von Freescale.

Das System so wie oben beschrieben läuft mit 10 ms 
Abarbeitungsgeschwindigkeit auf einem 8 Bit Controller. Nun habe ich den 
8 Bit Controller durch einen Pin-kompatiblen 32 Bit Controller ersetzt. 
Nun wollte ich eben auch mit der Abarbeitungsgeschwindigkeit hoch gehen.

Von der Rechenleistung des Controllers würde es "ohne größere Probleme" 
gehen." Z.b. die Umskalierung von Werten für den DAC dauert vorher 2 ms 
nun "nur" noch 58 Mikrosekunden.

der Flaschenhals ist und bleibt das EEPROM. Im Moment fällt mir keine 
Möglichkeit ein, wie ich es irgendwie elegant umschippern könnte ohne 
gegen die Wand zu fahren.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du solltest dir das Banking im EEPROM mal anschauen. Notfalls also 2 
Bytes Verlust pro Sequenz einkalkulieren, nur um die Page boudaries zu 
erreichen. Du kannst ein EEPROM nämlich mit bis zu 32 Bytes auf einmal 
beschreiben, wenn du vielfache von 32 einhälst. Da das EEPROM mit dem 
Schreiben erst bei Stop beginnt, kannst Du da also 30 Bytes schreiben 
und dann erst 10ms warten. Wärend nach dem Schreiben die Wartezeit nötig 
ist, ist dies nach dem Lesen selbstverständlich nicht erforderlich, auch 
gibt es beim Lesen keine Pages.

Wenn Du diese Zeit halbieren möchtest, dann solltest Du bei den 
Automotive EEPROMs nachsehen, die gibt es nämlich auch in 5ms.

Eine weitere Beschläunigung wäre erreichbar, wenn Du zwei EEPROMs nimmst 
und die Sequenzen abwechselnd lädst / schreibst.

Dazu kommt, dass die 5/10ms Maximalangaben sind. Du kannst also weitere 
Zeit schinden, wenn Du nicht eine feste Zeit wartest, sondern so früh 
wie möglich mit einem ACK-Polling herausfindest, wann das EEPROM wieder 
bereit ist. Diese Zeit ist aber leider von der Betriebstemperatur, der 
Spannungsstabilität und dem Alter des Chips abhängig. Kannst Du diese 
Parameter eingrenzen, dann lässt sich trotzdem noch etwas Reserve 
entlocken.

An sonsten geht wirklich nur der Austausch gegen ein FERAM. Als Zusatz 
sie hier angemerkt, dass diese Bausteine nicht nur das gleiche Protokoll 
wie ein EEPROM sprechen, sondern auch in identischen Gehäusen und 
Pinouts lieferbar sind. Es wäre also ein 1:1 Ersatz.

Gruß, Ulrich

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wärend nach dem Schreiben die Wartezeit nötig ist,

Während dieser Zeit kann man auch nichts lesen.
Der gibt kein ACK mehr raus solange die Page
geschrieben wird. Nur mal am Rande bemerkt.

Man kann auch nicht einfach die Pagezeit auf
eine kleinere Anzahl Bytes runterrechnen. Es dauert
immer eine Pagezeit. Egal ob 1 Byte oder 32.
Intern wird immer eine ganze Page geschrieben.

Das ganze Problem lässt sich nur mit viel RAM lösen.
Oder Ferroram.

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Beitrag Ulrich!!

Ulrich P. wrote:
> Du solltest dir das Banking im EEPROM mal anschauen. Notfalls also 2
> Bytes Verlust pro Sequenz einkalkulieren, nur um die Page boudaries zu
> erreichen. Du kannst ein EEPROM nämlich mit bis zu 32 Bytes auf einmal
> beschreiben, wenn du vielfache von 32 einhälst.
Das war auch mein Plan. Aber 30 Byte / 10 ms. Da komme ich auf 3 Byte 
pro ms. Dies würde genau einem Sequenzschritt (= 3 Byte) entsprechen.


> Dazu kommt, dass die 5/10ms Maximalangaben sind. Du kannst also weitere
> Zeit schinden, wenn Du nicht eine feste Zeit wartest, sondern so früh
> wie möglich mit einem ACK-Polling herausfindest, wann das EEPROM wieder
> bereit ist. Diese Zeit ist aber leider von der Betriebstemperatur, der
> Spannungsstabilität und dem Alter des Chips abhängig. Kannst Du diese
> Parameter eingrenzen, dann lässt sich trotzdem noch etwas Reserve
> entlocken.
Das ist ein interessanter Punkt. Sind diese 10 ms der theoretische 
"maximal" Wert, oder kann man durch Polling da ein paar ms rausholen?
Wenn ich immer "etwas" unter den 10 ms bleiben könnte, würde mir das 
durchaus genügen.

Mit einem "kleinen" Ram-Puffer könnte ich evtl. einen "jittern" des 10 
ms Zeitwertes ausgleichen?! War nur eine Idee, aber evtl. sollte ich 
sowas einbauen.

> An sonsten geht wirklich nur der Austausch gegen ein FERAM. Als Zusatz
> sie hier angemerkt, dass diese Bausteine nicht nur das gleiche Protokoll
> wie ein EEPROM sprechen, sondern auch in identischen Gehäusen und
> Pinouts lieferbar sind. Es wäre also ein 1:1 Ersatz.
Wie gesagt Austausch ist im Moment leider nicht mögich, aber für 
zukünftige Projekt werde ich das auf jeden Fall im Hinterkopf behalten.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger wrote:
>>Wärend nach dem Schreiben die Wartezeit nötig ist,
>
> Während dieser Zeit kann man auch nichts lesen.
> Der gibt kein ACK mehr raus solange die Page
> geschrieben wird. Nur mal am Rande bemerkt.

Das genau meinte ich damit.

> Man kann auch nicht einfach die Pagezeit auf
> eine kleinere Anzahl Bytes runterrechnen. Es dauert
> immer eine Pagezeit. Egal ob 1 Byte oder 32.
> Intern wird immer eine ganze Page geschrieben.
>
Auch das schien klar.

> Das ganze Problem lässt sich nur mit viel RAM lösen.
> Oder Ferroram.

Richtig.
Im Übrigen sind SPI-EEPROMs auch nicht schneller beim Schreiben, auch 
wenn die Datenübertragung selbst schneller sein kann. Habe die 
Datenblätter nicht geprüft. Diese Variante schien aber auszuscheiden, da 
die Hardware wohl schon feststeht.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Mit einem "kleinen" Ram-Puffer könnte ich evtl. einen "jittern" des 10
>ms Zeitwertes ausgleichen?! War nur eine Idee, aber evtl. sollte ich
>sowas einbauen.

Eigentlich ein klassischer Fall für RAM Double Buffering.
Zwei Lesepuffer und zwei Schreibpuffer mit jeweils Pagegröße.
Das muss man dann geschickt verschachteln um irgendwie
immer einen gewissen Vorsprung zu haben.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich P. wrote:
> holger wrote:

>> Oder Ferroram.
> Richtig.

Was haelt dich davon ab? Ich habe neulich ein 24C512 durch ein FRAM 
ersetzt, der Unterschied ist wie Tag und Nacht - und nur die 
Adressberechnung muss ein wenig angepasst werden.

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich verstehen immer noch nicht, warum der Austausch des EEPROMs gegen 
ein FERAM nicht möglich ist, es sei denn, das EEPROM ist BGA. SO8 ist 
mit einem Messer und einem normalen Lötkolben schnell getauscht.

Trotzdem:
Die 10ms sind die Zeit, die der Hersteller garantiert, wenn die 
Spezifikationen für Temperatur und Spannungen bis zu ihrer Grenze 
ausgereizt sind. D.h. wenn Du den Chip bei -Tmin oder +Tmax mit VCC=min 
oder Vcc=max der Normal Operating Conditions betriebst, werden die 10ms 
nicht überschritten.

Ich hatte schon EEPROMs im Automotive Bereich, die unter 1ms geschrieben 
haben, obwohl mit 5ms spezifiziert. Ich werde mihc natürlich nicht 
darauf festlegen lassen, welches Tempo nun ausgerechnet bei Deinem Chip 
zu erwarten ist. Meine Chips waren auch nicht von Microchip, sondern von 
ATMEL, was aber jetzt keine Wertung sein soll.

Das Einzige, was Dir helfen wird ist ein kleines Testprogramm, dass so 
einen Chip mal mit Nonsense beschreibt und dabei einen Pin toggelt, den 
Du per Scope dann darstellst. Damit hast Du eine sichere Aussage für 
Deine Spannung und bei Deiner Raumtemperatur. Also den Test auf jeden 
Fall mal bei +30°C oder +50°C wiederholen, weil die Platine vermutlich 
irgendwann in einer kleinen Box sitzt und von einem DC/DC und einer CPU 
beheizt wird.
Damit hast Du aber dann eine ordentliche Übersicht, welche Zeiten Dich 
real erwarten.

Gruß, Ulrich

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Sebastian B. (mircobolle)

>30 Byte / 10 ms -> 3 Byte / 1 ms !
>Das wäre also durchaus drin, wenn auch SEHR knapp ohne Spielraum.

Na dann nimm einfach einen grossen EEPROM, z.B. 24C512 von Atmel, der 
hat 128 Byte Pages mit der halben! Brennzeit -> achtfache 
Geschwindigkeit.

Oder nimm gleich SPI Dataflash, AT45DB011B, der hat auch 256 Byte Pages 
bei  max. 20ms Brennzeit. Vorteil ist das wesentliche schnellere SPI.

Dir ist aber hoffentlich klar, dass die Schreibzugriffe dein EEPROM 
ziemlich stressen?

MFG
Falk

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
holger wrote:

> Eigentlich ein klassischer Fall für RAM Double Buffering.
> Zwei Lesepuffer und zwei Schreibpuffer mit jeweils Pagegröße.
> Das muss man dann geschickt verschachteln um irgendwie
> immer einen gewissen Vorsprung zu haben.

Ja, auf der Heimfahrt hatte ich eine ähnliche Idee. Also mehrere Puffer 
in Page-Größe.

@Peter
>Was haelt dich davon ab? Ich habe neulich ein 24C512 durch ein FRAM
>ersetzt, der Unterschied ist wie Tag und Nacht - und nur die
>Adressberechnung muss ein wenig angepasst werden.
Mhm, noch gibt es das System nur als "Prototyp" auf meinem Schreibtisch. 
Das EEPROM habe ich auf einer kleinen Lochrasterplatine im DIP-8 Gehäuse 
sitzen. Das EEPROM ist über I²C mit dem Controller verbunden.

Kannst du mir einen FRAM Baustein empfehlen? Wie sieht es da preislich 
im Vergleich zu einem 0815 Eeprom aus? Wenn ich etwas Zeit habe, 
probiere ich mal diesen Speichertyp aus!

@Ulrich
>Die 10ms sind die Zeit, die der Hersteller garantiert, wenn die
>Spezifikationen für Temperatur und Spannungen bis zu ihrer Grenze
>ausgereizt sind. D.h. wenn Du den Chip bei -Tmin oder +Tmax mit VCC=min
>oder Vcc=max der Normal Operating Conditions betriebst, werden die 10ms
>nicht überschritten.
Da meine Sequenz-Routine alle 1 ms aufgerufen wird, wird auch die Eeprom 
Ack-Polling Funktion in diesem Intervall das Eeprom pollen. Wie gesagt, 
wenn ich durch die Lösung auf eine mehr oder weniger stabile Zeit von 1 
ms pro 3 Byte, also pro Sequenzschritt kommen würde, wäre ich sehr 
zufrieden.

Vielen Dank für eure vielen Beiträge!!

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner wrote:
> @ Sebastian B. (mircobolle)
>
>>30 Byte / 10 ms -> 3 Byte / 1 ms !
>>Das wäre also durchaus drin, wenn auch SEHR knapp ohne Spielraum.
>
> Na dann nimm einfach einen grossen EEPROM, z.B. 24C512 von Atmel, der
> hat 128 Byte Pages mit der halben! Brennzeit -> achtfache
> Geschwindigkeit.
Stimmt, das wäre eine Alternative zum FRAM, ohne vom EEPROM abkommen zu 
müssen. Wobei, wenn ich ohnehin einen neuen Treiber samt Adressierung zu 
schreiben hätte, könnte ich auch komplett auf eine andere 
Speichertechnologie umsteigen.

> Dir ist aber hoffentlich klar, dass die Schreibzugriffe dein EEPROM
> ziemlich stressen?
Ja, zu Beginn war der EEPROM Speicher nur zur Speicherung von 
Konfigurationsdaten und zur Speicherung einer abspielbaren Sequenz 
vorgesehen. Erst später kam die nützliche Funktion der Aufzeichnung 
hinzu. Wenn sich diese Funktion im Betrieb wirklich durchsetzen sollte, 
dann hat das EEPROM, und damit ich ;), allerdings wirklich ein Problem.

Danke für den Beitrag.

Gruss

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
habe gerade mal bei rsonline.de nach FRAM gesucht.
Gibt es auch FRAM Bausteine mit I²C Anbindung? Optimal wäre es 
natürlich, wenn die Schnittstelle identisch zu einem M24Cxx wäre. Das 
die Adressierung unterschiedlich sein wird ist mir bewusst.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und nun eier nicht rum und nimm das Ding. Kannst deine Software komplett 
unverändert lassen - bis auf irgendwelche Warte/Ack-Spielchen, die 
schmeisst du raus.
Kannst eine Page von 32Byte schreiben, einzelne Bytes oder auch den 
gesamten Speicher in einem Rutsch.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian B. wrote:
> habe gerade mal bei rsonline.de nach FRAM gesucht.
> Gibt es auch FRAM Bausteine mit I²C Anbindung? Optimal wäre es
> natürlich, wenn die Schnittstelle identisch zu einem M24Cxx wäre. Das
> die Adressierung unterschiedlich sein wird ist mir bewusst.

Die Schnittstelle ist identisch. Das ist auch nur TWI, nur welches 
Addressbit wohin kommt, musst du nochmal nachschlagen.

Beispiel:

AT24C512 hat word address A0-A15 und device address A0-A2
FM24C512 hat word address A0-A14 und device address A1-A2 + A15 von der 
word address.

Also einfach die Adresse ein wenig anders zusammenschieben und schon 
laeuft der "normale" TWI-EEPROM-code. Ergo gehen bei den FRAMs 
allerdings nur 4 an einem Bus und beim EEPROM 8. Wie's bei den kleineren 
Typen aussieht, weiss ich nicht, vieleicht ist die Adressierung dort 
sogar teilweise gleich.

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
crazy horse wrote:
> und nun eier nicht rum und nimm das Ding. Kannst deine Software komplett
> unverändert lassen - bis auf irgendwelche Warte/Ack-Spielchen, die
> schmeisst du raus.
> Kannst eine Page von 32Byte schreiben, einzelne Bytes oder auch den
> gesamten Speicher in einem Rutsch.

Ok, nun habt ihr es geschafft ;-) Ich werde mir so ein FRam von Ramtron 
bestellen und dann mal eine kleine Testplatine aufbauen. Die Ergebnisse 
werde ich dann hier posten.

Alternativ werde ich auch in der Zwischenzeit das Double-Ram-Buffering 
ausprobieren und damit testen wie nah ich an die "1 ms" 
Abarbeitungsgeschwindigkeit rankomme. Alles was darunter liegt ist 
natürlich umso besser.

Danke an alle die sich hier beteiligt haben!!

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schaut euch noch mal meine verlinkte Farnell-Seite an:
24C256: Einzelstück 8,50, 10er Preis 7,60 usw.
Stange mit 94 Stk 901,88€, ich hau mich weg. Das ist interessante 
Preispolitik :-)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Angebot und Nachfrage regeln den Preis. Aber wer fragt sowas nach?

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
crazy horse wrote:
> Schaut euch noch mal meine verlinkte Farnell-Seite an:
> 24C256: Einzelstück 8,50, 10er Preis 7,60 usw.
> Stange mit 94 Stk 901,88€, ich hau mich weg. Das ist interessante
> Preispolitik :-)

Hab das auch gerade gesehen. ;-)
Warum sind die FRAMS im Vergleich zu gewöhnlichen EEPROM so "teuer" ?
32 kB für 8,50 Euro ist ja nicht wirklich ein Schnäppchen. Oder habe ich 
da irgendwas nicht beachtet? Oder im Vergleich zu FLASH Speicher.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian B. wrote:

> Hab das auch gerade gesehen. ;-)
> Warum sind die FRAMS im Vergleich zu gewöhnlichen EEPROM so "teuer" ?
> 32 kB für 8,50 Euro ist ja nicht wirklich ein Schnäppchen. Oder habe ich
> da irgendwas nicht beachtet? Oder im Vergleich zu FLASH Speicher.

Warum sind Autos von Mercedes im Vergleich zu VWs denn nur so teuer?

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. wrote:
> Sebastian B. wrote:
>
>> Hab das auch gerade gesehen. ;-)
>> Warum sind die FRAMS im Vergleich zu gewöhnlichen EEPROM so "teuer" ?
>> 32 kB für 8,50 Euro ist ja nicht wirklich ein Schnäppchen. Oder habe ich
>> da irgendwas nicht beachtet? Oder im Vergleich zu FLASH Speicher.
>
> Warum sind Autos von Mercedes im Vergleich zu VWs denn nur so teuer?

Warum ist dann aber ein VW Phaeton teurer als eine A Klasse von 
Mercedes? ;-)
Klar, ich weiß schon, dass FRam eine bessere (also auch teurere) 
Speichertechnologie ist. Vermutlich ist auch der Herstellungsprozess 
aufwendiger, von dem her versteht sich das schon.
Aber FLASH ist ja vergleichbar schnell und auch ausfallsicher.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian B. wrote:

> Aber FLASH ist ja vergleichbar schnell und auch ausfallsicher.

Ausfallsicherer? Als FRAM? Wohl kaum. Und Flash ist ein Massenprodukt, 
was von vielen Herstellern hergestellt wird. FRAM ist Nische und wird ja 
auch eigentlich nur von Ramtron gebaut, oder?

Autor: Sebastian B. (mircobolle)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. wrote:
> Sebastian B. wrote:
>
>> Aber FLASH ist ja vergleichbar schnell und auch ausfallsicher.
>
> Ausfallsicherer? Als FRAM? Wohl kaum. Und Flash ist ein Massenprodukt,
> was von vielen Herstellern hergestellt wird.
Ok. Das stimmt natürlich. Flash = Massenprodukt, deshalb auch günstiger.
Mit "ausfallsicher" meinte ich eigentlich "nicht-flüchtig". Aber was 
mögliche Schreibzyklen und Datenhaltungszeit angeht, übertrifft FRam 
wohl auch Flash.

>FRAM ist Nische und wird ja
> auch eigentlich nur von Ramtron gebaut, oder?
Bis vor ein paar Tagen wusste ich noch gar nichts von FRAM. Ich bin über 
diesen Thread darauf aufmerksam gemacht worden, weil ich durch mein 
aktuell eingesetzt M24C64 EEPROM an Zeitgrenzen gestoßen bin, die ich 
durch Maßnahmen , wie "Double-RAM Buffering" usw. nicht in den Griff 
bekommen kann.

Ich werde auf jeden Fall mal eine Testplatine mit Fram aufbauen und dann 
gegen mein aktuell eingesetzt Eeprom austauschen und dann mal testen.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke mal, FRAM ist wesentlich ausfallsicherer, denn soweit ich 
weiß, wurde das Grundprizip schon in den Space-Shuttles angewendet 
(ferromagnetische Ringspeicher...)

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian R. (supachris)

>Ich denke mal, FRAM ist wesentlich ausfallsicherer, denn soweit ich
>weiß, wurde das Grundprizip schon in den Space-Shuttles angewendet

Naja, von den Dingern sind ja aber auch zwei nicht ganz in einem Stück 
runtergekommen in den letzten 25 Jahren. Ausfallquote von x:1?

SCNR
Falk

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.