Ich habe vor, einen kleinen Datenlogger zu bauen. Jetzt habe ich das Problem, den richtigen Speicher dafür zu finden. Ich muss, je nach Einstellung des Loggers, zwischen 4 und 18 Bytes aufzeichnen, im worst case jede Sekunde, maximal aber nach einer Stunde. Es soll dabei mindestens einen Monat lang aufgezeichnet werden können, daher sind bei 18 Bytes jede Sekunde ca. 45MB nötig. Eine serielle Ansteuerung ist wünschenswert. SD-Karte: Gute und günstige Lösung. Hat jedoch den Nachteil, dass nur Blöcke von 512 Bytes geschrieben werden können. Im schlimmsten Fall (4 Bytes jede Stunde) dauert es 128 Stunden bis genug Daten gesammelt wurden, um einen Block zu füllen. Dabei ist mir das Risiko zu hoch, dass in der Zwischenzeit die Daten verloren gehen (z.B. Stromausfall). Ich hatte die Idee, während dieser Zeit die Daten in einem nichtflüchtigen RAM (gepuffertes SRAM oder FRAM) zu sichern. Ausserdem müsste ich einen Pegelwandler verwenden, da die restliche Elektronik mit 5V läuft. Eine SD-Karte hätte jedoch den Vorteil, dass die Daten schnell auf einen PC übertragen werden könnten. Flash: Sind eher günstig, aber in diesen Grössen leider nur mit paralleler Ansteuerung erhältlich, was sich aber mit Schieberegistern mehr oder weniger beheben liesse. Habe Flash-Bausteine mit einer Blockgrösse von nur 64B gefunden, das wären dann 16 Stunden (4 Bytes jede Stunde). Das ist mir immer noch zu heikel, hätte also das selbe Problem wie bei der SD-Karte. EEPROM: Sind bei Farnell nur bis 128kB erhältlich, haben aber den Vorteil, dass jedes Byte einzeln geschreiben werden kann. Der Speicher reicht im worst case nur ca. 2 Stunden (18 Bytes jede Sekunde). FRAM: Das selbe Problem wie beim EEPROM. Sind zwar bis 512kB erhältlich, sind aber schweineteuer. Gepuffertes SRAM: Bei Farnell nur bis 1MB erhältlich (als BGA bis 8MB) und nicht seriell. Die Daten bleiben ausserdem nur erhalten, solange die Batterie/Kondensator nicht leer ist. Kennt jemand einen nichtflüchtigen Speicher in dieser Grösse, bei dem man jedes Byte einzeln schreiben kann? Wenn möglich seriell. Ich könnte mich mit max. 4 Speicherbausteinen anfreunden, mehr halte ich nicht für sinnvoll. Ansonsten wird es wohl auf die Lösung mit der SD-Karte und dem FRAM hinauslaufen. Vielen Dank für eure Antworten!
Hallo be stucki, SD Karte: Du könntest doch zunächst in einen 512 Byte Block schreiben. Wenn neue Daten gespeichert werden müssen, liest du den alten Blockstand aus, fügst die neuen Daten hinzu und speicherst den aktualisierten Block wieder ab. Ist der Block voll, schreibst du in den nächsten. Wo wäre das Problem nur 4 Byte in einen 512 Block zu schreiben, wenn du ne GB Karte hast?
> Du könntest doch zunächst in einen 512 Byte Block schreiben. Wenn neue > Daten gespeichert werden müssen, liest du den alten Blockstand aus, > fügst die neuen Daten hinzu und speicherst den aktualisierten Block > wieder ab. Ist der Block voll, schreibst du in den nächsten. Diese Idee hatte ich auch bereits. Hier ist das Problem, dass unter Umständen jede Sekunde aufgezeichnet werden muss und sich damit die Lebensdauer der Karte stark verringern würde. Die Zeit zwischen zwei Aufzeichnungen ist von den Eingangswerten (die, die aufgezeichnet werden) abhängig und nicht voraussehbar. Es wäre natürlich möglich, zwischen zwei Schreibzugriffen auf den selben Block eine bestimmte Zeit zu warten, damit sich die Zugriffe in Grenzen halten. > Wo wäre das Problem nur 4 Byte in einen 512 Block zu schreiben, wenn du > ne GB Karte hast? 1GB / 512 = 2MB
Wieso kannst du nicht einen Block in dem Ram deines Controllers "sammeln" und dann in einem Rutsch schreiben?
be stucki schrieb: > 1GB / 512 = 2MB 512 was? Germknödel? Hat unser Professor immer gefragt. Eine 1GB Karte hat demnach 2M 512B Blöcke, oder? Ein Monat hat 2,592M Sekunden. Demnach käme man mit einer 2GB Karte sogar noch ohne SDHC aus und könnte jede Sekunde deine maximal 18 Bytes speichern (oder auch bis zu 512). Wenn ich keinen Denkfehler drin hab ;) mfg
Das wäre auch meine Idee gewesen, im RAM puffern und dann ab auf die Karte. Falls dir das nicht sicher genug ist (Versorgungsausfälle) kann man die auch mit einer kleinen Batterie stützen. Oder auch grössere Datenmengen als 512Byte in einem externen Speicher sammeln (batteriegestützer SPI/I2C-RAM oder gleich einen FRAM. Aber der interne RAM sollte genügen.
> 1GB / 512 = 2MB
falsch gerechnet.
1GB / (512B/Block) = 2.1E6 Blöcke
bei 1 Block (à 512B) pro Sekunde
-> 2 Millionen Sekunden = 23 Tage
ganz abgefahrene Idee... Ich weiss ja nicht, wieviel Aufand du in die Prozessor-Geschichte stecken willst, aber wenn dein Datenlogger irgendwie Zugang zum Netz hätte, dann könntest alle paar Minuten eine Textdatei auf irgendeinem Netzlaufwerk (oder sogar Webspace) per FTP mit deinen gesammelten Messwerten aktualisieren..
Ja, meine "Rechnung" ist schlecht. Ich wollte damit sagen, dass ich 2M Blöcke zur Verfügung habe und diese so nicht für einen Monat reichen werden. Jochen schrieb: > Wieso kannst du nicht einen Block in dem Ram deines Controllers > "sammeln" und dann in einem Rutsch schreiben? be stucki schrieb: > Im schlimmsten Fall (4 Bytes jede Stunde) dauert es 128 Stunden bis > genug Daten gesammelt wurden, um einen Block zu füllen. Dabei ist mir > das Risiko zu hoch, dass in der Zwischenzeit die Daten verloren gehen. A0 S0 schrieb: > Demnach käme man mit einer 2GB Karte sogar noch ohne SDHC aus > und könnte jede Sekunde deine maximal 18 Bytes speichern Ja das stimmt, ist zwar die reinste Speicherverschwendung aber so würde es gehen. H.joachim Seifert schrieb: > Falls dir das nicht sicher genug ist (Versorgungsausfälle) kann man die > auch mit einer kleinen Batterie stützen. Oder auch grössere Datenmengen > als 512Byte in einem externen Speicher sammeln (batteriegestützer > SPI/I2C-RAM oder gleich einen FRAM. be stucki schrieb: > Ich hatte die Idee, während dieser Zeit die Daten in einem > nichtflüchtigen RAM (gepuffertes SRAM oder FRAM) zu sichern. Schlumpf schrieb: > aber wenn dein Datenlogger irgendwie Zugang zum Netz hätte Hat er nicht und wird auch nicht möglich sein, da auch ein mobiler Einsatz möglich sein soll. Ausgelesen wird er über eine USB-Schnittstelle oder wenn eine SD-Karte verwendet wird, nur diese ausgetauscht.
Hallo, ich setze seit vielen Jahren statische RAMs mit Batterie ein, Zuverlässigkeitsprobleme gibt es keine. Ich habe zwar schon Speicherkarten zurückbekommen, die wegen leerer Lithium-Batterie oder nicht mehr ladbarem Akku defekt waren - aber die waren mehr als 20 Jahre im Einsatz. Das geht sowohl allein damit oder als Puffer, bis ins Flash geschrieben wird. Gruss Reinhard
be stucki schrieb: > Gute und günstige Lösung. Hat jedoch den Nachteil, dass nur Blöcke von > 512 Bytes geschrieben werden können. Im schlimmsten Fall (4 Bytes jede > Stunde) dauert es 128 Stunden bis genug Daten gesammelt wurden, um einen > Block zu füllen. Wo ist das Problem? Warum sammelst du die Daten nicht in der Karte. Dann schreibst du den 512 Byte Block jedes mal neu, wenn 4 Byte dazukommen. Wenn du die SD-Karte 5 Jahre im Dauereinsatz hattest, tauscht du sie einfach aus. Die Kosten sind erheblich geringer, als 1/4-Stunde zusätzlicher Entwicklungsaufwand. p.s. Warum mißt du eigentlich so selten. Oft ist es günstiger mit höherer Rate aufzuzeichnen und hinterher die Daten durch ein Filter zu jagen (falls aufeinanderfolgende Punkte irgendetwas miteinander zu tun haben)
Ich benutze gerne SPI Flash/Sram/Fram als Software Implementation und eine SD-Karte am HW-USI/SPI Port und kopiere dann die Daten von einem Speicher in den anderen.
Wenn Du wirklich nur so wenige Daten hast, kannst Du die auch einfach im Flash des Mikrocontrollers speichern. Zur Not speicherst Du die einzelnen Bytes erst mal im EEPROM und kopierst die dann in den Flash. Oder Du versorgst Den Mikrocontroller einfach über einen Elko. Der hält noch genügend Spannung auch wenn der Mikrocontoller nicht mehr läuft.
Es gibt doch GoldCaps. Daher würde ich die 512Bytes einfach in das RAM des Controllers schreiben. Bei Stromausfall überlebt der Controller und sein RAM durch die gespeicherte Energie im GoldCap. Wenn der Controller im Sleep ist (1µA) kann er an 1F 2 Wochen überleben, bevor die Daten flöten gehen. Sollte reichen. Also SD-Karte dran und gut ist.
Hi >Hat jedoch den Nachteil, dass nur Blöcke von >512 Bytes geschrieben werden können. Im schlimmsten Fall (4 Bytes jede >Stunde) dauert es 128 Stunden bis genug Daten gesammelt wurden, um einen >Block zu füllen. Also bei mir sind das 128 Sekunden. MfG Spess
spess53 schrieb: > Im schlimmsten Fall (4 Bytes jede >>Stunde) dauert es 128 Stunden bis genug Daten gesammelt wurden, um einen >>Block zu füllen. > > Also bei mir sind das 128 Sekunden. > > MfG Spess bei mir sind es 128h
>Im schlimmsten Fall (4 Bytes jede >Stunde) dauert es 128 Stunden bis genug Daten gesammelt wurden, um einen >Block zu füllen. Sammle die Daten im RAM des Controllers, und spätestens nach einer vorgegebenen Zeit schreibst du sie auf die Karte, egal wie viel bisher zusammengekommen ist. Die Zeitspanne musst du halt wählen und sollte nicht bei 1 Sekunde sonder eher im Minuten oder Stundenbereich sein. Die restlichen Bytes des 512er Blocks ignorierst du dann einfach. Dann a) reichen 1GB ewig b) wirst du lange brauchen um die sd-karte zu schrotten. und wenn doch -> ne neue rein c) wirst du am schnellsten zum Ziel kommen
Wie wäre es mit einem uC der die 512Byte im RAM noch übrig hat. Zusätzlich ne Pufferbatterie wo diesen bei Ausfall der Versorgugnsspannung stützt. Er müsste dann nur erkennen dass die Versorgungsspannung weggebrochen ist, die Daten auf die SD-Karte schreiben und dann geht er in den Deep-Sleep-Mode o.ä....
Um welche Anwendung handelt es sich, wo jede Sekunde sich ein Messwert signifikant ändert? Denke auch daran, dass die Daten in irgendeiner Form weiterverarbeitet werden müssen. Wäre wirklich schön, etwas über den Anwendungsfall zu wissen.
Spendier Deiner Lösung einen Hi-Cap, den Du zusätzlich noch überwachen kannst. Dann gibt es keinen "Stromausfall", notfalls kannst Du die eine, angefangene Seite, ja kurz vor dem Schlappmachen noch in die SD-Karte schubsen. Eine SD-Karte würde ich Dir, in der Hauptsache, aus den folgenden Gründen empfehlen: 1. Kostengründe. 2. Leichte Auslesbarkeit vom PC aus. 3. Ausreichende Speicherkapazität. 4. Fertige Bibliotheken für die meisten Vielfüsser.
Microchip hat auch serielles Flash mit bis zu 64MBit. Endurance 100000 Zyklen.
Wenn Du einen µC mit FRAM verwendest, wie beispielsweise einen MSP430FR57xx, dann hast Du einerseits das Pegelanpassungsproblem für den Betrieb der SD-Karte nicht, und musst Dir andererseits keine Gedanken um irgendwelche Batteriepufferungen machen, so daß Du die Daten für einen Block der SD-Karte problemlos im "RAM" des µC sammeln kannst. Du musst nur darauf achten, daß der Startup-Code den verwendeten Speicherblock nicht bei Reset initialisiert, und daß Du einen ebenso resetfesten Schreibzeiger auf diesen Speicherblock vorsiehst.
Man kann bei Flash einen Block durchaus mehrmals beschreiben, ohne ihn zwischendurch zu löschen. Man kann dabei aber nur 1-Bits zu 0-Bits machen, effektiv also nur unbeschriebene Bereiche überschreiben. Als einfach einen Block nur einmal löschen und dann fleissig Bytes anhängen bis er voll ist. Problem gelöst.
@Sam Stimmt, aber manche brauchen die Kombinationen: ...F, ...FF, ...FFF usw. und so.
Vielen Dank für die vielen Antworten! Ihr habt mir alle sehr weitergeholfen. Sam P. schrieb: > Man kann bei Flash einen Block durchaus mehrmals beschreiben, ohne ihn > zwischendurch zu löschen. Man kann dabei aber nur 1-Bits zu 0-Bits > machen, effektiv also nur unbeschriebene Bereiche überschreiben. > Als einfach einen Block nur einmal löschen und dann fleissig Bytes > anhängen bis er voll ist. Problem gelöst. Dies ist wohl die einfachste Lösung. Das funktioniert mit der SD-Karte sicher auch, ohne dass die Lebenszeit der Karte allzusehr verkürzt wird, oder? Dass der restliche Speicher mit Einsen gefüllt ist, spielt keine Rolle, da die Datenblockgrösse jederzeit bekannt ist (aufgrund des Datenformats). Kurz zum Anwendungsfall: Einganswerte: 4x Temperatur, 2x analoger Eingang, 8x digitaler Eingang Ausgangswerte: 4x Relaisausgang, 4x Trasistorausgang (OC) Welche Signale aufgezeichnet werden sollen, kann konfiguriert werden. Der Zustand der Ausgangswerte kann in Abhängigkeit der Eingangswerte konfiguriert werden. Diese Werte (und ein Fehlercode, wenn dann ein Fehler auftritt) werden alle aufgezeichnet. Es sind folgende Aufzeichnungsmodi vorgesehen: - Jeder Wert wird nach ??s aufgezeichnet - Die Werte werden nur aufgezeichnet, wenn sie sich um einen bestimmten Wert geändert haben. - Wenn der Wert während ??s nicht aufgezeichnet wurde, wird er aufgezeichnet. Diese Modi sind frei konfigurierbar und können miteinander kombiniert werden. Das ganze wird erweiterbar aufgegleist, so dass später weitere Signale oder auch Schnittstellen aufgezeichnet werden können. Dabei möchte ich bei der Speichergrösse natürlich eine Reserve haben. Zudem könnte es sein, dass die kleinste Zeiteinheit (aktuell 1s) heruntergesetzt wird. Das ganze dient dazu, um das thermische Verhalten von Hardware (später evt. auch Mechaniken) über eine längere Zeit zu loggen. Um nicht eingeschränkt zu sein, habe ich noch einige digitale und analoge Eingänge, sowie digitale Ausgänge, die z.B. eine Hardware ausschalten wenn sie zu warm wird, hinzugefügt. Dass die Temperatur dabei sehr dynamisch als auch statisch sein kann, brauche ich wohl nicht zu erwähnen.
Das Projekt hat nun eine Weile geruht, nun gehts weiter. Ich habe mich für eine Kombination aus SD-Karte und einem FRAM entschieden. Dies aus dem Grund, weil noch andere Informationen dauerhaft gespeichert werden müssen, sich aber relativ häufig ändern können (ca. 300 - 400 Bytes). Ausserdem ist der Schaltungsaufwand minimal. Ich werde den FM24C16B-G von Ramtron verwenden (2kB, I2C, 5V).
Ich persönlich würde das verwenden was gut auf dem Markt vorhanden ist und keinesfalls eine Sonderlösung darstellt. Schau dir mal das serielle Flash SST25VF064C von Microchip an. Ist preislich sehr interessant und ist sogar bei Reichelt erhältlich: SST25VF064C
> Ich persönlich würde das verwenden was gut auf dem Markt vorhanden ist > und keinesfalls eine Sonderlösung darstellt Es werden ca. 3 - 4 Schaltungen hergestellt. Daher ist das egal. > Schau dir mal das serielle > Flash SST25VF064C von Microchip an. Ist preislich sehr interessant und > ist sogar bei Reichelt erhältlich: Ich benötige min. 45MB, dein Bautsein hat 8MB, also müsse ich 6 ICs verwenden. Kosten aber bei Farnell 5.20CHF/Stück. Bei Reichelt in die Schweiz bestellen ist auch nicht gerade günstig. Zum Vergleich: Eine 32GB SD-Karte kostet ca. 40CHF.
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.