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
:
Bearbeitet durch User
Eine halbe Sekunde ist viel... Gibt es vergleichbar preiswerte Alternativen wenn ich mich selbst um das Wear Leveling kümmern kann?
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 Daten Luky 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
Schau mal ob: S34ML08G2 für dich in Frage kommt. Gibts für faires Geld bei Digikey ab Lager und reicht pro IC für knapp 3 Stunden.
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
Solange man nur linear schreibt muss man sich nicht um Wearleveling kuemmern, denn dabei kommt jeder Sektor gleich oft dran...
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.
:
Bearbeitet durch User
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.
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.