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/stmicroelectronics/4578.pdf 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
Nimm ein Ferroram von Ramtron. Arbeitet wie ein EEPROM hat aber quasi Null Schreibzeit.
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.
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
>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.
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.
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.
>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.
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.
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
@ 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
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!!
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
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.
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.
und da kaufen: http://de.farnell.com/jsp/search/browse.jsp?N=500003+1000017&Ntk=gensearch_002&Ntt=fm24&Ntx=
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.
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!!
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 :-)
Angebot und Nachfrage regeln den Preis. Aber wer fragt sowas nach?
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.
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?
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.
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?
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.
Ich denke mal, FRAM ist wesentlich ausfallsicherer, denn soweit ich weiß, wurde das Grundprizip schon in den Space-Shuttles angewendet (ferromagnetische Ringspeicher...)
@ 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
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.