Ich baue einen Datenlogger mit sehr vielen parallelen Kanälen (insgesamt
>100, aber mit mehreren Modulen) und einer hohen Datenrate. Das Gerät
soll modular aufgebaut sein und ich bin gerade dabei, mir die "optimale"
Modulgröße der einzelnen Einheiten zu überlegen. Jede der Einheiten soll
eine eigene Speicherkarte haben und mit den anderen synchronisiert
werden.
Daher meine Frage: Welche kontinuierliche Datenrate schafft ein
Mikrocontroller (geplant: STM32) mit einer microSD-Card?
Ist es sinnvoll ein Dateisystem zu verwenden oder kann/sollte ich direkt
auf die Karte schreiben? Im Prinzip benutze ich sie nur als relativ
billigen Speicher, ein direktes Auslesen am PC ist nicht vorgesehen,
auch weil alles in einem IP68 Gehäuse eingebaut wird und das Gerät
selbst als (USB) "Kartenleser" dient.
Luky schrieb:> Im Prinzip benutze ich sie nur als relativ billigen Speicher
Ein Tipp: mach mal ein paar Dauer-Untersuchungen vorneweg. Du könntest
da u.U. ganz hübsch auf die Nase fallen, wenn du mit "schnell und viel
schreiben" nach 2 Wochen die microSD kaputt gemacht hast.
Und eine "kontinuierliche" Datenrate wird dir keiner der Hersteller auf
Dauer garantieren. Denn wenn die Karte dann intern erst mal mit ihrem
Wearlevelling beschäftigt ist, dann meldet sie einfach "nicht bereit".
die beste Abhilfe hier ist, eine "übergroße" Karte zu kaufen, dass es
nicht zu schnell eng darauf wird.
Lass doch in einem halben Jahr einfach mal deine Erfahrungen hören...
Luky schrieb:> Welche kontinuierliche Datenrate schafft ein Mikrocontroller (geplant:> STM32) mit einer microSD-Card?
Kommt auf die Karte an, und auf die Art der Ansteuerung. Per 1-Bit-SPI
erreicht eine SD-Karte nur einen Bruchteil der eigentlich möglichen
Geschwindigkeit, die bei modernen SDHC- bzw. SDXC-Karten schon deutlich
im zweistelligen MByte/sec-Bereich liegen kann.
Was ist dauernd und viel ? Bei nur linearem Zugriff wird's einfacher.
Muss waehrend dem Schreiben auch gelesen werden koennen, resp umgekehrt
?
Allenfalls an eine SSD denken. Oder bei hoeheren Anforderungen an eine
HD.
Es muss nicht gleichzeitig gelesen und geschrieben werden.
Jeder Kanal empfängt 100kByte/s an Daten, aber nur, wenn das System im
Betrieb ist, also nicht 24/7. Dass irgendwann mal Schluss ist, ist klar.
Wenn Du auf hohe Transferraten angewiesen bist, darfst Du das
SPI-Protokoll bei SD-Karten NICHT verwenden. Du MUSST das MCI (MMC
Command Interface) Protokoll verwenden, und zwar im 4 Bit Modus. Wenn Du
das nicht kannst oder hast, vergiss es.
SD-Karten können sogenannte "Class" Angaben haben, die dann die minimale
durchschnittliche (!) Schreibgeschwindigkeit anzeigen. Wichtig ist das
Wort "durchschnittlich", denn SD-Karten können schon einmal Pausen von
einer halben Sekunde fürs Wear Leveling einlegen. Du brauchst also
genügen MB RAM zum Puffern. Echtzeitfähig sieht anders aus.
Und: Der Standard sieht FAT32 bei SDHC, ExFat bei SDXC vor.
fchk
Luky schrieb:> Es muss nicht gleichzeitig gelesen und geschrieben werden.> Jeder Kanal empfängt 100kByte/s an Daten, aber nur, wenn das System im> Betrieb ist
Das halte ich für nicht völlig aus der Welt. Ich habe im SPI-Modus
(allerdings mit HW-SPI auf einem Coldfire-Mikrocontroller) schon 5-600
kB/s Schreibrate hingekriegt (auf FAT32). Einen ausreichend großen
Puffer dazu, falls sich die Karte doch mal allzulange mit sich selbst
beschäftigt und das könnte funktionieren.
Luky schrieb:> Jeder Kanal empfängt 100kByte/s an DatenLuky schrieb:> sehr vielen parallelen Kanälen (insgesamt >100
Also mehr als 10 MByte/sec bei guter Aufbereitung.
Luky schrieb:> Jeder Kanal empfängt 100kByte/s an Daten,
Hui, da musst Du dann wohl eins der moderneren SD Protokolle nehmen, SPI
fällt dann aus. Du müsstest aber sowieso einen größeren µC nehmen, weil
Du auch einige MB an S(D)RAM als Puffer brauchst.
Außerdem sind die Karten sehr unterschiedlich in der Performance, die
Sandisk hier waren alle OK aber einige billige Typen ließen sich beim
Schreiben schon mal eine ganze Sekunde Zeit. Es kann also gut sein dass
Du verschiedene Kartentypen ausprobieren musst.
Über 32GB gibts dann ab Werk nur ExFAT, wenn man das auf dem µC nicht
haben will müsste man auf FAT32 umformatieren. Dabei sind IMO die
Clustergrenzen an Blockgrenzen (bis 64MB bei SDXC) auszurichten.
Also 100kB Sekunde ist langsam und habe ich schon Problemlos mit SPI
hinbekommen. Und zwar mit Filesystem.
Aber die Karten machen in der Zwischendurch immer mal ein paar hundert
Millisekunden Pause wenn sie ueber die Welt nachdenken. Deshalb braucht
man einen Buffer der fuer etwa 1s ausreicht. Ich ab einen SH2 mit intern
1MByte Ram genommen. :-)
Olaf
Ich glaube, hier gibt's noch ein grundsätzliches Verständnisproblem
hinsichtlich der Aufgabenstellung.
Ich (und andere) haben wohl verstanden, daß Du viele Microcontroller
aufsetzen willst, jeder mit seiner eigenen SD-Karte (und mind. 100 kB/s
Schreibrate).
Das müsste m.E. (mit ausreichend großem Puffer) relativ problemlos
funktionieren.
noch Andere haben verstanden, daß Du n x 100 kB/s auf einem
Mikrocontroller gleichzeitig schreiben mußt.
Das geht mit SD-Karte eher nicht. Zumindest nicht, wenn n > 5 - 6.
Ja, ich möchte n x 100 kB/s auf einem Mikrocontroller gleichzeitig
schreiben und daher herausfinden, wie groß n vernünftigerweise sein
kann, um die Gesamtzahl der Module möglichst zu reduzieren. 8 Kanäle pro
Controller / Speichereinheit wär schon toll.
Das Dateisystem ist übrigens nicht optional, sondern vorgeschrieben.
Also du musst FAT32 bei SDHC bzw. exFAT bei SDXC (wofür du erstmal
eine Lizenz bei Microsoft kaufen musst) Verwenden, um überhaupt die
Geschwindigkeit erreichen zu können.
Natürlich brauchst du das 4Bit SD Bus Protokoll, denn bei SPI ist die
Speed Class immer 0. Ich kann dir einen Erfahrungswert verraten: Samsung
Evo SDHC Karten schaffen locker 1MByte/Sec kontinuierlich, wenn du 64 KB
Puffer hast und pro ms 1kB Daten anfallen.
Du brauchst natürlich auch einen Mikrocontroller der das Interface
überhaupt hat: Einige STM32 haben ein SDIO Interface, aber das kann nur
High Speed, also max 24 MB/sec Ubertragungsrate und nur 10 MB/Sec
Schreibrate (Speed Class 10). Für mehr kannst du nach UHS fähigen
Mikrocontrollern suchen... und viele MB RAM wirst du dafür auch
brauchen.
Luky schrieb:> 8 Kanäle pro Controller / Speichereinheit wär schon toll.
Das wäre < 1 MByte/sec; sofern Du auch noch ein bisschen Speicher zum
Puffern mitbringst, sollte das problemlos zu schaffen sein.
Womit Du Dich beschäftigen solltest, ist die optimale Ansteuerung der
SD-Karten, nicht im 1-Bit-SPI-Modus und bevorzugt auch nicht im
4-Bit-SPI-Modus, sondern mit "MCI", wie Frank hier schon beschrieb:
Beitrag "Re: Maximale kontinuierliche Schreibrate microSD"
Luky schrieb:> Ja, ich möchte n x 100 kB/s auf einem Mikrocontroller gleichzeitig> schreiben und daher herausfinden, wie groß n vernünftigerweise sein> kann, um die Gesamtzahl der Module möglichst zu reduzieren. 8 Kanäle pro> Controller / Speichereinheit wär schon toll.
Nur so als Denkansatz:
Vielleicht kann ja eine geeignete Komprimierung deiner Messdaten den
Flaschenhals der SD-Karte noch entschärfen? Der Controller wird sich ja
eh langweilen.. -> Und das alles macht dann auch beim auslesen der
Messwerte mehr Spaß...
Programmierer schrieb:> Das Dateisystem ist übrigens nicht optional, sondern vorgeschrieben.
Blödsinn. Wer soll ihn denn verklagen, wenn er darauf kein FAT nutzt?
Bei Elm-Chans code gibt es den Modus _USE_FASTSEEK.
Damit müssten Datenraten von knapp 1Mbyte/s möglich sein. Leider ist
dieser Modus nicht dokumentiert. Ich habe auch keine Codebeispiele
dafür gefunden.
zu SDIO-Datenraten:
Beitrag "sdio problem mit 4bit-modus"
Rolf M. schrieb:> Blödsinn. Wer soll ihn denn verklagen, wenn er darauf kein FAT nutzt?
Der Controller in der Karte ist ohne Verwendung des im Standard
vorgesehenen Dateisystems nicht in der Lage zu erkennen welche Blöcke
belegt sind und das Wear Leveling korrekt/optimal auszuführen und die
angegebene Schreibrate (speed class) zu erreichen. Somit ist ohne das
Dateisystem laut Standard nicht einmal garantiert, dass die Karte
überhaupt funktioniert (was die meisten aber tun).
Naja, ich verstehe zwar deinen Einwand halte ihn auch für denkbar, aber
doch zweifelhaft. Was ist den ein FAT Filessystem? Dir ist klar das dies
höchst unterschiedlich aussehen kann? Also alleine Anzahl, Groesse und
Position der FATs. Clustergröße usw. Superfloppy? Da kann formatiert und
unterschieden werden bis der Arzt kommt. Meinst du wirklich der
Controller hat einen kompletten FAT Interpreter laufen?
Ich habe jedenfalls auf einigen meiner Karten seit Jahren ext2 drauf
laufen. Oder sie sogar partioniert und mehrere Filesysteme drauf. Es gab
noch nie ein problem.
Olaf
Olaf schrieb:> Was ist den ein FAT Filessystem? Dir ist klar das dies höchst> unterschiedlich aussehen kann?
Klar. Daher steht in der SD Spezifikation genau, wie das auszusehen hat
(zB 32kB Cluster Size, Partition beginnt ab 4 MB, Daten ab 8 MB, usw).
Vielleicht einfach mal die Spezifikation lesen bevor hier wilde
Vermutungen geäußert werden?
Olaf schrieb:> Meinst du wirklich der Controller hat einen kompletten FAT Interpreter> laufen?
Teilweise reicht auch, um die FAT zu verstehen und die freien Blocks zu
identifizieren.
Olaf schrieb:> Ich habe jedenfalls auf einigen meiner Karten seit Jahren ext2 drauf> laufen. Oder sie sogar partioniert und mehrere Filesysteme drauf. Es gab> noch nie ein problem.
Das heißt du hast immer kontinuierlich die angegebene Schreibrate
erreicht und das Wear Leveling ist optimal, also die Karte hält so lange
wo vom Hersteller gewünscht? Wie hast du das genau
gemessen/festgestellt? Wenn gar nicht, weißt du überhaupt nicht ob du
ein Problem hast. Außerdem muss das längst nicht bei allen Karten so
sein.
@grundschüler (Gast)
>Bei Elm-Chans code gibt es den Modus _USE_FASTSEEK.
Das bringt nur teilweise was. Damit werden Suchzugriffe auf die FAT
vermieden, welche nach dem Vollschreiben eines Clusters den nächsten
Cluster finden muss. Meisten reicht es schon, die maximale Dateilänge
vorher auszudehnen (preallocation), dann muss nur ein FAT Zugriff
gemacht werden, um den nächsten Cluster zu finden.
>Damit müssten Datenraten von knapp 1Mbyte/s möglich sein.
Auch mehr, was die Karte hergibt. Die einfachsten SD-Karten machen
4MB/s, das schafft man mit SPI und 25 MHz nicht ganz. MIt 4 Bit SDIO
schafft man das locker. Das ändert aber nix daran, dass durch Wear
Leveling ab und an halt mal ewige Denkpausen von 300ms und mehr
entstehen können.
> Leider ist>dieser Modus nicht dokumentiert. Ich habe auch keine Codebeispiele>dafür gefunden.
Bei Elm Chan ist er dokumentiert!
http://elm-chan.org/fsw/ff/en/lseek.html
Luky schrieb:> Eine halbe Sekunde ist viel... Gibt es vergleichbar preiswerte> Alternativen wenn ich mich selbst um das Wear Leveling kümmern kann?
Du kannst rohes SLC NAND Flash verwenden. Dann bist Du selber für
Fehlerkorrektur, Bad Block Mapping, Wear Levelling etc verantwortlich.
MLC und TLC NAND Flash solltest Du nicht nehmen, das wird zu aufwändig.
fchk
@ Oder Doch (jetztnicht)
>Solange man nur linear schreibt muss man sich nicht um Wearleveling>kuemmern, denn dabei kommt jeder Sektor gleich oft dran...
Wollen wir wetten, daß das der Controller anders sieht? Denn die
Zuordung logischer Sektoren zu physischen Sektoren ist sein Geheimnis.
Ausserdem werden beim Löschen und Überschreiben von Dateien Sektoren
wieder beschrieben.
@ Frank K. (fchk)
>> Eine halbe Sekunde ist viel... Gibt es vergleichbar preiswerte>> Alternativen wenn ich mich selbst um das Wear Leveling kümmern kann?>Du kannst rohes SLC NAND Flash verwenden. Dann bist Du selber für>Fehlerkorrektur, Bad Block Mapping, Wear Levelling etc verantwortlich.>MLC und TLC NAND Flash solltest Du nicht nehmen, das wird zu aufwändig.
Machbar. Aber ob sich DAS lohnt. Ein paar MB SDRAM gibt es für nen Appel
& Ei, muss man nur den passenden Controller auswählen.
Falk B. schrieb:> @ Frank K. (fchk)>>>> Eine halbe Sekunde ist viel... Gibt es vergleichbar preiswerte>>> Alternativen wenn ich mich selbst um das Wear Leveling kümmern kann?>>>Du kannst rohes SLC NAND Flash verwenden. Dann bist Du selber für>>Fehlerkorrektur, Bad Block Mapping, Wear Levelling etc verantwortlich.>>>MLC und TLC NAND Flash solltest Du nicht nehmen, das wird zu aufwändig.>> Machbar. Aber ob sich DAS lohnt. Ein paar MB SDRAM gibt es für nen Appel> & Ei, muss man nur den passenden Controller auswählen.
Wobei das auch nicht immer so unkritisch ist.
Und: Ich gehe nicht davon aus, dass noch irgend ein Hersteller SLC Flash
in den SD-Karten verbaut. Da werden die letzten Restbestände mit 30% Bad
Blocks verwurstet. Durch den internen Controller merkt es ja niemand
gleich.
SLC Flash ist da zuverlässiger, und es ist deterministisch. Und von der
Ansteuerung einfacher als eine SD-Karte.
fchk
Ich habe neulich eine 32GB Karte von Sandisk für mein Schmachtphone
gekauft.
Und da lag ein Zettel bei, auf dem Stand dick und fett, dass die der
Garantieanspruch erlischt, wenn man die Karte anders Formatiert, als
geliefert. Sie warnen auch davor, die bestehende Formatierung durch eine
vermeintlich gleiche zu überschreiben, weil dies die Leistung der Karte
beeinträchtigen kann.
Das ist zwar keine klare Info, welche Kriterien die Formatierung
erfüllen muss. Aber der Hersteller würde sowas sicher nicht schreiben,
wenn es völlig egal wäre.
Stefan U. schrieb:> Und da lag ein Zettel bei, auf dem Stand dick und fett, dass die der> Garantieanspruch erlischt, wenn man die Karte anders Formatiert, als> geliefert. Sie warnen auch davor, die bestehende Formatierung durch eine> vermeintlich gleiche zu überschreiben, weil dies die Leistung der Karte> beeinträchtigen kann.
Sehr interessant!
Dafür gibts extra von der SD Association ein Programm zum korrekt
formatieren:
https://www.sdcard.org/downloads/formatter_4/Oder D. schrieb:> Solange man nur linear schreibt muss man sich nicht um> Wearleveling> kuemmern, denn dabei kommt jeder Sektor gleich oft dran...
Beim Schreiben in FAT braucht man sich darum genauso wenig kümmern, denn
das macht der Controller der Karte. Dafür hat man beim der Verwendung
von FAT eine garantierte Geschwindigkeit.
Alao, anonymer Gast "Luky", wenn ich solche Anforderungen höre, denke
ich... sorry... an Praktikanten beim BND oder MAD. Da mag ich ernsthaft
gar keine Hinweise geben oder Anleitungen verlinken. Türlich geht das
alles, sogar ganz sauber, aber wie gesagt... Du klingst mir zu sehr nach
"Schulpraktikum, gekauft von interessierten Unternehmen, gekauft von
Geheimdiensten", und dann sage ich doch lieber: "Du, sorry, geht nicht."
Aber vielleicht findest du ja andere Trottel hier, die dir die Arbeit
abnehmen. Nichts für Ungut, kann ja sein.
Carsten P. schrieb:> Alao, anonymer Gast "Luky", wenn ich solche Anforderungen höre,> denke> ich... sorry... an Praktikanten beim BND oder MAD.
Was hast du denn geraucht? Aluhut kaputt? Was hat ein bisschen
Datenloggen mit Geheimdiensten zu tun? Es gibt jede Menge Anwendungen in
der Industrie wo man große Datenmengen klein/leicht/billig/schnell
aufzeichnen möchte. Denke nur mal an einen Fahrzeug-Prototypen mit
gewiss mindestens 100 Sensoren, deren Werte man nachträglich
hochauflösend betrachten möchte. Jede Actionkamera macht höhere
Datenraten usw...
Programmierer schrieb:> Dafür hat man beim der Verwendung> von FAT eine garantierte Geschwindigkeit.
Da bin ich mir noch nicht so sicher ob nicht irgendwo noch ein
Flaschenhals steckt. Wenn ich z.B. zu VIELE Ordner GLEICHZEITIG kopiere
dauert es länger als wenn ich den drüberliegenden kompletten Ordner auf
SD kopiere. Evtl. ist es auch eine Cache-Frage?
oszi40 schrieb:> Wenn ich z.B. zu VIELE Ordner GLEICHZEITIG kopiere> dauert es länger als wenn ich den drüberliegenden kompletten Ordner auf> SD kopiere.
Dann ist lediglich dein Kopierprogramm dumm, denn die Operation ist im
Endeffekt die selbe. Die Geschwindigkeitsgarantie bezieht sich natürlich
auf kontinuierliches Schreiben in wenige große Dateien, nicht auf das
Kopieren von Ordnern mit vielen kleinen Dateien. Ich habe auch bemerkt
dass Windows extrem lange braucht alle Dateien auf einer SD-Karte zu
löschen wenn das sehr viele sind; die Karte einfach neu zu formatieren
geht viel schneller...
oszi40 schrieb:> Evtl. ist es auch eine Cache-Frage?
Klar, man muss natürlich die zu schreibenden Daten schlau puffern. Wie
schon erwähnt habe ich mit 16 KB Blöcken gute Erfahrungen gemacht, was
auch damit zusammen hängen könnte, dass 16 KB die Maximalgröße für die
Recording Units laut Spezifikation ist.
