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
>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.
>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.
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
>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.
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...
>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
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....
woran liegen eingentlich diese langen Wartezeiten? Ist das: http://de.wikipedia.org/wiki/SD_Memory_Card#Anzahl_maximaler_Schreibvorg.C3.A4nge der Grund?
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 .
@ 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)));
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 !
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
>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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.