Hi,
ich habe hier einen kleinen Microcontroller, welcher ein Speichermedium
in Form einer FatFS-formatierten microSD-Karte besitzt. Der Controller
selber zählt auch eine Art Seriennummer, die irgendwie gespeichert
werden muss, damit sie nach einem Neustart wieder zur Verfügung steht
und nicht von vorne begonnen wird.
Mein Problem jetzt: diese Nummer kann sich sehr häufig (d.h. sekündlich)
ändern. Wenn ich jetzt jedes mal in eine Datei auf der Karte schreibe -
welche Auswirkungen hat das auf diese? Komme ich da nicht sehr schnell
an die maximale Anzahl Schreibzyklen ran oder ist FatFS so clever, das
jedesmal wo anders hinzuschreiben, auch wenn ich jedes mal in die
gleiche Datei schreibe?
Alternative Speichermöglichkeiten wie EEPROM o.ä. existieren leider
nicht.
Danke!
Zorg schrieb:> oder ist FatFS so clever, das> jedesmal wo anders hinzuschreiben, auch wenn ich jedes mal in die> gleiche Datei schreibe?
Das hat mit FAT oder nicht FAT erstmal nichts zu tun, für etwaige
Vermeidung von Wear-Out einer SD Karten Zelle ist der Kartencontroller
(in der SD Karte) zuständig. Und wie es immer so ist, da man da nicht
reinschauen kann, gibt es einige gute und einige schlechte Strategien.
Wenn du es mit einem Diskettenlaufwerk zu tun gehabt hättest, würdest du
dir die Strategie sowieso nochmal überlegen. Ich an deiner Stelle würde
am Anfang dein Datum vom Medium laden und dann MC intern halten.
Zurückspeichern eben nur, wenn sich was ändert, oder der MC abgeschaltet
wird.
Grob gesagt, kann eine einzige Flashzelle etwa 100.000 - 500.000
beschrieben werden, dann ist Ende Banane.
Matthias Sch. schrieb:> Das hat mit FAT oder nicht FAT erstmal nichts zu tun
Hm, warum wurden dann in der Linux-Welt spezielle Flash-taugliche
Dateisysteme geschaffen?
> Zurückspeichern eben nur, wenn ... der MC abgeschaltet wird.
Genau das ist mein Problem: es gibt kein Shutdown, wenn der MC
abgeschaltet wird, ist es zu spät, ich MUSS also vorher schon
gespeichert haben.
Das ganze wird daran scheitern, dass die Karte gelegentlich mehr als 1
Sekunde zum Schreiben braucht. Und selbst wenn nicht: bei einem
Stromausfall beim Schreiben ist die Karte Schrott (naja, nicht jedes
Mal). Man braucht also eine Mini-USV. Und wenn man die hat, braucht man
nicht mehr so oft zu schreiben...
Man kann das Dateisystem umgehen und direkt auf die Karte schreiben. Das
halbiert die Anzahl der geschriebenen Blöcke zumindest (normal würde ja
auch noch der Zeitstempel im Verzeichnis aktualisiert).
Apropos "Zeitstempel": hat der Rechner eine RTC? Die (umgerechnete)
Uhrzeit ist auch eine Art Seriennummer. Oder man missbraucht die
Alarmregister als Speicher.
Wenn auf der Karte reichlich Platz ist, organisiert man den als
Ringpuffer und schreibt die Nummer im Abstand von z.B. 4096 Byte.
Angenommen, die Karte verwendet 4K-Pages, man spendiert 1GB für den Ring
und schreibt 1 mal pro Sekunde, dann hat man nach 8 Jahren 1000 Zyklen
pro Page.
Das natürlich ohne Dateisystem-Overhead. Das ist aber kein Problem: man
schreibt einmalig ganz normal eine Datei in der passenden Größe voll und
schreibt die Daten dann mit seek() relativ zum Anfang der Datei. Oder
noch besser auf absolute Sektornummern.
> Hm, warum wurden dann in der Linux-Welt spezielle> Flash-taugliche Dateisysteme geschaffen?
Da gibt es zwei Aspekte:
1) Weil die Controller von SSD performanter arbeiten, wenn sie wissen,
welche Zellen belegt und welche frei sind, können aktuelle
Betriebsysteme dies dem Flash Controller mitteilen.
Davon profitieren alle Filesysteme, denn sie nutzen nicht das
Inhaltsverzeichnis, um diese Info selbst zu erzeugen.
2) Die meisten Filesysteme wurden für magnetische Scheiben gestaltet.
Sie bemühen sich, die Bewegungen des Schreib-lesekopfes zu minimieren,
auch wenn dadurch andere Aspekte schlechter werden. So belegt das FAT
Filesystem den Datenträger in relativ großen Blöcken, auch wenn die
Dateien selbst nur wenige Bytes enthalten.
Für SSD ist diese Optimierung sinnlos (es gibt keine Mechnik), und die
damit verbundenen Seiteneffekte reduzieren ihre Performance unter das
Optimum.
> es gibt kein Shutdown, wenn der MC abgeschaltet wird,> ist es zu spät, ich MUSS also vorher schon gespeichert haben.
EEprom Speicher sind schnell genug, um während des Absinkens der
Abschaltens noch schnell ein paar Bytes zu speichern. Netzteile können
die Spannungsversorgung typischerweise einige zig Millisekunden lang
aufrecht erhalten.
Zorg schrieb:> Genau das ist mein Problem: es gibt kein Shutdown, wenn der MC> abgeschaltet wird, ist es zu spät, ich MUSS also vorher schon> gespeichert haben.
Du hast dein Problem sehr gut beschrieben, ziehst leider nur die
falschen Schlüsse. Ein Stromausfall beim Schreiben ist bei FAT in vielen
Fällen tödlich. Da würde nur etwas wie jfs oder ext3 von Linux helfen.
Wenn du aber ohnehin den bevorstehenden Tod erkennen musst, um definiert
in die Grube zu fahren, kannst du auch noch schnell in ein (serielles
externes) EEPROM deine Daten schieben. 20ms lassen sich mit einem
passenden Kondensator noch stützen und reichen bestens aus für den
geregelten Shutdown.
Zorg schrieb:> ich habe hier einen kleinen Microcontroller
Was ist es denn für einer?
Wenn du die Pins fürs SD hast, kannst du evtl. auch noch 2 oder 3 für
einen I²C oder SPI EEPROM opfern, dann hast du selbst bei einem Shutdown
noch Zeit zum Daten schreiben.
Hallo
Die Lösung, so wie ich es gemacht habe, ist diese.
Einen Uhrenbaustein DS1388Z nehmen, der zugleich Eeprom (i2C) und
Resetbaustein (Spannungsüberwachung ist).
Der Reset ist nicht wichtig... war aber dabei...
Dann den Hauptversorgungs 5Volt Kreis mit vieeeellll Puffer C für den
Mikrocontroller bauen.
Dieser darf aber nicht rückwärts speisen. Sprich darf nur in eine
Richtung Strom fliessen lassen. Dies bedeutet, zum Beispiel die
Hauptversorgung ist 5V. Dann eine 1N4007 in Reihe in die Plus Leitung
zum 5V Regler/Wandler.
Anschliessend von der Primären Stromversorgung mit passenenden
Vorwiderstand auf eine 4,7V Zenerdiode gehen und diese mit einen INTx
(Interrupt Eingang verbinden). Pulldown Widerstand ca. 10k am Eingang
nicht vergessen.
Wenn nun die Versorgung wegfällt, bricht die Spannung an der Zenerdiode
zusammen und löst einen Interrupt aus.
Die CPU kann jetzt noch die Uhrzeit lesen, und die Seriennummer ins
eeprom der Uhr schreiben. Danach in eine Endlosschleife gehen und warten
bis der Strom ausgeht.
Beispiel 12V Versorgung:
R=U/I = 12-4,7V/0,005 = 1460 Ohm, sprich 1K5 um den Strom zu begrenzen
an der Zenerdiode.
Bei klappt das. Und das seit Jahren.....
Gruß Thomas
Schaulus Tiger schrieb:> Angenommen, die Karte verwendet 4K-Pages, man spendiert 1GB für den Ring
SD Karten verwenden intern Pages in MB Größe, 1MB und 4MB sind gängig.
Bei SDXC dürfen die Pages IIRC sogar noch größer sein.
die sd-karte is ja schon per spi angeschlossen
ein zusätzliches eeprom mit spi würde allso nur noch eine weitere
CS-leitung brauchen (oder kann man CS mit einem inverter doppelt
belegen?)
Zorg schrieb:> Hm, warum wurden dann in der Linux-Welt spezielle Flash-taugliche> Dateisysteme geschaffen?
Weil die (JFFS2, UBIFS) für "nackte" Flash-Bausteine entwickelt wurden,
wo die Hardware kein Wear-Levelling macht. Eine SD-Karte macht das aber
- je nach Hersteller mehr oder weniger gut.
Schaulus Tiger schrieb:> Ich dachte, die Flash-Chips müssen immer 2K oder 4K auf einmal> schreiben. Dass die kleinste löschbare Einheit min. 1MB groß ist,> ist klar.
Mag sein. Aber es ist egal, wie du eine SD-Karte behandelst: Du hast
keine Ahnung, was der SD-Karten-Controller dadraus macht und wie er
den Flash behandelt.
