Forum: Mikrocontroller und Digitale Elektronik SD Karte - Timimgprobleme


von Martin (Gast)


Lesenswert?

Hallo,

in meinem aktuellen Projekt möchte ich Messwerte auf einer SD Karte 
speichern.
Habe hierzu bereits im Forum Hilfe / Rat gefunden und umgesetzt.

Habe mal ein paar Tests gemacht und dabei ist mir aufgefallen, dass ich 
sporadisch beim Schreiben auf die SD Wartezeiten von ca. 100ms habe.
Um dies zu testen, lasse ich in einer Timer-ISR einen Counter laufen. 
Aus der main heraus werden die Buffer geschrieben. Die Schreibrate 
beträgt etwa 100kB/sec. Zum Testen habe ich einen ARM7 und das SPI 
Interface läuft mit 20MHz. Wie bereits in anderen Threads gelesen, 
sollte diese Datenrate doch kein Problem sein. Deshalb verunsichern mich 
die Delays zwischen dem Schreiben von zwei 512Byte Blöcken. Ich schreibe 
diese linear, also ohne Filesystem.

Was sind eure Erfahrungen mit dem Timimg der SD Karten? Habt ihr solche 
"Aussetzer" auch schon feststellen können?

Danke
Martin

von holger (Gast)


Lesenswert?

>Was sind eure Erfahrungen mit dem Timimg der SD Karten? Habt ihr solche
>"Aussetzer" auch schon feststellen können?

Ja, konnte ich

Beitrag "Re: Parallelisierung auf µController"

Bis 310ms habe ich für die Busy Zeiten beim
schreiben eines Sektors schon gemessen.

von Martin (Gast)


Lesenswert?

Hallo Holger,

und ohne Fat Library?

Gruss

von holger (Gast)


Lesenswert?

>und ohne Fat Library?

Naja, schon mit FAT Library.
Die Busy Zeit hab ich in der Sektorschreibroutine gemessen.
Und das auch erst nachdem die Daten übertragen wurden.
Also die Zeit bis die Karte ok meldet das sie wieder Daten
annehmen möchte.

Die 310ms habe ich beim schreiben eines einzelnen Sektors gemessen.
Also nicht die Zeit zwischen zwei fwrite() z.B.

von Martin (Gast)


Lesenswert?

aus Optimierungsgründen habe ich die Fat Library beim Schreiben ja schon 
rausgeschmissen. Trotzdem messe ich immer noch Delayzeiten von bis zu 
100ms.
Das ist frustrierend.

Gruss

von holger (Gast)


Lesenswert?

>Das ist frustrierend.

Das ist es wirklich.

Ich hab jetzt mal 40000 Sektoren RAW auf die Karte geschrieben.
Völlig ohne FAT. Immer noch 290ms maximale Busy Zeit.

Mit oder ohne FAT macht kaum einen Unterschied.

von Andreas W. (andreasw) Benutzerseite


Lesenswert?

Auf http://www.embedded-os.de unter
RTOS -> pC/OS -> pC/FAT -> MMC/SD-ports
gibt es eine kleine Übersicht zu den Latenzen.
Die SDHC-Karten scheinen ziemlich schnell zu sein...

von holger (Gast)


Lesenswert?

>Die SDHC-Karten scheinen ziemlich schnell zu sein...

Nicht wirklich ;)

MMC256MB extrememmory
8192  25.50s 784.3kB/s
40ms max Busy

SDHC4GB Toshiba
8192  29.90s 668.8kB/s
110ms max Busy

von embedded-os (Gast)


Lesenswert?

wie im source-code unter:

http://www.embedded-os.de/index.html?pcfat_port.htm

steht, sind einige der "normalen" MMC/SD-Karten mit time-outs versehen 
(Nac / Nbs) die sehr grenzwertig sind. Auch SDHC-Karten sind, wenn nicht 
die 100ms / 250ms timeouts verwendet werden, sondern wiederum Nac/Nbs 
basierend auf der SPI-clock, recht grenzwertig.
Desweiteren kann bei großen Transfers via "Read_MultipeSectors" und 
"Write_MultipleSectors" eine starke Transfer-Schwankung basierend auf 
dem verwendeten (in Hardware) Wear-Leveling beobachtet werden.
Deswegen verwendet der o.g. code einen "Sicherheitsmuliplikator" - 
siehe:

// some SD-cards have (in comparison with other cards) extrem low 
timings declared
// but are not running stable with it -> so we can fix this by adding 
extra timing
MMC_Nac *= 5;          // expand timeouts to a "normal" range
MMC_Nbs *= 5;

zur Performance:
bei Verwendung des DMA und "r/w_MultipeSector" können bei guten Karten 
bis zu 1050kB/s read und 880kB/s write erreicht werden - aber eben nicht 
bei allen Karten....

von Toni (Gast)


Lesenswert?

woran liegen eingentlich diese langen Wartezeiten?
Ist das: 
http://de.wikipedia.org/wiki/SD_Memory_Card#Anzahl_maximaler_Schreibvorg.C3.A4nge
der Grund?

von embedded-os (Gast)


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 .

von holger (Gast)


Lesenswert?

@ emmbedded-os

Schöne Erklärung des Problems !

P.S.: Du hast da einen Fehler im ATMega128 Code ;)

>U08 FFSPort_MMC_Send(U08 w)
>    while(!(SPSR & (1 << SPIE)));

   while(!(SPSR & (1 << SPIF)));

von embedded-os (Gast)


Lesenswert?

Danke,

solche Fehler mag ich ja :(
Aber bei der Definition vom ICC compiler
#define    SPIF         7       // bit7 of SPSR
#define    SPIE         7       // bit7 of SPCR

geht das sogar funktional durch... ;)
Korrektur ausgeführt !

von Martin (Gast)


Lesenswert?

Hallo,

habe es jetzt geschaft, ca 150kB/s kontinuierlich(ohne Ausetzer) auf die 
SD Karte zu schieben.


Jetzt habe ich aber ein neues Problem. Anscheinend wurde durch die hohe 
Beanspruchung(ISR, ...) das Schreiben eines Blocks auf die Karte via SPI 
unterbrochen. Dies hat zur Folge, dass die Karte weder über MCU noch am 
PC erkannt wird. Ich vermute, dass die Karte in einem undefinierten 
Zustand ist und die Verwaltung auf der Karte nicht mehr ordentlich 
funktioniert. Diesen Zustand habe ich inzwischen bei drei 
SD-Karten(MicroSD). Meine Frage ist jetzt, besteht die Möglichkeit, die 
SD-Karte hart zu reseten (z.B. durch einen Spannungsimpuls von aussen)? 
Es kann doch nicht sein, dass die Karte durch einen Ablauffehler 
zerstört werden kann, oder?

Gruss

von holger (Gast)


Lesenswert?

>Dies hat zur Folge, dass die Karte weder über MCU noch am
>PC erkannt wird.

So ein ähnliches Problem hatte ich auch gerade.
Kommt die MCU noch durch die MMC/SD Init ?
Bei einer Karte war bei mir beim schreiben was schief gelaufen.
Karte in den Kartenleser gesteckt und XP meldet "kein Medium".
Formatieren wird gar nicht erst angeboten und geht deshalb nicht.

Bei mir kam die Karte aber mit uC noch durch die MMC/SD Init !
Ich hab dann mit dem uC einfach die ersten 100 Sektoren mit Nullen 
vollgeschrieben. Karte in den Kartenleser und AHA !
Formatieren geht wieder, Karte geht wieder.

von embedded-os (Gast)


Lesenswert?

Die SPI-Init und CSD, CID lesen sollte auf alle Fälle noch 
funktionieren.
Und nur wenn du zwischen den Bytes (durch die ISR) die CS-leitung auf 
high setzt (auto-mode) kann dich eine ISR wirklich stören. An sonsten 
sendet dein code
* CS-low
* 0..n Bytes
* -> dann macht die ISR was (natürlich nicht am SPI-port)
* und dann können normaler Weise noch n..512 Bytes per SPI rausgehen.
* CS-high

Solltest du einen Abbruch erhalten haben, kann es sein, daß du das ganze 
"Ding" neu "low-level" formatieren mußt - dann wenn Sektor-0 oder die 
FAT im Eimer sind. Das geht mit deiner MCU - einfach alles nullen. 
Jedoch richtet Windows anschließend einen MBR ein, mit vier möglichen 
Partitionen, wovon die Erste aber leider kleiner wurde als vor dem 
Crash.

von Martin (Gast)


Lesenswert?

Hallo Holger,

das muss ich morgen unbedingt mal probieren. Habe mir heute gerade erst 
wieder zwei neue Karten geholt und eine geht schon wieder nicht mehr. 
Man traut sich kaum noch, die letzte reinzupacken.

Über weitere Hinweise wäre ich sehr dankbar

Gruss

Bitte 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
Noch kein Account? Hier anmelden.