Hallo zusammen, Ich nutze die Elm Chan FatFs-Bibliothek mit einem xMega256A3U, um Daten auf einer Mikro-SDHC-Karte Klasse 10 zu speichern. Ich lese und schreibe 512-Byte-Blöcke mittels DMA, und es funktioniert wunderbar. Einstellungen sind: FAT32, kein LFN, kein "Tiny". Nun habe ich bemerkt, dass in 50% der Zeit der Schreibevorgang mit f_write() sehr schnell geht, d.h. ca. 1 ms ingesamt, gemessen an der CLK-Line mit einem Oszi. In den anderen 50% der Zeit dauert der Schreibvorang deutlich länger und es werden mind. 3 Mal 512-Byte-Blöcke übertragen. Problem: Ich konnte bisher noch nicht tracen (debugger), worin der Unterschied besteht, d.h. welche Anfrage die SD-Karte zusätzlich schickt oder verlangt, dass das manchmal länger dauert. Anbei ist mal ein Screenshot vom "langen" Schreibvorgang. Die dichten Balken am Anfang, Mitte und Ende sind 512er Blöcke, die mit DMA übertragen werden. Bis zum Ende des ersten Balkens ist in einer Detailaufnahme der Vorgang identisch mit dem "schnellen" Schreibvorgang. IAlles danach ist vielleicht zusätzliches FAT32-Management, Syncing oder so etwas - genau das ist die Frage. Es ist noch wichtig zu wissen, dass sich diese langen/kurzen Schreibvorgänge nicht direkt abwechseln, sondern entweder wird über eine lange Zeit sehr schnell beschrieben oder wie im Screenshot relativ langsam. Der Vorgang verändert sich jedesmal, wenn die Karte am PC war und Dateien gelöscht wurden oder die Karte formatiert wurde. Ich habe alles mögliche probiert, auch die Blockgröße beim formatieren verändert, konnte es aber letztlich nicht sicher reproduzieren und damit nicht eingrenzen. Ich hoffe auf das Wissen von jemandem, der sich mit der FatFs-Bib oder der ganzen SD-Kartengeschichte an sich gut auskennt.
Angehängte Dateien:
-
scope_1.png
19 KB
In der SD Karte ist ein Controller drinn, der Lässt sich halt manchmal ein bischen Zeit für was anderes. Irgendwelchen Speicher umsortieren oder so. Das kann schon mal 100ms oder so dauern.
Das weiß ich und verstehe ich auch. Komisch ist nur, dass über mehrere zig Sekunden bis zu Minuten der Schreibvorgang robust und sehr schnell geht, und nach einigen Versuchen genau umgekehrt (wie im Screenshot). Das hat vielleicht etwas mit dem Ort zu tun, an den der SD-Controller schreiben will? Es ist ja kein echtes Timeout oder Delay, sondern entweder: Schreibvorgang -> Ende oder Schreivorgang -> 8ms anderes Zeug, bei dem noch 2x512 Byte hin- oder hergeschickt werden -> Ende Was passiert da?
Emanuel L. schrieb: > Schreivorgang -> 8ms anderes Zeug, bei dem noch 2x512 Byte hin- oder > hergeschickt werden -> Ende Ganz genau: Emanuel schrieb: > IAlles danach ist vielleicht zusätzliches FAT32-Management, Syncing oder > so etwas - genau das ist die Frage. Wenn ein Cluster voll ist, muss ein freier Cluster gefunden und dieser in der FAT für die Datei eingetragen werden. Das kann je nach Implementierung in FatFs einige Datentransfers bedeuten. Praktischerweise ist FatFs open-source, sodass du es einfach nachschauen kannst! Prinzipiell ist es möglich 128 Cluster (=4 MiB bei der empfohlenen Cluster-Größe von 32KiB) auf einen Rutsch zu allokieren und somit weniger Overhead zu erzielen. Ob FatFs das kann weiß ich nicht. Emanuel schrieb: > Der Vorgang verändert sich jedesmal, wenn die Karte am PC war und > Dateien gelöscht wurden oder die Karte formatiert wurde. Hoffentlich nicht mit dem Windows/Linux-Formatier-Tool, sondern mit dem Tool von http://sdcard.org ? Emanuel schrieb: > auch die Blockgröße beim formatieren verändert, > konnte es aber letztlich nicht sicher reproduzieren und damit nicht > eingrenzen. Schlechte Idee... Die Block("Sektor")größe ist fix 512B, und die Cluster-Größe sollte man auf 64 Sektoren = 32 KiB lassen, um optimale Performance zu erzielen.
Vermutlich ist das Wear-Leveling der Karte schuld. Da das FAT-Filesystems eine Blöcke sehr viel häufiger (nämlich, die wo sich die FAT befindet) schreibt als andere, würden diese Blöcke vorzeitig verschleissen. Der Kartencontroller wird also iregndwann die Daten in einen anderen, noch wenig benutzten Speicherbereich umkopieren. Das zieht neben dem eigentlichen Kopiervorgang noch einigen Verwaltungsaufwand nach sich, so dass sich die Karte eine kleine Ruhepause genehmigt. Das Problem ist, dass sich die Wear-leveling-Vorgänge von aussen kaum beeinflussen lassen. Wenn es auf kurze LAtenzzeiten ankommt, ist es besser, ein alternatives, speziell für Flash optimiertes Filesystem zu verwenden.
@Mike (Gast) >Das Problem ist, dass sich die Wear-leveling-Vorgänge von aussen kaum >beeinflussen lassen. Jo. > Wenn es auf kurze LAtenzzeiten ankommt, ist es >besser, ein alternatives, speziell für Flash optimiertes Filesystem zu >verwenden. Oder einen ausreichend großen FIFO verwenden.
Mike schrieb: > Das Problem ist, dass sich die Wear-leveling-Vorgänge von aussen kaum > beeinflussen lassen. Wenn es auf kurze LAtenzzeiten ankommt, ist es > besser, ein alternatives, speziell für Flash optimiertes Filesystem zu > verwenden. Krasser Unsinn. Das würde nur dann etwas nutzen, wenn du direkt auf Flashspeicher zugreifst. Das ist aber bei einer SD-Karte niemals der Fall, weil du immer nur mit deren Flashcontroller redest und niemals mit dem Flash selber. Du musst also hier sogar genau das Filesystem mit genau der Geometrie verwenden, welches der Flashcontroller erwartet (und auch mit gutem Recht erwarten darf, denn schließlich gibt es ja einen SD-Standard). Die Verwendung jedes anderen Filesystems oder auch nur einer abweichenden Geometrie ist von vorherein vorhersehbar kontraproduktiv, weil die wear-leveling-Algorithmen des Controllers natürlich für das erwartete Filesystem mit der erwarteten Geometrie optimiert sind. In aller Regel führt alles andere übrigens zu einem sehr vorzeitigen Tod des Mediums... Das gleiche gilt auch weitestgehend für USB-Sticks. Auch deren Wear-leveling ist optimiert. Und zwar i.d.R. für exakt die Struktur, mit der sie ausgeliefert werden. Blöd bloß, daß die Hersteller sich hier nicht auf einen schützenden Standard zurückziehen können, der eine bestimmte Struktur vorschreibt. Das ändert aber nur leider nix an der normativen Kraft des Faktischen... Fazit: Bei allen Medien, bei denen man nicht direkt den Flash beschreibt, sollte man tunlichst die vorgegebene Struktur verwenden und nix anderes! Es sei denn, man verwendet sie im Wesentlichen als WORM-Medien, dann darf man von dieser Regel auch mal abweichen.
Okay, vielen Dank für Eure Antworten! Ich hatte so etwas schon vermutet, aber hatte gehofft, dass es vielleicht doch eine Möglichkeit gibt, das ganze von außen zu beeinflussen. Zwei Fragen bleiben mir aber noch: 1. Wenn es das Wear-Levelling ist, wieso macht der Controller auf der Karte nicht alles automatisch, sondern mein xMega muss noch zweimal 512 Bytes hin- und herschaufeln? Einige 100 Millisekunden timeout der Karte, in der sie nix annimmt und rechnen muss, wären für mich in Ordnung. 2. Kennt jemand einen verfügbaren Flashspeicher, der per SPI ansprechbar ist, mit 1 GByte Kapazität? Nor/Nand spielt keine Rolle. Ich habe gesehen, dass es SPI Nor-Flashs mit bis zu 2-4 GByte gibt, aber eben nicht gerade verfügbar bei Farnell und Co. Stückzahl des Projekts ist < 10, also muss das von der Stange kommen und am Besten auch in 6 Monaten noch verfügbar sein (kein zufälliger Restbestand). Grüße
@Emanuel Leicht (Firma: atec innovation GmbH) (eleicht) >1. Wenn es das Wear-Levelling ist, wieso macht der Controller auf der >Karte nicht alles automatisch, sondern mein xMega muss noch zweimal 512 >Bytes hin- und herschaufeln? Das sind notwendige Zugriffe auf die FAT. > Einige 100 Millisekunden timeout der Karte, >in der sie nix annimmt und rechnen muss, wären für mich in Ordnung. Wo ist dann dein Problem? >2. Kennt jemand einen verfügbaren Flashspeicher, der per SPI ansprechbar >ist, mit 1 GByte Kapazität? Micro-SD Karte ;-) >Stückzahl des Projekts ist < 10, also muss das von der Stange kommen und >am Besten auch in 6 Monaten noch verfügbar sein (kein zufälliger >Restbestand). Siehe oben. Alles andere ist Perlen vor die Säue. So einfach und billig kriegst du das selber nie hin.
>>1. Wenn es das Wear-Levelling ist, wieso macht der Controller auf der >>Karte nicht alles automatisch, sondern mein xMega muss noch zweimal 512 >>Bytes hin- und herschaufeln? > > Das sind notwendige Zugriffe auf die FAT. Okay, danke. >> Einige 100 Millisekunden timeout der Karte, >>in der sie nix annimmt und rechnen muss, wären für mich in Ordnung. > > Wo ist dann dein Problem? Mein Problem ist, dass ich jede Millisekunde (sharp!) Sensoren per UART abfrage. Es sind ca. 20 Sensoren in Reihe, nach dem letzten fange ich beim ersten an. Die Zeitabstände müssen immer konstant bleiben, d.h. ich kann nach den 20 Sensoren ein Delay einfügen zum Datenschreiben (z.B. nochmal 1..x Millisekunden). Was ich nicht kann, ist unregelmäßig einmal nach einer 20er Runde Daten schreiben, dann beim nächsten Mal erst nach 5x20 Sensoren, weil dann die Zeitabstände nicht stimmen. Der Schreibvorgang muss auch immer gleich bleiben, d.h. nicht einmal 2 ms, dann 10 ms. Ich könnte natürlich grundsätzlich ein Schreibdelay von z.B. 15 ms einfügen, die die SD-Karte + FatFs maximal zum Schreiben braucht (nach Oszi-Messreihen). Aber dann hätte ich in häufigen Fällen ein unnötiges Delay, was meine Zeitauflösung zerschießt. > >>2. Kennt jemand einen verfügbaren Flashspeicher, der per SPI ansprechbar >>ist, mit 1 GByte Kapazität? > > Micro-SD Karte ;-) Damn it. >>Stückzahl des Projekts ist < 10, also muss das von der Stange kommen und >>am Besten auch in 6 Monaten noch verfügbar sein (kein zufälliger >>Restbestand). > > Siehe oben. Alles andere ist Perlen vor die Säue. So einfach und billig > kriegst du das selber nie hin. Einfach muss nicht, FatFs hab ich auch neu umgesetzt, da kann ich auch den Code für nen Flash-Speicher inkl. Auslese-Funktion programmieren. Muss nichtmal all zu billig sein, nur verfügbar.
@ Emanuel Leicht (Firma: atec innovation GmbH) (eleicht) >> Wo ist dann dein Problem? >Mein Problem ist, dass ich jede Millisekunde (sharp!) Sensoren per UART >abfrage. Es sind ca. 20 Sensoren in Reihe, nach dem letzten fange ich >beim ersten an. Die Zeitabstände müssen immer konstant bleiben, d.h. ich >kann nach den 20 Sensoren ein Delay einfügen zum Datenschreiben (z.B. >nochmal 1..x Millisekunden). Was ich nicht kann, ist unregelmäßig einmal >nach einer 20er Runde Daten schreiben, dann beim nächsten Mal erst nach >5x20 Sensoren, weil dann die Zeitabstände nicht stimmen. Logisch. >Der Schreibvorgang muss auch immer gleich bleiben, d.h. nicht einmal 2 ms, >dann 10 ms. Ich könnte natürlich grundsätzlich ein Schreibdelay von z.B. >15 ms einfügen, die die SD-Karte + FatFs maximal zum Schreiben braucht >(nach Oszi-Messreihen). Aber dann hätte ich in häufigen Fällen ein >unnötiges Delay, was meine Zeitauflösung zerschießt. Das ist Murks. Die Lösung lautet FIFO. Been there, done that. Deine Sensoren liest du ganz entspannt und gleichmäßig in einem Timer-Interrupt aus und schreibst die Daten in den FIFO. Im Hauptprogramm läuft eine kleine Statemachine, welche periodisch nachschaut, ob genügend Daten im FIFO liegen. Wenn ja, werden die auf SD-Karte geschrieben. Der "Trick" dabei ist, daß dieser Schreibvorgang beliebig durch den Timer-Interrupt unterbrochen werden kann, das interessiert die SD-Karte nicht, den SPI ist eine synchrone Schnittstelle, außerdem läuft die Übertragung der einzelnen Bytes per Hardware, es würde aber auch Soft-SPI funktionieren. Auf diese Weise kann man problemlos und zeitlich exakt Sensordaten einlesen und asynchron auf SD-Karte schreiben. Das hab ich vor langer Zeit mit einem DMX512 Rekorder gemacht, dort waren es bis zu 22kB/s beim Lesen und Schreiben und "nebenbei" wurde noch der DMX512 Datenstrom erzeugt (UART mit 250kBaud) >Einfach muss nicht, FatFs hab ich auch neu umgesetzt, Angepasst. > da kann ich auch >den Code für nen Flash-Speicher inkl. Auslese-Funktion programmieren. Dann hast du aber kein Wear Leveling und musst dich auch um die Datensicherung kümmern. Nicht sinnvoll. >Muss nichtmal all zu billig sein, nur verfügbar. Der Bauteilpreis ist verschwindend gering im Vergleich zum Arbeitsaufwand. Gerade dann MUSS man sinnvollerweise auf Fertiglösungen zurückgreifen. Micro-SD Karen sind dafür ideal!
Falk B. schrieb: >> da kann ich auch >>den Code für nen Flash-Speicher inkl. Auslese-Funktion programmieren. > > Dann hast du aber kein Wear Leveling und musst dich auch um die > Datensicherung kümmern. Ein Wear-Leveling braucht er ja dann auch nicht, und er kann sich zusätzlich den ganze FAT-Krempel sparen und hat damit keine spontanen unvorhersehbaren zusätzlichen Wartezeiten für den Schreibvorgang mehr.
> Das ist Murks. Die Lösung lautet FIFO. Been there, done that. Deine > Sensoren liest du ganz entspannt und gleichmäßig in einem > Timer-Interrupt aus und schreibst die Daten in den FIFO. Im > Hauptprogramm läuft eine kleine Statemachine, welche periodisch > nachschaut, ob genügend Daten im FIFO liegen. Wenn ja, werden die auf > SD-Karte geschrieben. Der "Trick" dabei ist, daß dieser Schreibvorgang > beliebig durch den Timer-Interrupt unterbrochen werden kann, das > interessiert die SD-Karte nicht, den SPI ist eine synchrone > Schnittstelle, außerdem läuft die Übertragung der einzelnen Bytes per > Hardware, es würde aber auch Soft-SPI funktionieren. > > Auf diese Weise kann man problemlos und zeitlich exakt Sensordaten > einlesen und asynchron auf SD-Karte schreiben. Das hab ich vor langer > Zeit mit einem DMX512 Rekorder gemacht, dort waren es bis zu 22kB/s beim > Lesen und Schreiben und "nebenbei" wurde noch der DMX512 Datenstrom > erzeugt (UART mit 250kBaud) Hrm das stimmt allerdings. Bisher hatte ich die Idee mit der Statemachine und Schreibvorgang unterbrechen verworfen, weil in der main-loop schon einige andere Statemachines realisiert sind, die die verschiedenen Sensortypen bzw. den vollständigen Datenempfang abfragen. Im Grund müsste ich "nur" die neue Datenabfrage direkt in den 1ms-Timer (existiert ja eh schon) integrieren, statt das in der Hauptschleife zu starten. Der Fifo ist ja auch schon realisiert... Vielleicht muss ich nur ein bisschen was umschreiben und das könnte funktionieren. Ich hatte das schon abgeschrieben. Danke! Ich halte Euch auf dem Laufenden, werde das nachher direkt ausprobieren. >>Einfach muss nicht, FatFs hab ich auch neu umgesetzt, > > Angepasst. Das Wort hat mir gefehlt ;-). >> da kann ich auch >>den Code für nen Flash-Speicher inkl. Auslese-Funktion programmieren. > > Dann hast du aber kein Wear Leveling und musst dich auch um die > Datensicherung kümmern. Nicht sinnvoll. Auch wieder wahr
@ Rolf Magnus (rmagnus) >> Dann hast du aber kein Wear Leveling und musst dich auch um die >> Datensicherung kümmern. >Ein Wear-Leveling braucht er ja dann auch nicht, und er kann sich >zusätzlich den ganze FAT-Krempel sparen und hat damit keine spontanen >unvorhersehbaren zusätzlichen Wartezeiten für den Schreibvorgang mehr. Mag sein, aber er will ja am Ende die Daten aus seinem Gerät (Datalogger?) auch wieder raus kriegen. Einfach die SD-Karte ziehen und in den PC stecken. Mach das mal mit deinem Flash-IC ;-)
Um maximale Schreibgeschwindigkeit zu erreichen:
* SD Bus ("SDIO") statt SPI verwenden, denn nur dann gilt die Speed
class
* Immer 4 MByte auf einmal schreiben (das ist die maximale Allocation
Unit)
* Immer nur 4 MB am Stück freie Cluster schreiben, an Adressen die
Vielfache von 4 MB sind
* Durch schlaues Schreiben der FAT immer jeden FAT Block nur genau 1x
Beschreiben und damit 128 Cluster auf einmal Allokieren
* Immer den ganzen 4 MB Block auf einmal löschen
Wenn man nicht genug FIFO Puffer hat, kann man Punkt 2 auch lassen und
kleinere Stücke schreiben (aber natürlich so viel wie möglich, und nur
2er Potenzen- 16 KByte sind erfahrungsgemäß gut).
Auf diese Art schafft man die 10MByte/sec (bei Speed Class 10) und je
nach Karte auch mehr.
@Dr. Sommer (Gast) >Auf diese Art schafft man die 10MByte/sec (bei Speed Class 10) und je >nach Karte auch mehr. Schön, aber das alles geht bestenfalls auf einem Embedded-PC ala Raspberry Pi & Co, nicht auf einem kleinen Mikrocontroller.
Falk B. schrieb: > Schön, aber das alles geht bestenfalls auf einem Embedded-PC ala > Raspberry Pi & Co, nicht auf einem kleinen Mikrocontroller. Nö, bei schlauer Programmierung geht das auf allen Mikrocontrollern die SDIO und DMA haben, wie zB diverse STM32. Für die großen Mengen an RAM (für Max Speed) braucht man dann noch nen SDRAM Controller, den haben die großen STM32.
Dr. Sommer schrieb: > Falk B. schrieb: >> Schön, aber das alles geht bestenfalls auf einem Embedded-PC ala >> Raspberry Pi & Co, nicht auf einem kleinen Mikrocontroller. > > Nö, bei schlauer Programmierung geht das auf allen Mikrocontrollern die > SDIO und DMA haben, wie zB diverse STM32. Für die großen Mengen an RAM > (für Max Speed) braucht man dann noch nen SDRAM Controller, den haben > die großen STM32. Hat mein xMega aber nicht. Sonst würde ich sicher nicht mit USART im Master SPI Mode rumdödeln. Mein Problem war von Beginn an aber nicht die maximale Datenrate, denn die ist bei mir gering genug. Mein Problem waren die Zeiten der Schreibzugriffe, was ich - wie oben erwähnt - aber mit einer besserern Interrupt-Routine zu lösen versuche.
Dr. Sommer schrieb: > Auf diese Art schafft man die 10MByte/sec (bei Speed Class 10) und je > nach Karte auch mehr. Aber nicht mit einem AVR 8-Bit µC. Außerdem braucht der OP sicher nicht mehr als ein paar KByte/sec. Dr. Sommer schrieb: > * SD Bus ("SDIO") statt SPI verwenden, denn nur dann gilt die Speed > class Da sind die Specs aber nicht öffentlich. Für SPI kann man sich die ollen MMC Specs saugen die im Netz so rumfliegen (MMC ist direkter Vorgänger von SD). > * Immer 4 MByte auf einmal schreiben (das ist die maximale Allocation > Unit) Klingt schön, aber je nach Karte gibts dann trotzdem eine Wartezeit fürs Schreiben. Ich hatte hier schon Karten mit ca. 1 Sekunde Schreibzeit, die betrachte ich allerdings als "defekt ab Werk". BTW: Sandisk MicroSD Karten haben hier immer recht gut und schnell im SPI Mode funktioniert. So 300-500ms sollte die Anwendung aber schon puffern können, sonst gibts Overruns.
Emanuel L. schrieb: > Mein Problem waren die Zeiten der > Schreibzugriffe, was ich - wie oben erwähnt - aber mit einer besserern > Interrupt-Routine zu lösen versuche. Dann brauchst du einfach nur einen FIFO. Sollte eigentlich sowieso selbstverständlich sein. Jim M. schrieb: > Aber nicht mit einem AVR 8-Bit µC. Wer sowas verwendet ist eh selbst schuld :) Jim M. schrieb: > Da sind die Specs aber nicht öffentlich Und was ist das hier? https://www.sdcard.org/downloads/pls/index.html Oha, da sind die SD-Spezifikationen inklusive SD bus herunterladbar. Die genauen Timings für den SD bus erledigt eh die SDIO-Hardware im Controller, daher brauchts die nicht. Jim M. schrieb: > Ich hatte hier schon Karten mit ca. 1 Sekunde Schreibzeit, > die betrachte ich allerdings als "defekt ab Werk". Jim M. schrieb: > BTW: Sandisk MicroSD Karten haben hier immer recht gut und schnell im > SPI Mode funktioniert. Interessant. Gerade bei SanDisk karten hatte ich Wartezeiten bis 3sek. SanDisk Flash-Speicher gilt aber generell nicht als besonders gut... Jim M. schrieb: > So 300-500ms sollte die Anwendung aber schon puffern können, sonst gibts > Overruns. Logisch. Bei "guten" (zB Samsung Evo) Karten reichen ca 50ms.
Dr. Sommer schrieb: > Emanuel L. schrieb: >> Mein Problem waren die Zeiten der >> Schreibzugriffe, was ich - wie oben erwähnt - aber mit einer besserern >> Interrupt-Routine zu lösen versuche. > Dann brauchst du einfach nur einen FIFO. Sollte eigentlich sowieso > selbstverständlich sein. "Einfach nur einen Fifo" ist nicht der Punkt, um den es geht, was ich genau in meinem Text sage. > Jim M. schrieb: >> Aber nicht mit einem AVR 8-Bit µC. > Wer sowas verwendet ist eh selbst schuld :) Ich nehme an, Du bist Hobbybastler und kein professioneller Elektronikentwickler. Ich danke allen für die teils sehr hilfreichen Kommentare und Hilfestellungen! Ich würde jedoch bitten, diesen Thread auch etwas sauber zu halten und nicht jedes Kommentar über die verwendete Architektur und die entsprechenden Probleme zu re-kommentieren und auszudebattieren.
Emanuel L. schrieb: > Ich hatte so etwas schon vermutet, aber hatte gehofft, dass es > vielleicht doch eine Möglichkeit gibt, das ganze von außen zu > beeinflussen. Die gibt es tatsächlich: nimm eine andere SD-Karte. Denn wie gesagt: dort ist ein Controller drauf, auf dem eine herstellerabhängige Software läuft. Emanuel schrieb: > auf einer Mikro-SDHC-Karte Klasse 10 Welche? Dr. Sommer schrieb: > Bei "guten" (zB Samsung Evo) Karten reichen ca 50ms. Die Software auf diesen Karten kann ich auch bezüglich der Lebensdauer, Zuverlässigkeit und Datensicherheit besten Gewissens empfehlen. Absoluter Schrott sind nach meiner Erfahrung restlos alle billigen TLC-Karten vom Discounter und "Elektrofachhandel"...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Emanuel schrieb: >> auf einer Mikro-SDHC-Karte Klasse 10 > Welche? Eine Intenso 8 GB und eine Transcend 4 GB. Identisches Schreibverhalten nach dem, was ich mit dem Oszi messen konnte.
Emanuel L. schrieb: > Eine Intenso 8 GB und eine Transcend 4 GB. Das sind solche TLC-Karten aus dem Baumarkt, die ich gemeint hatte... Erst die angekündigten SuperMLC-Karten von Transcend dürften da bezüglich der Lebensdauer besser sein: http://de.transcend-info.com/About/press/11116 Und das mit der Lebensdauer ist wirklich /signifikant/: die Samsung-Karten leben im Dauerschreibtest (Karte ist fast vollständig mit statischen Daten gefüllt, dann wird eine 100k-Datei laufend geschrieben, kopiert und gelöscht) gut 20x länger als Intenso-Karten mit "gleichen" Daten. Die Intenso-Karte zeigt nach einer Woche (oder früher) Fehler in den statischen Daten(!!), diese Dateien sind also korrupt und unbrauchbar. Die Samsung-Karten machen das mindestens 4-5 Monate lang mit, bis letztlich ähnliche Fehler auftreten. Wenn man davon ausgeht, dass beide ähnliche Speichertechnologien verwenden, dann ist die Firmware und das Wearleveling der Samsung-Karten signifikant besser.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Und das mit der Lebensdauer ist wirklich /signifikant/: die > Samsung-Karten leben im Dauerschreibtest (Karte ist fast vollständig mit > statischen Daten gefüllt, dann wird eine 100k-Datei laufend geschrieben, > kopiert und gelöscht) gut 20x länger als Intenso-Karten mit "gleichen" > Daten. Die Intenso-Karte zeigt nach einer Woche (oder früher) Fehler in > den statischen Daten(!!), diese Dateien sind also korrupt und > unbrauchbar. Die Samsung-Karten machen das mindestens 4-5 Monate lang > mit, bis letztlich ähnliche Fehler auftreten. Danke für die Info, das ist sehr interessant für uns. Ich werde das bei Gelegenheit bei uns prüfen bzw. für unseren Kunden etwas höherwertige SD-Karten bereitstellen. > Wenn man davon ausgeht, dass beide ähnliche Speichertechnologien > verwenden, dann ist die Firmware und das Wearleveling der Samsung-Karten > signifikant besser. Es kann aber auch stark vom Flash-Speicher beeinflusst sein, das würde auch die Preisunterschiede erklären. Auflötbarer Flash-Speicher ohne Controller benötigt auch nicht zwingend einen dedizierten uC, der Wear-Leveling und Co. betreibt, weil diese Hardware bereits aus den "guten" Chargen besteht und entsprechend verwendet werden kann. Allerdings sind dort die Schreib- und Lesevorgänge wohl auch eher seltener. Nevertheless: Ich habs geschafft! Danke Euch allen, die Tipps und Infos haben mir sehr weiter geholfen. Ich habe die gesamte Sensor-Routine in die Interrupts gepackt und etwas in der Geschwindigkeit optimiert, damit diese Interrupts nicht die restlichen Routinen schrotten. Ich hatte erst einen Fifo benutzen wollen, aber dann habe ich immer erst nach einem kompletten f_write()-Vorgang von FatFs eine Rückmeldung über den freien Speicher. In den FatFs-Unter-Routinen die Read-Pointer umsetzen wollte ich mir für den Moment sparen. Ich habe also eine "härtere" Methode gewählt, ich nenne es "SwitchBuffer". Ähnlich dem Fifo ist es ein Struct, der aber zwei Buffer beinhaltet. Einer wird beschrieben, der andere gelesen. Ich musste sie großzügig auslegen, damit keine Daten verloren gehen. Bisher funktioniert es, wenn beide Buffer 2048 Bytes :-) haben (auf dem xMega256A3U!). In der Größe würde nun wohl auch ein Fifo funktionieren, der sich erst nach f_write aktualisiert, weil dann immer noch genügend Platz zwischen dem Read und Write-Pointer wäre. Aber das ist Optimierungspotential. Der Vorteil ist nebenbei, dass immer 2048 Bytes auf einmal geschrieben werden können, und dadurch halten die SD-Karten wohl länger durch. Und bisher gehen keine Daten verloren, das funktioniert klasse! Danke nochmals.
Emanuel L. schrieb: > Es kann aber auch stark vom Flash-Speicher beeinflusst sein, das würde > auch die Preisunterschiede erklären. > Auflötbarer Flash-Speicher ohne Controller benötigt auch nicht zwingend > einen dedizierten uC, der Wear-Leveling und Co. betreibt, weil diese > Hardware bereits aus den "guten" Chargen besteht und entsprechend > verwendet werden kann. Allerdings sind dort die Schreib- und Lesevorgänge > wohl auch eher seltener. Richtig. Er braucht aber dann wieder Wearleveling, wenn ein Dateisystem drauf läuft und beliebige Prozesse beliebige Dateien schreiben und ändern können. Emanuel L. schrieb: > Der Vorteil ist nebenbei, dass immer 2048 Bytes auf einmal geschrieben > werden können, und dadurch halten die SD-Karten wohl länger durch. Die Karten sind aufgrund ihrer noch größeren Blockgröße vorranig auf große Dateien und statischen Betrieb ausgelegt. Das ist es ja, was eine normale Kamera oder ine Handy macht: ab und zu eine 2MB Datei und dann lange Ruhe...
Emanuel L. schrieb: > Ich habe also eine "härtere" Methode gewählt, ich nenne es > "SwitchBuffer". Herzlichen Glückwunsch, du hast den Doppelpuffer neu erfunden :-)
@ Emanuel Leicht (eleicht) >weiter geholfen. Ich habe die gesamte Sensor-Routine in die Interrupts >gepackt und etwas in der Geschwindigkeit optimiert, damit diese >Interrupts nicht die restlichen Routinen schrotten. Gut. >Ich hatte erst einen Fifo benutzen wollen, aber dann habe ich immer erst >nach einem kompletten f_write()-Vorgang von FatFs eine Rückmeldung über >den freien Speicher. Wieso? Du kannst VORHER prüfen, wieviel Speicher auf der Karte noch frei ist und dann parallel mitschreiben, wieviele Bytes du in den FIFO schreibst. Damit hast du immer dieses Information, ganz unabhängig vom FATfs. > In den FatFs-Unter-Routinen die Read-Pointer >umsetzen wollte ich mir für den Moment sparen. Das ist auch totaler Murks. >Ich habe also eine "härtere" Methode gewählt, ich nenne es >"SwitchBuffer". >Ähnlich dem Fifo ist es ein Struct, der aber zwei Buffer beinhaltet. >Einer wird beschrieben, der andere gelesen. Was ist daran hart? Das ist eines der ältesten Konzepte der Welt, nennt sich Doppelpuffer oder neudeutsch double buffering. > Ich musste sie großzügig >auslegen, damit keine Daten verloren gehen. Bisher funktioniert es, wenn >beide Buffer 2048 Bytes :-) haben (auf dem xMega256A3U!). Das ist der Nachteil eines Doppelpuffers, man nutzt den vorhandenen Speicher nur knapp zur Hälfte aus. Ich schrieb nicht umsonst was von einem echten FIFO. >Der Vorteil ist nebenbei, dass immer 2048 Bytes auf einmal geschrieben >werden können, und dadurch halten die SD-Karten wohl länger durch. Schöne Illusion ;-) Du hast nich mal ansatzweie eine Ahnung oder auch nur Einfluß, wie der SD Controller seine Daten puffert und das Schreiben organisiert. Selbst FATfs puffer einen kompletten Sektor und schreibt nur sektorweise.
Falk B. schrieb: > @ Emanuel Leicht (eleicht) >>Ich hatte erst einen Fifo benutzen wollen, aber dann habe ich immer erst >>nach einem kompletten f_write()-Vorgang von FatFs eine Rückmeldung über >>den freien Speicher. > > Wieso? Du kannst VORHER prüfen, wieviel Speicher auf der Karte noch frei > ist und dann parallel mitschreiben, wieviele Bytes du in den FIFO > schreibst. Damit hast du immer dieses Information, ganz unabhängig vom > FATfs. Es ging mir nicht um den Speicher auf der SD-Karte, denn ich habe selbst im längsten Anwendungsfall immer noch massig Platz. Ich meinte den Platz im Fifo, der knapp werden kann, wenn der Write-Pointer den Read-Pointer einholt. Allerdings ist mir aufgefallen, dass ich das einfach über eine globale Variable lösen kann, die in den xmit-Routinen beschrieben wird. Am Ende werde ich es wohl irgendie so machen. >>Ich habe also eine "härtere" Methode gewählt, ich nenne es >>"SwitchBuffer". > > Was ist daran hart? Das ist eines der ältesten Konzepte der Welt, nennt > sich Doppelpuffer oder neudeutsch double buffering. Das da schonmal vorher jemand drauf gekommen ist, war mir auch klar, Sherlock. Mit "hart" meinte ich, dass es im Vergleich zum Fifo eher mehr an einer Holzhammer-Methode gleichkommt und dafür aber eben weniger effizient ist wie ein Fifo. > Ich schrieb nicht umsonst was von einem echten FIFO. Du klingst überheblich. >>Der Vorteil ist nebenbei, dass immer 2048 Bytes auf einmal geschrieben >>werden können, und dadurch halten die SD-Karten wohl länger durch. > > Schöne Illusion ;-) Du hast nich mal ansatzweie eine Ahnung oder auch > nur Einfluß, wie der SD Controller seine Daten puffert und das Schreiben > organisiert. Selbst FATfs puffer einen kompletten Sektor und schreibt > nur sektorweise. Soweit ich weiß, sind große Datenpakete generell besser. Eine einmalige 4x512-Byte Schreibe"anfrage" an die SD ist demnach besser als verteilte 1x512-Byte-Anfragen - so dachte ich zumindest. Ganz ohne zu wissen, was die SD damit macht.
Emanuel L. schrieb: > Eine einmalige 4x512-Byte Schreibe"anfrage" an die SD ist demnach besser > als verteilte 1x512-Byte-Anfragen - so dachte ich zumindest. Die Blöcke sind noch wesentlich größer... Aber alle Male ist ein einziger Zugriff besser als 4 verteilte. >> Ich schrieb nicht umsonst was von einem echten FIFO. > Du klingst überheblich. Halb so schlimm. Nur nicht unnötig aufregen...
@ Emanuel Leicht (eleicht) >Es ging mir nicht um den Speicher auf der SD-Karte, denn ich habe selbst >im längsten Anwendungsfall immer noch massig Platz. Ich meinte den Platz >im Fifo, der knapp werden kann, wenn der Write-Pointer den Read-Pointer >einholt. Ja und? Das Problem löst du aber nicht mit einem Doppelpuffer sondern immer nur mit ausreichen Speicher. >> Ich schrieb nicht umsonst was von einem echten FIFO. >Du klingst überheblich. Nö. Man hat dir einen guten Tip gegeben und du hast ihn, warum auch immer, ignoriert. Zumal im Artikel FIFO schon ein fertiger FIFO als Quelltext drin ist. >Soweit ich weiß, sind große Datenpakete generell besser. Eine einmalige >4x512-Byte Schreibe"anfrage" an die SD ist demnach besser als verteilte >1x512-Byte-Anfragen - so dachte ich zumindest. Ganz ohne zu wissen, was >die SD damit macht. Prinzipiell ja, praktisch kann man aber nicht sagen, ob das wirklich nennenswert Vorteile bringt. Auch 2kB ist immer noch winzig für eine SD-Karte.
Falk B. schrieb: > Man hat dir einen guten Tip gegeben und du hast ihn, warum auch > immer, ignoriert. Zumal im Artikel FIFO schon ein fertiger FIFO als > Quelltext drin ist. Ok, zum dritten Mal: Fifo implementieren: Nicht das Problem. Wissen, wo/wie ich in FatFs so schnell wie möglich die geschriebenen Daten (Read-Pointer) zurückgeben kann, war mir unbekannt und schien zu kompliziert. Lösung war: Riesen Doppelpuffer. Aktueller Stand: Bei diesem Riesenpuffer würde auch der Fifo funktionieren, der erst nach f_write() weiß, wieviel Daten übertragen wurden. Bei insgesamt 4 kB Puffer spielt es aber keine Rolle, welches System verwendet wird. Zukunft: Read-Pointer Rückgabewert in die xmit-Routinen rein, dann kann ein kleinerer Fifo implementiert werden als 4 kB und der Vorteil zum Doppelpuffer ausgespielt werden. >>Soweit ich weiß, sind große Datenpakete generell besser. > > Prinzipiell ja, praktisch kann man aber nicht sagen, ob das wirklich > nennenswert Vorteile bringt. Auch 2kB ist immer noch winzig für eine > SD-Karte. Ich meine, irgendwo einmal einen Vergleich gesehen zu haben, bei dem Karten mit verschieden großen Daten über einen uC dauerhaft beantsprucht wurden. Bei diesem Vergleich hatte sich bereits in dieser - für SD-Karten in der Tat winzigen - Dateigröße ein Unterschied ergeben. Das ist aber nur Hintergrundwissen, das ich mir gespeichert hatte.
Meine 2 cEuro: - Die Speedclass garantiert tatsächlich bei korrekter Verwendung von Blöcken in Allocation-Unit Größe einen Datendurchsatz - Die Speedclass garantiert meines Wissens nach keine Latenzen. - Die Anzahl der "gleichzeitig" geschriebenen Datenblöcke hat Einfluss auf den Durchsatz, aber nicht auf die Latenzen - Billige SD-Karten sind massiv schlechter was die Latenzen angeht als z.B. SanDisk (Hier: Transcend 8GB bis zu 500 ms Latenz, SanDisk 8GB bis 100 ms Latenz) Die einzige Lösung ist ein FIFO. Auch Trim/Erase vor dem schreiben verhindert die Latenzen nicht (macht sie aber seltener, aber was nützt es?).
@ Emanuel Leicht (eleicht) >Fifo implementieren: Nicht das Problem. Also? >Wissen, wo/wie ich in FatFs so schnell wie möglich die geschriebenen >Daten (Read-Pointer) zurückgeben kann, war mir unbekannt und schien zu >kompliziert. Wozu brauchst du den? Du sagst FATfs "schreib x Bytes", das tut es. Wenn man unsicher ist, kann man die wirklich geschriebene Anzahl DIREKT als Funktionsparameter ermittlen, *bw heißt der und er ist immer nötig. http://www.elm-chan.org/fsw/ff/en/write.html >Lösung war: Riesen Doppelpuffer. Lösung für ein nicht vorhandenes Problem? >Aktueller Stand: Bei diesem Riesenpuffer würde auch der Fifo >funktionieren, der erst nach f_write() weiß, wieviel Daten übertragen >wurden. Was willst du immer mit dieser Angabe? Du hast irgendwie eine verdreht Vorstellung dieses Ablaufs. > Bei insgesamt 4 kB Puffer spielt es aber keine Rolle, welches >System verwendet wird. >Zukunft: Read-Pointer Rückgabewert in die xmit-Routinen rein, Braucht kein Mensch. Der FIFO ist eine Black box, alles was man wissen muss, bekommt man über die Funktionen. Die ISR schreibt Daten rein, die Abholfunktion liest sie aus. Die internen Pointer des FIFOs interessieren dich dabei keine Sekunde. >dann kann >ein kleinerer Fifo implementiert werden als 4 kB und der Vorteil zum >Doppelpuffer ausgespielt werden. Der FIFO muss nur so groß sein, um für x ms deinen Datenstrom zu puffern. Das kannst du ausrechnen. >Ich meine, irgendwo einmal einen Vergleich gesehen zu haben, bei dem >Karten mit verschieden großen Daten über einen uC dauerhaft beantsprucht >wurden. Bei diesem Vergleich hatte sich bereits in dieser - für >SD-Karten in der Tat winzigen - Dateigröße ein Unterschied ergeben. Das >ist aber nur Hintergrundwissen, das ich mir gespeichert hatte. Tja, aber ohne belastbare Zahlen und Links ist es nichts weiter als eine schwache Erinnerung. Und die kann nur allzuoft täuschen.
Falk B. schrieb: > Der FIFO muss nur so groß sein, um für x ms deinen Datenstrom zu > puffern. Das kannst du ausrechnen. Kann ich nicht, genau das ist der Knackpunkt. Wenn die Schreibedauer auf die SD-Karte konstant wäre, ja. Wegen dieses Problems habe ich den Thread erst eröffnet. Klar kann ich eine Maximalzeit schätzen/messen, aber im Endeffekt benötige ich genügend Puffer, dass der Fifo sich nicht überholt, auch bei unregelmäßigeren Zeiten oder Ausreißern. > Der FIFO ist eine Black box, alles was man wissen > muss, bekommt man über die Funktionen. Die ISR schreibt Daten rein, die > Abholfunktion liest sie aus. Die internen Pointer des FIFOs > interessieren dich dabei keine Sekunde. Mein Punkt hier ist: Wenn ich bei 4 kB Puffer bleibe, ist es Wurst, ob es ein Doppelpuffer oder ein Fifo ist. Ein Fifo bringt mir nur den Vorteil, dass ich weniger Platz brauchen -könnte-. Beispiel: Fifo hat "nur noch" 2 kB (statt 2x2 kB des Doppelpuffers). Ich schreibe auf die SD-Karte, sobald 1024 Byte im Fifo sind. Wie soll ich sicher stellen, dass die Daten raus sind, bevor ich sie im Interrupt des Sensorempfangs überschreibe? Antwort: Entweder genügend großen Puffer, dass das "einfach nicht passiert" (siehe oben, "ausrechnen") -> damit wäre ich wieder bei ca. 4 kB, also kann ichs lassen, wie es ist. Oder: Ich setze in den DMA-Schreibefunktionen auf die SD-Karte den Read-Pointer mit um und weiß, dass schon wieder z.B. 512 Byte mehr Platz im Fifo sind, die ich wieder zum schreiben nutzen kann. Da bei mir die DMA-Routine in der xmit-Funktion ist, sprach ich davon, hier den Pointer "manuell" umsetzen zu müssen. Wenn der 512 Byte DMA-Zugriff als "Fifo-Funktion" (in fifo.c) implementiert ist, läuft das natürlich automatisch und der Fifo ist als Blackbox anzusehen. Ich widerspreche Dir also nicht, ich glaube das ist eher ein Missverständis, was ich mit dem Pointer-Umsetzen in der xmit-Funktion mein(t)e.
@ Emanuel Leicht (eleicht) >> Der FIFO muss nur so groß sein, um für x ms deinen Datenstrom zu >> puffern. Das kannst du ausrechnen. >Kann ich nicht, genau das ist der Knackpunkt. Wenn die Schreibedauer auf >die SD-Karte konstant wäre, ja. Wegen dieses Problems habe ich den >Thread erst eröffnet. Mensch, ist es denn SOOOO schwer? Natürlich muss man dort die LÄNGSTMÖGLICHE Verzögerung beim Schreiben nutzen und nicht den schnellen Durchschnittsfall!!! >Klar kann ich eine Maximalzeit schätzen/messen, aber im Endeffekt >enötige ich genügend Puffer, dass der Fifo sich nicht überholt, auch >bei unregelmäßigeren Zeiten oder Ausreißern. Ja und? Darum geht es doch!! >Mein Punkt hier ist: Wenn ich bei 4 kB Puffer bleibe, ist es Wurst, ob >es ein Doppelpuffer oder ein Fifo ist. Kann sein, ich weiß ja nicht wie hoch deine Datenrate ist. >Ein Fifo bringt mir nur den Vorteil, dass ich weniger Platz brauchen >-könnte-. Jain, ggf. vereinfachen sich auch ein paar Abläufe. Das ist aber nebensächlich. >Fifo hat "nur noch" 2 kB (statt 2x2 kB des Doppelpuffers). >Ich schreibe auf die SD-Karte, sobald 1024 Byte im Fifo sind. Wie soll >ich sicher stellen, dass die Daten raus sind, bevor ich sie im Interrupt >des Sensorempfangs überschreibe? Gar nicht, das müssen die restlichen 1024 Byte puffern. >Antwort: Entweder genügend großen Puffer, dass das "einfach nicht >passiert" (siehe oben, "ausrechnen") -> damit wäre ich wieder bei ca. 4 >kB, also kann ichs lassen, wie es ist. Das gilt aber nur, wenn du min. 1024 Byte am Stück schreiben willst. Wenn du schon eher schreibst, hast du mehr Puffer. >Oder: Ich setze in den DMA-Schreibefunktionen auf die SD-Karte den >Read-Pointer mit um und weiß, dass schon wieder z.B. 512 Byte mehr Platz >im Fifo sind, die ich wieder zum schreiben nutzen kann. Das würde ich lassen. >Ich widerspreche Dir also nicht, ich glaube das ist eher ein >Missverständis, was ich mit dem Pointer-Umsetzen in der xmit-Funktion >mein(t)e. Da ich deine Software nicht mal ansatzweise kenne, ist es müßig, darüber im Detail zu diskutieren. Aus der Ferne klingt es aber nach einem Quick & Dirty Hack. Davor kann man nur warnen. Natürlich funktioniert auch ein Doppelpuffer, aber ein FIFO ist im Einzelfall flexibler.
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.