SD-Karten ansprechen, Größe der Sektoren?

die wirst du vermutlich auch nur im Datenblat von der Sd karten finden, 
denn die Hersteller können es ja selber festlegen. Gibt es dafür nicht 
extrem die möglichkeit sie abzufragen?

Ich verwende hier einen Open-Source-Treiber für SD-Karten ( EFSL: 
http://sourceforge.net/projects/efsl/ ).

Mit einer 1GB-Karte funktioniert das Ganze. Wenn ich das Programm 
debugge, zeigt mir der Treiber eine Sektorgröße von 512 Byte.

Wenn ich eine 2GB Karte reinstecke, funktioniert das ganze nicht mehr. 
Der Treiber zeigt mir eine Sektorgröße von 1024 Byte.

Nach allem was ich gelsen habe, sollte EFSL auch mit Karten größer asl 
1GB zurecht kommen. Jetzt ist die Frage, ob es auch 2GB Karten mit einer 
Blockgröße von 512 Bytes gibt und es damit sein kann, dass es je nach 
Karte geht oder eben nicht.

Vielen Dank für eure Antworten.

>Meine 4GB-microSDHC Karte hat Sektorgrößen von 512Byte. (Intenso)
Interessant, die Blockgrößen scheinen also nicht unbedingt direkt mit 
der Karte zusammen zu hängen.

>Setze selbst inzwischen nur noch die Library FatFS von ChaN ein
Die Umstellung von EFSL auf den Chan-Code würde jetz natürliche einiges 
an Aufwand bedeuten.
Der Programmierstiel von ChaN ist auch ein deutlich anderer als in der 
EFSL. Sieht compakter aber auch unübersichtlicher aus.

>Soweit ich weiß, haben auch größere Karten Sektorgrößen von 512Bytes.
>Die Karten haben u.U. größere Cluster, aber die Sektoren können dennoch
>einzeln angesprochen werden.

Den Karten kann man verschiedene Kommandos senden. Mit dem Kommando16 
lässt sich die übertragene Blocklänge einstellen:

CMD16   //! Set block length.

Ich frage mich, ob mir das etwas nutzen könnte.

Mir ist auch noch keine SD-Karte mit einer anderen Sektorgröße als 
512Byte untergekommen, egal welche Speicherkapazität sie haben und egal 
ob SD oder SDHC. Auch mein 8GB Karte hat 512 Byte Sektoren.

>Wenn ich eine 2GB Karte reinstecke, funktioniert das ganze nicht mehr.
>Der Treiber zeigt mir eine Sektorgröße von 1024 Byte.

Bei 2GB Karten sehr ungewöhnlich. Ich habe eine 4GB Karte die keine SDHC
ist und 1kB Sektoren im CSD meldet. Die Angabe wird aber nur für
die Berechnung der Sektorzahl benötigt. Die wahre Sektorgröße ist
512 Byte. Damit funktioniert die Karte auch. SDHC Karten haben auch
alle 512 Byte Sektoren.

Nachtrag:

>Bei 2GB Karten sehr ungewöhnlich.

Tatsächlich ist das gar nicht ungewöhnlich. Ich erinnere
mich wieder woran das liegt;) Die Einträge im CSD reichen
nur bei 1GB Karten aus um die Anzahl Sektoren zu berechnen
wenn die Sektorgröße 512Byte ist. Für 2GB und 4GB (non SDHC)
Karten reichen die Einträge nicht mehr aus. Deshalb wird eine
angebliche Sektorgröße von 1kB bei 2GB, und 2kB bei 4GB (non SDHC)
Karten im CSD eingetragen. Die wahre Sektorgröße ist 512 Byte.

Vielen Dank holger, für diesen nützlichen Hinweis. Für Software, welche 
die Sektorgröße anhand der Angaben im CSD Register überprüft, kann das 
zu Problemen führen. Ich glaube zumindest, dass ist bei meiner Version 
das Problem.

Gibt es eigentlich ein Programm für Windows oder Linux, mit dem man das 
CSD Register auslesen kann?

>Vielen Dank holger, für diesen nützlichen Hinweis. Für Software, welche
>die Sektorgröße anhand der Angaben im CSD Register überprüft, kann das
>zu Problemen führen. Ich glaube zumindest, dass ist bei meiner Version
>das Problem.

Hmm, ich weiss nicht;) Hab grad mal nachgesehen: EFSL liest das
CSD bis Version 3.6.0 gar nicht! Wie hast du das mit den 1kB Sektoren
festgestellt?

Das ganze Programm ist nicht von mir, ich bin nur gerade dabei es zu 
warten. Mein Vorgänger hat das Auslesen des CSD-Registers getrennt 
implementiert. EFSL ist ja nur für das FAT-Dateisystem und braucht 
eigentlich nur 4 Schnittstellenroutinen. Etwas in der Art init, 
readsector, writesector ( die 4.te weiß ich grad nicht, weil ich den 
Code nicht auf meinem Rechner habe )
An der entsprechenden Stelle ( Sektorlänge wird ) das CSD Register mit 
dem Wert "10" beschrieben ( 2GB ) und bei der 1GB-Karte mit 9.

>Das ganze Programm ist nicht von mir,

Hmm. Kleiner Tipp um dir viel Arbeit zu sparen:
Meide 2GB Karten und 4GB Karten wo kein SDHC draufsteht.
Dann hast du die Sonderfälle ausgesondert;)
Oder ignoriere read_bl_len als Sektorgrösse.

Ok, werde morgen mal sehen, ob's klappt.

Gruß,
chris

Hier der Ausdruck des CSD-Registers. Wie man sehen kann, steht die 
read_bl_len auf 10 was wohl einer Größe von 10 Bit als 1024 entspricht.

>Aber genau dafür ist doch CMD16 da. Damit kannst du der Karte mitteilen,
>dass du sie gern mit 512Byte Blöcken ansprechen möchtest.

CMD16 ist hier nicht unnötig. Der Wert für die Sektorgröße
ist ein reiner Rechenwert. Die Sektorgröße ist trotzdem 512Byte.
CMD16 hab ich bei solchen Karten noch nie benötigt. CMD16 braucht
schlicht und ergreifend niemand. Das kann sogar stören weil
einige Karten das Kommando gar nicht annehmen wollen.

>CMD16 ist hier nicht unnötig.

Öhhm, das nicht streichen;)
CMD16 ist hier unnötig.

Hmm, jetzt wird das ganze verwirrend.

Im Moment habe ich den Verdacht, dass es einen Unterschied zwischen 
Blockgröße und Sektorgröße gibt.

Kann es sein, dass das Kommando16 zur Änderung der Blockgröße für die 
Datenübertragung gedacht ist und mit der Sektorgröße nichts zu tun hat?

Hier die Kommandos laut manual.

Kann mir jemand sagen, ob bei einem FAT-Dateisystem die Sektorgröße 
immer 256 Byte große ist?
In einigen Foren wird das behauptet. Ich kann aber keine Spezifikation 
dazu finden.

>Kann mir jemand sagen, ob bei einem FAT-Dateisystem die Sektorgröße
>immer 256 Byte große ist?

Die Sektorgröße ist 512 Byte. Das geht von der Diskette bis
zur Gigabyte Platte. Erst die neuen Terabyte Platten benutzen
größere Sektoren. Punkt.

Ähm, ja, ich meinte 512 Bytes/Sektor.

>CMD16 braucht
>schlicht und ergreifend niemand. Das kann sogar stören weil
>einige Karten das Kommando gar nicht annehmen wollen.

Das EFSL unterstützt laut Manual 
http://heanet.dl.sourceforge.net/project/efsl/efsl-devel/0.3.6/manual-0.3.6.pdf 
nur Sektoren mit 512Byte Größe.

Ziemlich unpraktisch ist jetzt, wenn die SD-Karte mit Kommando CMD17 ( 
read_single_block ) einen Block mit 1024Bytes bei einer 2GB-SD-Karte 
zurückliefert. Das kann man zur Not noch abfangen, indem man einfach nur 
die 512Bytes aus dem Block nimmt, die passen.

Beim Schreiben wird es allerdings schwierig: Die SD-Karte erwartet einen 
1024 Block, es stehen aber nur 512 Bytes zum Schreiben zur Verfügung.

>Auch hab ich noch keine Karte gehabt, die auf CMD16 mit 05 (illegal CMD)
>geantwortet hätte.

Eine Frage zum CMD16: Wenn man mit dem Kommando die Blocklänge auf 512 
kürzt, wird dann im CSD-Register die "read_bl_len" Variable auch 
angepasst?

Ich habe das CMD16 mal ausprobiert, aber es scheint, als wenn 
"read_bl_len" auf 10 ( also 1024 ) bleibt.

Fabian schrieb:
>Macht z.B. die hier unter Artikel findbare AVR_FAT32 Lib auch so.

Habe mir gerade eben mal die AVR_FAT32 angesehen ( 
http://www.mikrocontroller.net/svnbrowser/avr-fat32/0.6.1/ )
Vom Code Aufbau aus sieht die Lib schon mal nicht schlecht aus.

Das CMD16 wird tatsächlich verwendet.

Unter welchem Copyright steht die Lib eigentlich? Im Header ist nichts 
dergleiche wie GPL oder BSD zu finden.

>SD-Karten (nicht SDHC!) mit mehr als 1 GB Speicherkapazität können
>durchaus auch "Sektoren" mit mehr als 512 Byte haben.

Nach meinem jetzigen Erkenntnisstand ist hierbei aber Vorsicht geboten:
Ich habe eine 2GB-SD-Karte, die zeigt mir eine FAT16 Partitionierung an. 
Die Sektorgröße der FAT ist 512Byte.

Allerdings ist die Blockgröße, welche die SD-Karte zurückmeldet 1024 
Byte. Soviel Daten werden auch bei jedem Zugriff übertragen.


Also Sektorgröße != Blockgröße


Sektrogröße ==> FAT
Blockgrößte ==> Anzahl der Daten bei Lesen oder Schreiben mit SPI

>Eine Frage zum CMD16: Wenn man mit dem Kommando die Blocklänge auf 512
>kürzt, wird dann im CSD-Register die "read_bl_len" Variable auch
>angepasst?

Nein, natürlich nicht. Die Karte würde dann ja nur noch eine
Größe von 1GB melden!

Das mit dem CMD16 und den 1024 Byte Sektorgröße scheint
von Hersteller zu Hersteller wohl frei nach Laune gestaltet
worden zu sein. Ich habe drei verschiedene 2GB Karten
und eine 4GB non SDHC die völlig ohne CMD16 auskommen.
Eine von den drei Karten meckert sogar bei CMD16.
Alle Karten laufen problemlos mit 512Byte Sektorgröße.
Der Eintrag im CSD steht nur zur Berechnung der Größe
der Karte auf 1024 oder 2048 Byte. Möglicherweise ein reiner Rechenwert.
Man könnte ja mal versuchen mit CMD16 auf 1024 Byte Blöcke
umzuschalten.

Und bei anderen Herstellern muss man CMD16 senden
damit die Karte mit 512 Byte Blöcken arbeitet.
Naja, dann sendet man halt immer CMD16, und wenn es
da knallt ignoriert man das Ergebnis halt.

>Und bei anderen Herstellern muss man CMD16 senden
>damit die Karte mit 512 Byte Blöcken arbeitet.
>Naja, dann sendet man halt immer CMD16, und wenn es
>da knallt ignoriert man das Ergebnis halt.

Mir scheint, dann könnte es beim Schreiben auf die SD-Karte ein Problem 
geben. Die Karte erwartet einen 1024er Block, bekommt vom Filesystem 
aber nur einen 512er Block. Das müsste eigentlich schief gehen.

Dazu fällt mir nur eine Lösunt ein, wie man auf die Karte schreiben 
könnte:

1. 1024er Block von der Kartte in Speicher einlesen
2. entsprechenden 512er Block im Speicher ersetzen
3. 1024er Block auf Karte zurückschreiben

Gibt es da eine einfachere Möglichkeit?

>Mir scheint, dann könnte es beim Schreiben auf die SD-Karte ein Problem
>geben.

Und heute "scheint" der Vollmond.

>Dazu fällt mir nur eine Lösunt ein, wie man auf die Karte schreiben
>könnte:

>1. 1024er Block von der Kartte in Speicher einlesen
>2. entsprechenden 512er Block im Speicher ersetzen
>3. 1024er Block auf Karte zurückschreiben

>Gibt es da eine einfachere Möglichkeit?

CMD16 benutzten und auf 512 Blockgröße stellen?
Hast du das überhaupt mal ausprobiert oder willst
du einfach nur rumsülzen?

>CMD16 benutzten und auf 512 Blockgröße stellen?
>Hast du das überhaupt mal ausprobiert oder willst
>du einfach nur rumsülzen?

Danke der Nachfrage. Ich habe den Thread nicht aus Spaß begonnen.
1. Beim Auslesen des CSD zeigt die Karte ein Blockgröße von 1024 ( wie 
weiter oben im Screenshot sichtbar )
2. Ich habe Kommando 16 ausprobiert, es ging nicht

Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
>Bei allen SC-Karten (kein SDHC), die ich bisher nativ mit einem µC
>beschrieben habe, war noch nie eine dabei, die mit einer anderen
>Sektorgrösse als 512Bytes gearbeitet hat.

Mir geht es nicht um die Sektorgröße, sondern um die Blocklänge, mit der 
die Karte arbeitet.

Eine Frage, vielleicht hat es von euch schon mal jemand ausprobiert: Was 
passiert, wenn die Karte eine Blockgröße von 1024 Byte hat, man aber nur 
512Byte schreibt? Würde die Karte beim deselektieren eventuell den 
halben Block schreiben oder einfach verwerfen?

>Das ist doch dasselbe. Ich stamme aus einer Zeit, da Disketten noch
>Sektoren hatten. Das hat sich bei mir eingebrannt und somit haben
>Speicherkarten für mich auch Sektoren ;-). Die nächstgrößere Einheit
>wären dann die Cluster.

Knut, das versuche ich ja schon die ganze Zeit zu erklären: Das 
FAT-Dateisystem hat 512Byte-Sektoren. Die SD-Karte meldet aber eine 
Blockgröße von 1024 Byte. Jetzt will der Dateisystemtreiber die 512Byte 
Sektoren schreiben, muss aber irgendwie mit der 1024er Blockgröße der 
SD-Karte zuerecht kommen.

>Danke der Nachfrage. Ich habe den Thread nicht aus Spaß begonnen.

Wirklich lustig ist er auch nicht. Irgendwie werde ich das Gefühl nicht
los das du ein wenig bockig bist und nicht verstehen willst;)

>1. Beim Auslesen des CSD zeigt die Karte ein Blockgröße von 1024 ( wie
>weiter oben im Screenshot sichtbar )
>2. Ich habe Kommando 16 ausprobiert, es ging nicht

Und ich habe oben schon geschrieben das dieser Wert ein Fake
sein kann. Der steht nur im CSD um den Speicherplatz berechnen
zu können. Da ist bei allen meinen 2GB und einer 4GB Karte bei mir so.
DIE HABEN TROTZDEM EINE SEKTORGRÖSSE VON 512Byte.

Wenn es kein Fake ist dann hilft CMD16.
Wenn CMD16 nicht hilft wirf die Karte weg!

Also ich habe einige ältere SD Karten von Sandisk mit einer Blockgröße 
von 1024 Bytes:
1GB Sandisk - Blockgröße 1024
2GB Sandisk - Blockgröße 1024
2GB Transcend - Blockgröße 1024
Der Rest sind 4GB, 8GB und 16GB mit 512 Bytes Blockgröße

Das FAT-Dateisystem unterstützt auch Sektorgrößen von 512, 1024, 2048 
usw.

Allerdings ist die Partitionstabelle auf 512 Bytes hart codiert, was die 
Blockgröße hier nun einschränkt.
Das andere Problem ist, dass die meisten Treiber und anderes Zeugs beim 
FAT auf 512 Bytes hart codiert ist und bei vielen Geräten (Handy, Kamera 
usw.) mit einer anderen Sektorgröße nicht zurechtkommt.

Dazu kommt noch, das das FAT nun von Microsoft Patentiert ist und wenn 
man ein Gerät verkaufen möchte, an Microsoft eine Lizenzgebühr bezahlen 
muss. Obwohl man vermutlich schon eine Lizenzgebühr bezahlt hat, da die 
Speicherkarten vom Hersteller aus schon mit FAT vorformatiert sind.

Bei den größeren Speicherkarten, welche eine Blockgröße von 512 Bytes 
anzeigen, ist intern eine größere Blockgröße vorhanden (4096, 8192, ...) 
da sonst die große Speichermenge nicht platz hätte auf dem kleinen 
Platz.

Wenn also ein Sektor mit 512 Bytes geschrieben wird, so liest der 
Speicherkartenkontroller den Block in einen Buffer aus (Beispielsweise 
4096 Bytes), danach wird der Block mit 512 Bytes in den Buffer geladen, 
der Flash-Block mit 4096 Bytes wird gelöscht! Und danach wird der Buffer 
mit 4096 Bytes in den Flash-Block geflasht!

Da die Anzahl der internen Buffer nicht sehr groß ist, ist beim nicht 
sequentiellen schreiben vieler Blöcke mit 512 Bytes, die Lebensdauer der 
Speicherkarten schnell erschöpft.
Zum Beispiel beim schreiben der FAT Tabelle oder der Direktoryeinträge.
Beispielsweise bei 4096 Bytes interner Blockgrößen kann es vorkommen, 
dass ein und der selbe Speicherblock 8-mal gelöscht und wieder 
geschrieben wird.