Kurze Fragen zu SD Karten

@ 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

@ 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.

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.