hi, ich frage mich ob es im jahr 2017 nicht eine möglichkeit gibt speicher im mb-bereich zur ablage von messdaten an einen µc zu hängen eeprom fällt aus wegen dem ganzen gehacke mit "wear leveling", fram kommt meiner vorstellung schon nahe, nur kann ich da nix mit mehreren mb finden sd-card scheint mir aktuell die einzige option zu sein, nur die gibt es auch nur noch ab 4gb und das ist doch schon ein wenig overkill und relativ langsam wie löst ihr aktuell solche probleme ?
Ray M. schrieb: > sd-card scheint mir aktuell die einzige option zu sein, nur > die gibt es auch nur noch ab 4gb und das ist doch schon ein wenig > overkill man muss nicht alles davon nutzen > und relativ langsam dann machst du etwas falsch, SD Karten können ja nach Schnittstelle mehr als 100Mbyte/s.
EEPROM und Wear-Leveling muss man ja nicht machen. Die können so auch schon relativ viele Schreibzyklen. Aufnahme von Messwerten hört sich jetzt nicht so an als ob das gleiche Byte Millionen mal beschrieben werden muss. Ansonsten gibts auch noch NOR Flash. Da kommt man auch noch ohne Wear-Leveling weg, ist aber auch nicht besonders schnell.
Ray M. schrieb: > oh, AT45DB641E schaut mit 64mb genau nach dem aus was ich suche ... Achtung, das sind nur 64MBit, also 8MB.
Sebastian V. schrieb: > Ray M. schrieb: >> oh, AT45DB641E schaut mit 64mb genau nach dem aus was ich suche ... > > Achtung, das sind nur 64MBit, also 8MB. ja, auch gerade gesehen ... vor leuter freude doch glatt das rechnen vergessen also weiter suchen, 32mb oder 64mb würde ich schon gern finden
Ray M. schrieb: > oh, AT45DB641E schaut mit 64mb genau nach dem aus was ich suche ... > > danke Gut, hat 8-Megabyte - aber um wear-leveling wirst du auch da nicht rumkommen - haben ja den gleichen Zyklus wie EEPROM. Beim AT45DB641E ja auch "bloß" 100.000 W/E per Page (256 bytes).
NOR-Flash? Das gibts ab 128MBit bit 2 GBIt. Kuckst du hier: https://www.micron.com/products/nor-flash/serial-nor-flash Billig pro MBit, aber begrenzte Schreibzyklen. Für billigere Typen, kuck bei Winbond. Ist halt auch wieder "das mit dem Wear Leveling". sonst gäbe es noch FRAM von Cypress: http://www.cypress.com/products/nonvolatile-ram Hat quasi unbeschränkte Schreibzyklen, aber teurer pro MBit. Und MRAM https://www.everspin.com/serial-peripheral-interface Das hat unbeschränkte Schreibzyklen und noch teurer. EEPROM ist meiner Meinung nach der beste Kompromiss aus Schreibzyklen und Preis, das gibts bis 1MBit.
Ray M. schrieb: > eeprom fällt aus wegen dem ganzen gehacke mit "wear leveling" Meßdaten loggt man in der Regel hintereinander, da braucht man kein wear leveling. Z.B. löscht man vor dem Schreiben einer Page die nachfolgende Page. D.h. die letzte nicht leere Page enthält die neuesten Meßwerte. Es gibt Flash im SO-8 für 3,3V bis 16MB, z.B. S25FL127SABMFI101. Ray M. schrieb: > sd-card scheint mir aktuell die einzige option zu sein, nur > die gibt es auch nur noch ab 4gb Auch da passen 16MB drauf. Man darf Speicher ungenutzt lassen.
Ray M. schrieb: > 32mb oder 64mb millibit? Auch wenn du nur sehr ungern die Shifttaste verwendest: in der Technik ist sie unumgänglich. Oder du schreibst deine Worte eben gleich aus: "megabyte". Ray M. schrieb: > eeprom fällt aus wegen dem ganzen gehacke mit "wear leveling", > sd-card scheint mir aktuell die einzige option zu sein, nur > die gibt es auch nur noch ab 4gb Und gerade bei Flash brauchst du unbedingt Wearleveling. Du kaufst es dort halt mit der Karte ein und hoffst, dass der Hersteller das gut implementiert hat. Und als Tipp: das können bei Weitem nicht alle gleich gut. Manche sogar wirklich schlecht. Du solltest in diesem Fall also passende Tests machen. Und dabei sind teure Industrie-SD nicht unbedingt besser als "billige" aus der Consumer-Ecke. > fram kommt meiner vorstellung schon nahe, nur kann ich da nix > mit mehreren mb finden Die gängigen NVRAMs sind auch eher im SubMB Bereich angesiedelt. Wenn "viel Speicher" verlangt wird und der bezahlbar sein soll, bleibt eigentlich nur eine (mikro)SD Karte. Peter D. schrieb: > Ray M. schrieb: >> sd-card scheint mir aktuell die einzige option zu sein, nur >> die gibt es auch nur noch ab 4gb > Auch da passen 16MB drauf. Man darf Speicher ungenutzt lassen. Und wenn der Hersteller seinen Wearlevel Algorithmus gut implementiert hat, dann ist nach 256 Schreibzyklen jeder Block erst 1x in Aktion gewesen. Bei 10000 Löschzyklen käme man dann also auf 2,5Mio Schreibzyklen für die 16MB. Allerdings schaffen es viele Hersteller nicht, ein solches Wearleveling zu programmieren.
:
Bearbeitet durch Moderator
Bevor man rät könntest du ja auch mal die Anforderungen sagen: - Schreibzyklen? Immer an die gleiche Stelle oder fortlaufend? - Gesamtgröße - Geschwindigkeit? - Wie wichtig ist Preis, Gehäuseform, Stromaufnahme?
ok, danke für die infos ... für meine logdaten nehme also wie bisher eine micro-sd, ich schreib da aktuell 10mal/sec rein, dass funktioniert gut da ich ein fauler programierer bin, will ich mir einen struct machen, denn will ich 10mal/sec in einen kleinen nichtflüchtigen speicher schreiben und dafür suche ich eine lösung
Wie groß sind die Datenpakete. Wenn es immer nur wenige Bytes sind, dann würde ich erst eine Page (z.B. 256Bytes) in den Puffer (RAM) schreiben und dann in den Flash übernehmen. Das spart Löschzyklen, im Falle eines Stromausfalls gehen dann aber ein paar Sekunden verloren. Muss man selber entscheiden.
Matthias x. schrieb: > Wie groß sind die Datenpakete. Wenn es immer nur wenige Bytes sind, dann > würde ich erst eine Page (z.B. 256Bytes) in den Puffer (RAM) schreiben > und dann in den Flash übernehmen. Das spart Löschzyklen, im Falle eines > Stromausfalls gehen dann aber ein paar Sekunden verloren. Muss man > selber entscheiden. SD-Karten sind so groß, das man auch für 10byte einfach eine Page verwenden kann.
Peter II schrieb: > SD-Karten sind so groß, das man auch für 10byte einfach eine Page > verwenden kann. Diese Rechnung kann aber böse ins Auge gehen, wenn man mehrmals pro Sekunde schreiben will. Denn dann muss für jede 10Byte Datei jedesmal ein kompletter Block gelöscht werden. Und der macht das bei den billigen TLC Karten nur 1000mal mit...
Lothar M. schrieb: > Diese Rechnung kann aber böse ins Auge gehen, wenn man mehrmals pro > Sekunde schreiben will. Denn dann muss für jede 10Byte Datei jedesmal > ein kompletter Block gelöscht werden. Und der macht das bei den billigen > TLC Karten nur 1000mal mit... dann schreibt man ebend die 10byte in einen Block. (4k?). Dann passen auf eine 16GB karte immer noch 40Mbyte Daten.
ok, vieleicht hab ich mich komisch ausgedrückt, ich versuch es
nochmal zu verdeutlichen
ich mache eine datei auf der micro-sd auf, da schreibe ich 10mal/sec
rein,
bin ich fertig mit einem log-zyklus mache ich das file zu, fertig ...
funktioniert
jetzt sammle ich wärend des log-zyklus statistische daten, also
sowas wie min/max/avg usw... die will ich auch 10mal/sec in irgendeinen
nichtflüchtigen speicherbaustein schreiben
das ist die anwendung die ich möglichst einfach haben will und
"wear leveling" sieht im code nicht nur scheisse aus, es ist für
jemanden
der da reinschaut nicht ohne weiteres zu erschliessen was sich sein
vorgänger da denn so ausgedacht hat
weil libs für standart-probleme gibt es im µc-umfeld ja nicht ... warum
auch immer, sowas in der art wär ja auch echt zu schön für diesen
planeten
#include <eeprom_wlc.h>
// wlEEPROM datatstore(EEPROM_SIZE, USE_FROM, USE_TO);
wlEEPROM datatstore1(4096, 0, 2048);
wlEEPROM datatstore2(4096, 2049, 4096);
struct data {
...
}
datastore1.save(&data);
Lothar M. schrieb: > Denn dann muss für jede 10Byte Datei jedesmal > ein kompletter Block gelöscht werden. Ich habe die in Flash Medien integrierten wear levelling Verfahren etwas anders in Erinnerung. Denn man kann zwar nur grosse Blöcke lesen, aber darin sehr wohl inkrementell schreiben. Zentrale Verwaltungseinheiten, wie Directories, FAT, etc, liegen zwar an einer festen Position auf dem logischen Datenträger, nicht aber an einer festen Position innerhalb des Flash-Speichers. Das Ergebnis sehr kleiner Schreiboperationen ist dann lediglich eine erhebliche write amplification, d.h. es bezogen auf die Abnutzung werden pro Operation nicht 10 Bytes geschrieben, sondern etliche kB. Aber es wird nicht pro Operation gelöscht.
Ray M. schrieb: > hi, > > ich frage mich ob es im jahr 2017 nicht eine möglichkeit gibt > speicher im mb-bereich zur ablage von messdaten an einen µc zu hängen > eeprom fällt aus wegen dem ganzen gehacke mit "wear leveling", > fram kommt meiner vorstellung schon nahe, nur kann ich da nix > mit mehreren mb finden > wie löst ihr aktuell solche probleme ? Flash, vom Spansion oder SST
Frank T. schrieb: > Ray M. schrieb: >> hi, >> >> ich frage mich ob es im jahr 2017 nicht eine möglichkeit gibt >> speicher im mb-bereich zur ablage von messdaten an einen µc zu hängen >> eeprom fällt aus wegen dem ganzen gehacke mit "wear leveling", >> fram kommt meiner vorstellung schon nahe, nur kann ich da nix >> mit mehreren mb finden >> wie löst ihr aktuell solche probleme ? > > Flash, vom Spansion oder SST hast du einen link ?
Man kann auch mehrere Verfahren kombinieren. Beispielsweise ein FRAM sukzessive auffüllen, bis genug Daten beisammen sind, um effizient eine SD-Karte zu füllen. SD-Karten haben teilweise erhebliche Latenzen, da abhängig von den internen Operationen mal moderate und mal sehr lange Schreibzeiten auftreten können. Wenn man das mit alternierenden Puffern im FRAM durchführt, dann verknüpft man die deterministisch latenzfreien Schreiboperationen von FRAM mit der Kapazität von SD-Karten und vermeidet dank FRAM den Verlust der bei Logfiles wichtigen jüngsten Daten.
:
Bearbeitet durch User
A. K. schrieb: > Ich habe die in Flash Medien integrierten wear levelling Verfahren etwas > anders in Erinnerung. Denn man kann zwar nur grosse Blöcke lesen, aber > darin sehr wohl inkrementell schreiben. Es gibt da offenbar signifikante Unterschiede. Ich habe da einen Kartentyp im Dauerschreibtest, wo laufend eine kleine 1kB Datei drauf geschrieben wird. Die Karte war anfänglich nach knapp 3-4 Tagen kaputt. Eine Analyse ergab, dass nur ganz wenige Sektoren verwendet waren und die Karte lokal kaputt geschrieben wurde. Allein eine Änderung der Wearleveling Strategie in der Software brachte dann die Karte im Dauerschreibtest auf eine Lebensdauer von über einem Jahr. Also eine Steigerung um den Faktor 100. Der Witz ist, dass die üblichen SD Karten für kleine Dateien eigentlich gar nicht ausgelegt sind, weil sie ja meistens 1. nur große Dateien (Fotos, Filme) beinhalten und 2. nur selten beschrieben und 3. kaum gelöscht werden. Peter II schrieb: > dann schreibt man ebend die 10byte in einen Block. (4k?). Dann passen > auf eine 16GB karte immer noch 40Mbyte Daten. Darauf hast du eh' keinen direkten Zugriff. Was dir die Karte als Blockadresse vorgaukelt, hat nicht arg viel mit dem zu tun, was sich im Flashbaustein der SD abspielt.
:
Bearbeitet durch Moderator
A. K. schrieb: > SD-Karten haben teilweise erhebliche Latenzen, da > abhängig von den internen Operationen mal moderate und mal sehr lange > Schreibzeiten auftreten können. Hängt sehr davon ab, wieviel Mal die Karte schon beschrieben worden ist und vor allem, mit wieviel Daten pro Schreiboperation. Jeweils nur 12Byt auf eine SD-Karte zu schreiben ist auf jeden Fall, na ja, das Gegenteil von klug... A. K. schrieb: > Wenn man das mit alternierenden Puffern im FRAM durchführt, dann Ja, genau. Oder man macht es mit internem RAM als Puffer und benutzt einen Akku zur Sicherheit. Ray M. schrieb: > sd-card scheint mir aktuell die einzige option zu sein, nur > die gibt es auch nur noch ab 4gb und das ist doch schon ein wenig > overkill und relativ langsam Warum ist das ein Overkill ? Du kannst auch nur 64MB davon beschreiben, ist ja nicht verboten... Und wenn du 60 Dateien mit jeweils 64MB anlegst und Datenblöcke zwischenpufferst, brauchst du dich auch nicht um Wearleveling zu kümmern. Jedenfalls nicht bis Jahr 2089... :-) P.S. Bei 4 Euro für eine 4GB SD-Karte sollte auch ein Auswechseln alle 2 Jahre nicht so sehr schmerzen.
Lothar M. schrieb: > Die gängigen NVRAMs sind auch eher im SubMB Bereich angesiedelt. Wenn > "viel Speicher" verlangt wird und der bezahlbar sein soll, bleibt > eigentlich nur eine (mikro)SD Karte. Oder SPI-NOR-Flash: https://www.micron.com/products/nor-flash/serial-nor-flash 128MBit - 2GBit ist jetzt genau zwischen EEPROM und SD-Karten angesiedelt. Die Ansteuerung ist deutlich einfacher, als bei einer SD-Karte.
Ray M. schrieb: > das ist die anwendung die ich möglichst einfach haben will und > "wear leveling" sieht im code nicht nur scheisse aus, es ist für > jemanden > der da reinschaut nicht ohne weiteres zu erschliessen was sich sein > vorgänger da denn so ausgedacht hat Ich weiß nicht, was Du immer mit dem "wear leveling" hast. Du brauchst nur eine Möglichkeit, um nach dem Einschaltreset zu erkennen, an welchem Sektor (64kB) Du anfängst, weiter zu schreiben und diese Adresse ist dann Dein Pointer. Du mußt im Flash also nicht eine Datei öffnen, sondern schreibst einfach an die Adresse und zählst sie hoch. Den Platz am Ende eines Sektors, wo kein Datenrecord mehr reinpaßt, läßt Du frei. Und am Flash-Ende machst Du einen Wraparound. Nach dem Einschaltreset das erste Byte jedes Sektors zu lesen, ob es 0xFF ist, kostet kaum Zeit.
Hurra schrieb: > Lothar M. schrieb: >> Die gängigen NVRAMs sind auch eher im SubMB Bereich angesiedelt. Wenn >> "viel Speicher" verlangt wird und der bezahlbar sein soll, bleibt >> eigentlich nur eine (mikro)SD Karte. > > Oder SPI-NOR-Flash: > https://www.micron.com/products/nor-flash/serial-nor-flash > > 128MBit - 2GBit ist jetzt genau zwischen EEPROM und SD-Karten > angesiedelt. das scheint für mich super zu passen, nur gilt eigentlich überschreiben als löschen ??? weil im datenblatt steht – Minimum 100,000 ERASE cycles per sector dann wären wir ja wieder bei "wear leveling", hätten aber schonmal die speichergröße besiegt ;) > Die Ansteuerung ist deutlich einfacher, als bei einer SD-Karte. gibt es da eine lib für oder geht das wie üblich bei µc's zu fuß ? und eine referenz-beschaltung, weil im datenblatt konnte ich keine finden ;(
Ray M. schrieb: > das scheint für mich super zu passen, nur gilt eigentlich überschreiben > als löschen ??? Natürlich. Das ist Flash. Das ist immer das gleiche - das sind im Endeffekt Löschzyklen. Um zu schreiben, muss man löschen. Darum herum kommt man nur mit FRAM oder MRAM. MRAM hätte unbegrenzte Schreibzyklen, ist aber klein und teuer. Zum Support: Da muss ich passen. Wenn das so ähnlich wie ein M25Pxx - SFLASH ist, dann ist es sehr einfach. Goole spuckt das hier aus: https://www.micron.com/~/media/documents/products/other-documents/micron_stmicroelectronics_compatibility_guide.pdf?la=en Alsoist offensichtlich irgendeine Art von Lib zu bekommen.
Ray M. schrieb: > dann wären wir ja wieder bei "wear leveling", hätten aber schonmal > die speichergröße besiegt ;) Peter D. schrieb: > Ich weiß nicht, was Du immer mit dem "wear leveling" hast. Das frage ich mich auch. Ray M. schrieb: > für meine logdaten nehme also wie bisher eine micro-sd, ich schreib da > aktuell 10mal/sec rein, dass funktioniert gut Dann schreib doch 10 Mal in deinen RAM-Puffer rein und dann einmal pro Sekunde volle 512 Byt auf die SD-Karte. Ergibt bei 4GB etwa 8 Millionen Sektoren = alle 3 Monate ist die Karte voll. Und das ist erst ein Zyklus, das ist Lichtjahre davon entfernt, um vom Wearleveling auch nur bemerkt zu werden. Und FAT wird in der Zeit auch nur 32 Mal pro Sektor beschrieben, auch kein Problem...
Hurra schrieb: > Oder SPI-NOR-Flash: > https://www.micron.com/products/nor-flash/serial-nor-flash Ändert nichts grundlegend an der Wearleveling Thematik. Man merkt die schlechte Firmware nur erst später... Marc V. schrieb: > Und das ist erst ein Zyklus, das ist Lichtjahre davon entfernt, um > vom Wearleveling auch nur bemerkt zu werden. Du vergisst die Bytes, die von der Kartenverwaltung benötigt werden. Denn die Karte sollte ja wissen, wo die aktuellen Daten zu finden sind. Denn wie gesagt: das, was du aussen an Blöcken, Sektoren, Pages usw. siehst, hat mit dem Flash-Inhalt nicht unbdingt viel zu tun.
:
Bearbeitet durch Moderator
das theme mit der sd-card ist nicht mein problem, ich schreibe meine log-daten auf eine sd und das funktioniert 1a ohne jegliche probleme !!! ich schreibe aktuell gleichzeitig statistiken in einen nicht flüchtigen speicher (aktuell fram) mit, funktioniert auch 1a ohne probleme jetzt bin ich doch aus versehen auf die idee gekommen das man den speicherchip vergößern könnte und sich damit die sd-card sparen könnte, auch aus der sicht von mechanischen anforderungen, viele vibrationen, labbbbbrige sd-card-slots usw... das war anscheinend keine gute idee ... danke trotzdem für alle anregungen, tips und hinweise ...
@Ray M. (ray_m) >das theme mit der sd-card ist nicht mein problem, >ich schreibe meine log-daten auf eine sd und das funktioniert >1a ohne jegliche probleme !!! Dann ist das Problem des faulen Programmierers doch gelöst. >ich schreibe aktuell gleichzeitig statistiken in einen nicht flüchtigen >speicher (aktuell fram) mit, funktioniert auch 1a ohne Probleme Noch ein Problem weniger! >jetzt bin ich doch aus versehen auf die idee gekommen das man >den speicherchip vergößern könnte und sich damit die sd-card sparen >könnte, auch aus der sicht von mechanischen anforderungen, >viele vibrationen, labbbbbrige sd-card-slots usw... Kann man. Wenn man einen Mindestmaß an Aufwand in die Software steckt und ein EINFACHES Wear Leveling einbaut. Das ist nicht sonderlich kompliziert, ein Ringpuffer ala FIFO reicht meistens. Damit werden reihum alle Pages/Sektoren mit Daten beschrieben und somit die Belastung gleichmäßig verteilt. Packt man in das Datenpaket noch eine 32 Bit Seriennummer, findet man auch immer wieder das letzte, gültige Datenpaket. >das war anscheinend keine gute idee ... Unsinn.
Lothar M. schrieb: > Hurra schrieb: >> Oder SPI-NOR-Flash: >> https://www.micron.com/products/nor-flash/serial-nor-flash > Ändert nichts grundlegend an der Wearleveling Thematik. Man merkt die > schlechte Firmware nur erst später... Das stimmt. Trotzdem sprich - im Vergleich zu einer SD-Karte - viel für das NOR-Flash als Massenspeicher an einem µController: - Temperaturbereich - Platzbedarf - definierte Qualität / Schreibzyklen (Consumer-SD-Karten sind fragwürdig..) - definierte Lebensdauer - Stromverbrauch - Overhead in der Software geringer - deterministisches Zeitverhalten - Verträgt höhere Beschleunigungen - Fallweise der Preis (unklar) Eben so einige kleine Vorteile, die so ein Flash der SD-Karte voraus hat. Aus dem Bauch heraus hätte ich gesagt, dass ein fest verlöteter Speicher in den Punkten Preis, Qualität und Zuverlässigkeit die weit bessere Wahl für die Anwendung ist. Drum mein Vorschlag.
Wäre zwar old-school: SRAM und Lithium-Knopfzelle. Hält auch zuverlässig 10 Jahre+
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.