mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Suche Erklärung für SD-Card Schreib-Delays


Autor: Peterchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, mir ist aufgefallen, daß SD-Karten irgendwann mal eine Pause 
einlegen.

Ich schreibe, ohne Unterbrechung, 2048 Bytes durch ein FAT-Dateisystem 
(dieses hier: http://elm-chan.org/fsw/ff/00index_e.html) auf eine 
SD-Karte. Die Karte wird im SPI-Modus betrieben (SPI-Takt = 18 Mhz).

Im Normalfall dauert ein Schreibzugriff für 2048 Bytes 3 bis 4 ms. Hin 
und wieder dauert ein Schreibzugriff aber 150...200 ms. In dieser Zeit 
ist die Karte scheinbar etwas länger beschäftigt.

Ist dieses Verhalten normal (weil die Karte den physikalischen Speicher 
beschreiben muß) oder deutet es auf einen Fehler bei mir hin?

Danke im Voraus,
 Peterchen

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, das ist normal, insbesondere bei einer recht neuen Karte. Hin und 
wieder werden beim Schreiben defekte Speicherzellen entdeckt. Dann wird 
ein Reserve-Speicherblock gesucht und der defekte Block umgelagert. Dies 
kann mit einer grösseren Umorganisation des Kartenspeichers verbunden 
sein, die dann eben etwas länger dauert.

Gruss
Mike

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe übersehen, dass Du über ein FAT-System schreibst. Da kann es 
auch vorkommen, dass durch Löschen von Dateien Lücken in der 
kontinuierlichen Speicherbelgung vorhanden sind. Kommt das System beim 
Schreiben ans Ende einer solchen Lücke, muss ein neuer freier 
Speicherbereich in der FAT-Tabelle gesucht werden, was je nach 
Implementierung des Filesystems (freier Pufferspeicher) ebenfalls etwas 
dauern kann. Dieser Effekt kommt zum obengenannten noch hinzu. Hast Du 
mal versucht, eine grosse Datei auf eine vollständig leere (frisch 
formatierte) Karte zu schreiben? Dann sollte die FAT-Speichersuche kein 
Thema sein.

Gruss
Mike

Autor: Peterchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Ich habe bei einer frisch formatierten 2GB SD-Card (Agfa-Photo) direkt 
In der Low-Level Schreibfunktion gemessen. So siehts aus:

DiskWrite: (35) 169
DiskWrite: (218) 164
DiskWrite: (4) 159
DiskWrite: (4) 161
DiskWrite: (288) 166
DiskWrite: (10) 160
DiskWrite: (252) 165
DiskWrite: (10) 164
DiskWrite: (252) 165
DiskWrite: (10) 163
DiskWrite: (252) 162
DiskWrite: (10) 162
DiskWrite: (252) 163
DiskWrite: (10) 160
DiskWrite: (252) 165
DiskWrite: (10) 163
DiskWrite: (252) 163
DiskWrite: (10) 165
DiskWrite: (252) 161
DiskWrite: (10) 164
...
...
...

Die Zahl in Klammern ist die Anzahl vorheriger Schreibzugriffe, die 
unter 10ms lagen. Die Zahl danach ist die Zeit für diesen langen 
Schreibzugriff. Auffällig sind die anfänglichen Startschwierigkeiten und 
dann, daß sich dies Delays alle 10 und 252 Zugriffe wiederholen.

Autor: Frank Götze (embedded-os)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das liegt an nachfolgenden Punkten:
* NAND ist 8/16bit seriell (kein Addressbus) und wird "quasi" wie eine
  serielle Schnittstelle angesprochen
* es wird immer 1..4 Sektoren (a 512byte) gelesen und ECC-geprüft
* es kann immer nur eine Page (typ 2kB) geschrieben werden (mit ECC)
* es kann immer nur ein Block (typ 128kB) gelöscht werden

Nun multipliziere das mit "wear-leveling" und verwende als Basis mal
typische Zeiten eines Samsung NAND-Flash's.

siehe:
http://de.wikipedia.org/wiki/Flash-Speicher
http://en.wikipedia.org/wiki/Wear_levelling

oder du googlst mal nach diesen KeyWords .

Da nun das Wear-Leveling bemüht ist, die write-Last auf alle Sektoren 
mglst. gleichmäßig zu verteilen, werden bei jedem Schreiben andere phys. 
Sektoren verwendet. Wenn diese bisher andere (ungültige Daten) 
beinhalten, muß erst der Block gelöscht werden. Wenn die frei-Bereiche 
knapp werden oder große "used-cnt" Unterschiede auftreten werden auch 
verwendete Sektoren reorganisiert. Diese müssen aber jederzeit unter der 
entsprechenden logischen Sektoren-Nummer (vom user) ansprechbar sein.

Also, WearLeveling (Mathematik & patentierte Algo's) + phys. 
Eigenschaften + log. Verwaltung ergibt etwa alle "128kB - 2kB" ein 
table-work with erase/update cycle...

Autor: Peterchen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Viel Dank, Frank!
Du hast mir sehr geholfen. :-)

Autor: Claus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

beschäftige mich auch gerade mit diesem Phänomen,
eine kurze Frage, kann man die 200ms irgendwie
umgehen? Ändert vielleicht ein MMC Modus etwas?

Vielen Dank & Viele Grüße
Claus

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>beschäftige mich auch gerade mit diesem Phänomen,
>eine kurze Frage, kann man die 200ms irgendwie
>umgehen?

Mit viel RAM als Zwischenpuffer: JA.
Ohne: NEIN.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.