SD Karte - Anzahl Input Buffers

[Marc (Gast)]

Guten Abend

Ich befasse mich gerade mit einem einfachen SDIO Treiber aus einem der 
STM32 Examples (ich verwende ein ECBSTM32E Eval Board mit einem 
STM32F103ZE). Ich verwende aufgrund der höheren Datenraten das Send 
Multiple Block Kommando. Das Prinzip ist relativ simpel: Karte wird 
initialisiert (Block Length, ...) und dann werden die Daten via DMA auf 
die Karte übertragen, das Transfer Complete Flag gepollt und das 
Transmission Completed Kommando übertragen. Das funktioniert soweit auch 
ganz in Ordnung.

Nach ersten Tests bei denen ich etwas hin und her geschrieben habe, 
stellen sich mir zwei Fragen:

1. Schreibe ich bspw. 5 Blöcke an 512Bytes an die Karte, stelle ich nach 
dem ersten Block eine erheblich grössere Verzögerung fest (siehe 
Anhang).
Weiss jemand woher diese Verzögerung kommt? Evtl. durch den Sleep Mode?

2. Am Ende der Grafik sieht man zudem den Busy-State bei der die Karte 
am schreiben ist. Wieviele Blöcke kann ich nun schreiben bis die 
internen Buffer gefüllt sind? Die meisten Karten Datasheets sind ja eher 
für Marketingzwecke... Wo kann ich sowas rausfinden?

Vielen Dank!

[Svenska (Gast)]

Ich befürchte, dass du genau nichts vernünftiges allgemeingültiges 
rausfinden kannst. Was die Flashcontroller in den SD-Karten tun, ist 
nicht wirklich bekannt und von Karte zu Karte unterschiedlich. Außerdem 
darf das Wear-Levelling jederzeit zuschlagen und dir deine 
Performance-Analysen versauen...

[Jim M. (turboj)]

Die Blockgröße steht IIRC im SD_STATUS Register drin. Vorsicht: Eine 
Sorte Samsung OEM Karten stürzte beim Lesen dieses Registers ab und 
brauchte danach einen Power-cycle.

Faustegel: Kleine Karten (SD): 1 MByte Blöcke,
größere (SDHC): 4 MByte Blöcke.

Genauere Vorhersagen sind aber schwierig, da die internen Controller 
Wear-Leveling machen - und daher die Blöcke auch umsortieren könnten.

[Marc (Gast)]

Vielen Dank für eure Antworten.

Ich werde das Register sicher mal auslesen und dann gleich schauen, ob 
es mit der Faustregel übereinstimmt.

Wie wirkt sich das Wear-Leveling auf den Schreibzyklus aus? Längere 
Busy-zeiten?

Gruss

[Svenska (Gast)]

> Wie wirkt sich das Wear-Leveling auf den Schreibzyklus aus? Längere
> Busy-zeiten?

Wie sonst? Im Übrigen darf auch ein Lesezugriff das Wear-Levelling 
triggern. Aber du scheinst kein Interesse an einer Nichtantwort zu 
haben. :-)

Deine Faustregel passt aus meiner Sicht trotzdem nicht, weil 5x512 Byte 
deutlich weniger als 1 MB sind.

[Jim M. (turboj)]

Svenska schrieb:
> Deine Faustregel passt aus meiner Sicht trotzdem nicht, weil 5x512 Byte
> deutlich weniger als 1 MB sind.

Es kann druchaus eine Blockgrenze drin sein, wir wissen ja nicht welche 
5 Blöcke es absolut sind.

Als Kompott reagieren die Karten auf 5x "Single write" oft 
unterschiedlich zu 1x "multiple write" a 5 Sektoren.

In der für lau erhältlichen Spec auf sdcard.org sind auch noch 16 KB 
Unterblöcke erwähnt, Details aber leider kaum. Eventuell lohnt es sich 
auf diese Grenzen zu achten.

[Marc (Gast)]

Oha, ich freue mich selbstverständlich über jede Antwort. ;-)

Am einfachsten versuche ich einmal die Anzahl Blöcke kontinuierlich zu 
erhöhen und achte mich auf ein Auftreten eines erneuten Busy-States. 
Dieses könnte ja dann aufgrund des Wear-Levelings oder nach dem Füllen 
des letzten Inputbuffers auftreten.

Wenn dies auch keine Erkenntnisse liefert, muss ich mich wohl damit 
zufrieden geben, dass ich keine 100%-ige Voraussage machen kann. Ihr 
bestätigt ja beide, dass es etwas schwammig definiert ist.

Gruss

[Marc (Gast)]

Als kleines Update:

SD_Status gibt vorallem Auskunft über den aktuellen Zustand der SD 
Karte. Z.B. wird dort ein Flag gesetzt, wenn ein interner Fehler 
auftritt oder man einen "unerlaubten" Sektor beschreiben will.
=> keine Infos zur Block Size

CSD_Register enthält schon interessantere Daten. Man erkennt in 
WRITE_BL_LEN die aktuelle Blockgrösse (per Default 512Byte) und in 
SECTOR_SIZE wie viele Blöcke auf einmal gelöscht werden können.
Über die Anzahl internen Blockbuffer kann ich jedoch nichts finden.

Vielleicht hat das Delay nach dem internen Block auch etwas mit dem 
Erase before write zu tun. Mal sehen...