Hallo, nur mal ein paar kurze Fragen: Wenn ich eine SD Karte "komfortabel" benutzen möchte, dann sollte diese vermutlich im FAT16 oder FAT32 System beschrieben werden? Dies setzt voraus, dass wenigstes 512Byte gleichzeitig als Block geschrieben werden? Dies bedingt, dass die genutzten Mikrocontroller sinnvollerweise wenigstens 1024Byte RAM besitzen? mfg
@ SD (Gast) >Wenn ich eine SD Karte "komfortabel" benutzen möchte, dann sollte diese >vermutlich im FAT16 oder FAT32 System beschrieben werden? Ja. >Dies setzt voraus, dass wenigstes 512Byte gleichzeitig als Block >geschrieben werden? Nein. >Dies bedingt, dass die genutzten Mikrocontroller sinnvollerweise >wenigstens 1024Byte RAM besitzen? Nein. Es geht auch so. http://elm-chan.org/fsw/ff/00index_p.html
Falk Brunner schrieb: > Nein. Doch. Bei den heutzutage fast nur noch erhältlichen SDHC geht es gar nicht mehr anders als in 512 Byte Blöcken und bei den älteren SD Karten wäre weniger als 512 Byte ein Schreikrampf. Obendrein sollte man ohnehin ein Fat-Filesystem in der µC Firmware dabei haben, wenn man SD-Karten benutzen will, sonst kann man anderswo damit nur mit elendigen Krämpfen was anfangen. Fazit: SD nur für Controller, die genug RAM haben. Ein mir vernünftig erscheinender Wert wäre so mindestens 4 K an RAM (2K für die App, 2K für das Fatfilesystem), drunter wird es leicht zur Farce. W.S.
@ W.S. (Gast) >> Nein. >Doch. ORRRHHHHHH! https://www.youtube.com/watch?v=w4aLThuU008 ;-) >Bei den heutzutage fast nur noch erhältlichen SDHC geht es gar nicht >mehr anders als in 512 Byte Blöcken und bei den älteren SD Karten wäre >weniger als 512 Byte ein Schreikrampf. weiß ich nicht im Detail, kann sein, muss nicht. Hat das schon mal einer REAL geprüft? Der gute CHAn wird die Software nicht im luftleeren Raum geschrieben haben.
Falk Brunner schrieb: > weiß ich nicht im Detail, kann sein, muss nicht. Hat das schon mal einer > REAL geprüft? Der gute CHAn wird die Software nicht im luftleeren Raum > geschrieben haben. Kann sein, dass ihr aneinander vorbeigeredet habt. FAT kann auch kleinere Portionen als 512 Bytes als Datei schreiben. Intern wird dann natürlich auf Clustergröße "aufgeblasen" und letztlich in mindestens 512 Bytes großen Blöcken auf die SD-Karte geschrieben. Man kann eine SD-Karte auch per Mikrocontroller beschreiben, ganz ohne das RAM zu verwenden, aber es ist schon sehr mühsam. Entweder man verzichtet komplett auf ein Dateisystem, oder man bildet es rudimentär nach. Ich hatte so einen Fall mal mit einem ATtiny85, der als Datenlogger verwendet wurde. Geht durchaus, solche Verrenkungen rentieren sich aber normalerweise nicht, wenn du ein Einzelstück entwickelst. Außer, du siehst das als Herausforderung und magst ein bisschen knobeln. :-)
Ich möchte eine alte SD-Karte zum Datenloggen für einen Mikrocontroller verwenden. Dabei habe ich gerade festgestellt, dass auf der FAT16 formatierten Karte ein Cluster eine Größe von 16kByte hat. Also sollte die Karte besser mit FAT32 und 512 byte "großen" Clustern formatiert werden. Oder gibt es Nachteile /Schwierigkeiten bei Mikrocontrollern und FAT32?
Daniel H. schrieb: > Also sollte die Karte besser mit FAT32 und 512 byte "großen" Clustern > formatiert werden. Damit die Karte durch viele unnütze FAT Zugriffe schneller kaputt geht? Cluster will man für den µC Betrieb fast immer mögichst gross haben. Und nein, die muss man nicht am Stück schreiben.
Ich kann deiner Argumentation nicht folgen. Meine Argumentation ist folgende: Um die Karte nicht durch übermäßige Schreibzyklen zu verschleißen, soll bei einer kleinen Änderung der Log-Datei nur ein kleines Cluster geschrieben werden. Entsprechend bei zwei Änderungen (maximal) zwei Cluster. Bei großen Clustern müssten bei zwei kleinen Änderungen zwei große Cluster und somit ein deutlich größerer Speicherbereich neu geschrieben werden. Oder übersehe ich etwas?
Daniel H. schrieb: > Um die Karte nicht durch übermäßige Schreibzyklen zu verschleißen, soll > bei einer kleinen Änderung der Log-Datei nur ein kleines Cluster > geschrieben werden. > [...] > Oder übersehe ich etwas? Auch bei großen Clustern schreibt man nur den jewails geänderten 512 Byte Sektor auf die Karte. Grade bei Logdateien sollten die Cluster nicht zu klein sein, denn man mus einmal pro Cluster auf die FAT zugreifen. Betrachtet man die für Logdateien übliche Operation Append (Öffnen und ans Ende der Datei springen), so hat man für eine 5 kB Datei bei 512 Byte Custern 10 davon. Die muss man bei jedem weiteren Append wieder aus der FAT einlesen. Bei 16 kB Cluster muss man dagegen die FAT gar nicht lesen, solage die Datei kleiner als 1 Cluster bleibt - denn der erste Cluster steht im Verzeichniseintrag. Die FAT wird also nicht nur seltener geschrieben, sie wird - zumindest bei auf µCs üblichen minimalen Implementationen - auch seltener gelesen, was mehr Performance bedeutet.
Mach es doch unkomfortabel: ganz ohne Filesystem und schreib einfach roh drauf. Zum Lesen nimmst du Linux, damit kann man auch rohe Devices wieder zurücklesen. Die Aufbereitung kann ja dann der Compi übernehmen
Also müssten folgende Aussagen zutreffen? 1. Bei einem Schreib- / Appendprozess werden immer 512 byte Häppchen geschrieben. 2. Gelöscht wird jedoch ein kompletter Cluster. 3. Die Clustergröße ist primär nur für Minimierung von Lese-/ Schreibzugriffen auf die FAT interessant. (Anwendung als Datenlogger, KEIN "Betriebssystem" mit vielen kleinen Dateien.)
Daniel H. schrieb: > Also müssten folgende Aussagen zutreffen? > > 1. Bei einem Schreib- / Appendprozess werden immer 512 byte Häppchen > geschrieben. Na ja, ein Datenblock, evl. noch der nächste je nach Datenmenge, bzw. Lager der nächsten Blockgrenze. Dann der Block mit dem Verzeichniseintrag um die Länge/Datum zu akualisieren. Ist ein Cluster voll kommt noch ein Block in der FAT hinzu um den nächten Cluster zu reservieren > 2. Gelöscht wird jedoch ein kompletter Cluster. Nein - gelöscht wird nur der Verzeichniseintrag (ein Block) und der Eintrag in der FAT (ein oder mehrere Blöcke je nach Größe der Datei) > 3. Die Clustergröße ist primär nur für Minimierung von Lese-/ > Schreibzugriffen auf die FAT interessant. Jain - in einem Dateisystem muss man mehrere pysikalische Blöcke zu Clustern zusammenfassen, weil sonst irgendwan mehr Speicher zur Verwaltung des selbigen Verbraucht wird als zum Speichen von Nutzdaten Sascha
Daniel H. schrieb: > 1. Bei einem Schreib- / Appendprozess werden immer 512 byte Häppchen > geschrieben. SD Karten lassen Schreibvorgänge nur in 512 Byte Blöcken (und Vielfachen davon) zu. Bei SDHC Karten betrifft dies auch alle Lesevorgänge. > 2. Gelöscht wird jedoch ein kompletter Cluster. Gelöscht im Sinne von "Überschrieben" wird normalwerweise nix. Beim Löschen einer Datei werden in der FAT die entsprechenden Cluster als "frei" markiert, der Verzeichniseintrag ebenfalls, das ist alles.
Flash-Adresse und Blocknummer haben meist nichts miteinander zu tun. Eine halbswegs ordentliche Flash-Karte verwendet für einen Block nicht immer dieselben Speicherzellen. Die Karten versuchen selbstständig, ihre Speicherzellen relativ gleichmäßig zu benutzen. Dadurch macht man diese auch nicht so schnell kaputt.
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.