Weis jemand, wie groß die Sektoren in SD-Karten sind? Bei Karten kleiner 1GB sind die Sektoren wohl 512 Bytes groß. Wie aber ist das bei anderen Karten? Ich suche schon ein ganze Weile eine Tabelle mit den Sektorgrößen, kann aber einfach nichts finden.
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?
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.
Knut Ballhause schrieb: > Soweit ich weiß, haben auch größere Karten bis Sektorgrößen von > 512Bytes. Die Karten haben u.U. größere Cluster, aber die Sektoren > können dennoch einzeln angesprochen werden. Das widerspricht den Angaben auf http://en.wikipedia.org/wiki/Secure_Digital#Storage_capacity da ist klar von anderen Sektorgrößen (nicht zu verwechseln mit Clustergrößen!) die Rede.
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.
Meine 4GB-microSDHC Karte hat Sektorgrößen von 512Byte. (Intenso)
Mir ist bisher noch keine Karte untergekommen, die nicht mit 512bytes
Sektorgröße ("Block") genutzt werden konnte, allzu exotische Karten habe
ich allerings auch nicht.
Die EFSL wird schon lange nicht mehr gepflegt. Kann gut sein, dass es
Probleme mit Karten(-größen) gibt, die es zu deren Entwicklungszeit noch
nicht gab. Wenn richtig erinnert, hatte ich eine modifizierte Fassung
der EFSL
(http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#efsl_arm)
mit 2GB Karten getestet, ist aber schon sehr lange her.
Setze selbst inzwischen nur noch die Library FatFS von ChaN ein (siehe
Artikel MMC- und SD-Karten in der Artikelsammlung). Die hat zwar
keinen IO-Mananger ("Cache") wie die EFSL, wird aber von ChaN gut
gepflegt. Ist einen Blick wert. EFSL-"API" habe ich für alten Code mit
eine paar Hilfsfunktionen "über" das FatFS-"API" gelegt (ist aber nicht
alles 1:1 umsetzbar). ChaN hat in seinem Code auch eine Option zur
Einstellung der Sektorgrößen vorgesehen.
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.
Angehängte Dateien:
-
csd.PNG
2,4 KB
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. Macht z.B. die hier unter Artikel findbare AVR_FAT32 Lib auch so. Gruß Fabian
>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?
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.
@holger: das mit CMD16 unnötig wundert mich etwas. Ich habe andere Erfahrungen gemacht. Z.B. hatte ich eine 2GB Karte von extrememory, die immer nur Müll ausgegeben hat bis ich ihr mit CMD16 512Byte Blockgröße vorgab. Auch hab ich noch keine Karte gehabt, die auf CMD16 mit 05 (illegal CMD) geantwortet hätte. Gruß Fabian
Ä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.
holger schrieb: >>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. Das ist nicht korrekt, es gibt reale FAT-Implementationen auf anderen Sektorgrößen auch bei aus heutiger Sicht lächerlich kleinen Speichermedien. Ein (fast schon willkürliches) Beispiel sind 3.5"-MO-Medien mit 640 MB Kapazität, die nutzen 2 kiB-Sektoren. SD-Karten (nicht SDHC!) mit mehr als 1 GB Speicherkapazität können durchaus auch "Sektoren" mit mehr als 512 Byte haben.
>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?
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. Ich habe etwa 10 verschiedene Marken in diversen Größen bis 2GiB getestet. Vielleicht habe ich einfach nur Glück gehabt ;-)
>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?
chris schrieb: > Mir geht es nicht um die Sektorgröße, sondern um die Blocklänge, mit der > die Karte arbeitet. 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. chris schrieb: > 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? Wenn die Karte tatsächlich 1024 Byte an Daten erwartet, wird sie das Kommando nicht ausführen, wenn sie nicht die volle Blocklänge an Daten erhalten hat. Ein Schreiben von beispielsweise nur 511 Datenbytes bei einer 512Byte Blocklänge führt zu einem Ignorieren des gesamten Befehls.
>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.
Schon klar. Und die Karte lässt sich nicht überreden per CMD16?!
>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.
Beitrag #7097393 wurde von einem Moderator gelöscht.
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.