Ein Arduino ProMini 3,3 Volt schreibt Daten auf die SD-Karte. Angebunden ist die per SPI im China-Modul. Die Software nutzt <SPI.h> und <SD.h> der A*IDE 1.8.9 Jede Sekunde werden 18 Byte geschrieben, gelegentlich auch mal 24 Byte. Die Datei wird nach jedem Schreibvorgang geschlossen. Ich habe hier drei Karten, Bild im Anhang, deren Hersteller ich nicht kenne. Es dauert kaum drei Minuten, bis das Schreiben fehlschlägt - am PC oder mit H2testw ist keine Fehlfunktion zu erkennen. Aktuell läuft das mit einer Xmore-industrial über Stunden ohne jegliche Probleme. Der einzig augenscheinliche Unterschied ist, dass die Xmore schneller ist - bei den paar Bytes mag ich mir das aber nicht als Grund vorstellen. Auf was muss ich achten, wenn ich neue Karten kaufen muss?
Angehängte Dateien:
-
Front.jpg
31 KB -
Gravur.jpg
30 KB -
Xmore.jpg
36 KB
Manfred schrieb: > Auf was muss ich achten, wenn ich neue Karten kaufen muss? Auf Glück hoffen. Unzverlässige und inkompatible SD Karten sind leider genau so allgegenwärtig, wie schlechte Disketten in den 90er Jahren. SD Karten von SunDisk haben einen guten Ruf, ich glaube mit denen hatte hier noch niemand ernsthafte Probleme.
Stefan F. schrieb: > SunDisk Die nennen sich seit der Jahrtausendwende "SanDisk"... Manfred schrieb: > Auf was muss ich achten, wenn ich neue Karten kaufen muss? Nimm Kioxia oder Toshiba wenn dir die Xmore zu teuer sind. Aber lass die Finger von unbenamten microSD und von Consumerware wie Intenso und Verbatim.
:
Bearbeitet durch Moderator
SanDisk und Samsung, das sind die von mir bevorzugten Hersteller; keine Probleme damit, mit No-name hingegen gab es einige im Laufe der Jahre. Aber - nach gerade mal 180 Schreibvorgängen ein "Fehlschlagen", während diese Karten am PC keine Fehlfunktion zeigen? Da würde ich das Problem nicht bei der Karte suchen.
Vielleicht sollte man die Datei nicht jede Sekunde schliessen? Dann muss ja jedesmal die Verwaltungsstruktur erneuert werden. Und bei manchen Filesystemen liegt die immer an der gleichen Stelle. Also wird evtl jede Sekunde das gleiche Byte geändert?
> Es dauert kaum drei Minuten, bis das Schreiben fehlschlägt - am > PC oder mit H2testw ist keine Fehlfunktion zu erkennen. Ich rate mal, die karte macht dann irgendeine interne Verwaltungssache und ist fuer 100ms oder so nicht ansprechbar. Deine verkorkste Libarie merkt das nicht, oder sie gibt dir korrekt einen Fehler zurueck aber du wertest keine Rueckgabewerte aus. Olaf
Bekanntlich kann das Schreiben hin&wieder recht lange dauern, bis zu 400 ms habe ich schon gesehen. Umgekehrt aber auch: ein Dutzend SDCards von Intenso: beschrieben und sofort kontrollgelesen - einwandfrei. Nach einigen Wochen Lagerung (ohne Zugriff) dauerte das Lesen mancher Blöcke an die 100 ms; der Inhalt aber war korrekt.
Manfred schrieb: > Es dauert kaum drei Minuten, bis das Schreiben fehlschlägt - am > PC oder mit H2testw ist keine Fehlfunktion zu erkennen. vielleicht ist die Kontaktgabe an dem Arduino-Adapter schlecht? es gibt neuerdings sehr dünne Karten, ältere Adapter müssen damit nicht zurechtkommen, Abhilfe war manchmal Tesa auf die Kartenrückseite kleben um fehlende Dicke auszugleichen! Weil der Fehler am PC mit H2testw nicht auftritt, tippe ich auf anderen (µ)SD Adapter! Vielleicht fehlt dem Arduino-Adapter auch nur ein Pufferkondensator oder die Stromversorgung mangelt, typische Jumperkabel sind aus Eisen und nicht aus Kupfer und haben den 6-fachen Widerstandswert! Die möglichen Fehlerquellen sind schier unendlich.
:
Bearbeitet durch User
Don't do I/O! And if you have to, do ALOT. Nicht so krümelige Speichereien. Das kostet Strom und macht alles karputt! Sammeln und dann erst wegorgeln.
> Bekanntlich kann das Schreiben hin&wieder recht lange dauern, bis zu 400 > ms habe ich schon gesehen. Interessant, mein Rekord war bisher 230ms. Man lernt halt nie aus. :) Olaf
Lothar M. schrieb: > Nimm Kioxia oder Toshiba wenn dir die Xmore zu teuer sind. Der Preis wäre nachrangig. Xmore sind mir aus einer sicherheitskritischen Anwendung zugelaufen, bei den üblichen Bastelhändlern bekomme ich die nicht. PittyJ schrieb: > Vielleicht sollte man die Datei nicht jede Sekunde schliessen? Der Gedanke behagt mir nicht, weil ich dann im Fehlerfalle eine nicht lesbare Datei habe. olaf schrieb: > Deine verkorkste Libarie > merkt das nicht, oder sie gibt dir korrekt einen Fehler zurueck > aber du wertest keine Rueckgabewerte aus. Wie kommst Du darauf, am Problem vorbei? Die Library gibt die Anzahl geschriebener Bytes zurück und ich werte diese aus. Täte ich es nicht, würde ich erst Stunden / Tage später an der fehlerhaften Datei bemerken, dass mein Logging abgebrochen ist. Aber Du bringst mich auf die Idee, eine Software zu bauen, die keine Rückgabe auswertet und mir später die Datei anzugucken. S. Landolt schrieb: > Bekanntlich kann das Schreiben hin&wieder recht lange dauern, bis zu 400 > ms habe ich schon gesehen. Das kann ein Grund sein. Ich kann das Intervall auf 10 Sekunden umschalten, dann dürfte ja kein Fehler auftreten. Teste ich nächste Woche, derzeit ist das Ding bis Montag beschäftigt. Joachim B. schrieb: > vielleicht ist die Kontaktgabe an dem Arduino-Adapter schlecht? es gibt > neuerdings sehr dünne Karten, ältere Adapter müssen damit nicht > zurechtkommen, Unwahrscheinlich. > Weil der Fehler am PC mit H2testw nicht auftritt, tippe ich auf anderen > (µ)SD Adapter! Im Gerät ist ein SD-Modul, der Adapter von µSD nach Standard ist der selbe. > Vielleicht fehlt dem Arduino-Adapter auch nur ein Pufferkondensator oder > die Stromversorgung mangelt, typische Jumperkabel sind aus Eisen und > nicht aus Kupfer und haben den 6-fachen Widerstandswert! Die Werte sind mir bekannt, hatte ich mal gemessen und 2018 im China-Schnäppchen Thread gepostet. Bei meinen 10cm werden das knapp 0,5 Ohm sein, deren Spannungsabfall ich für vertretbar halte.
Manfred schrieb: > Ein Arduino ProMini 3,3 Volt schreibt Daten auf die SD-Karte. > Angebunden ist die per SPI im China-Modul. > Die Software nutzt <SPI.h> und <SD.h> der A*IDE 1.8.9 > > Jede Sekunde werden 18 Byte geschrieben, gelegentlich auch mal 24 Byte. > Die Datei wird nach jedem Schreibvorgang geschlossen. Warum? Hast du so viel Angst um deine Daten? Wenn du das machst, wird jedes mal der Puffer auf die SD-Karte geschrieben. Das killt sie nicht sofort, ist auf Dauer aber eher kontraproduktiv. Ich vermute einen Progrmmierfehler in deinem Programm. Vermutlich tust du die Datei NICHT korrekt schließen und wieder öffnen. Hatte ich auch mal, da frisst sich dann mal der Arduino fest, weil keine Handles für neue Dateien mehr vergeben werden können. Ich glaube bei 100 oder 255 offenen Dateien war Schluß. > Auf was muss ich achten, wenn ich neue Karten kaufen muss? Falsche Frage. Du musst den Fehler in deiner Software suchen, denn dort liegt er mit sehr hoher Wahrscheinlichkeit.
Stefan F. schrieb: >> Auf was muss ich achten, wenn ich neue Karten kaufen muss? > > Auf Glück hoffen. Unzverlässige und inkompatible SD Karten sind leider > genau so allgegenwärtig, wie schlechte Disketten in den 90er Jahren. Jaja, alle Anderen sind Schuld nie, niemals liegt des Problem bei einem Selber . . .
Lothar M. schrieb: > Aber lass die Finger von unbenamten microSD und von Consumerware wie > Intenso und Verbatim. Wenn gleich du nachweislich dort einen Fehler gefunden hast, liegt das Problem des OPs mit SEHR hoher Wahrscheinlichkeit nicht dort, zum der Effekt sehr leicht reproduzierbar ist.
olaf schrieb: > Ich rate mal, die karte macht dann irgendeine interne Verwaltungssache > und ist fuer 100ms oder so nicht ansprechbar. Deine verkorkste Libarie > merkt das nicht, oder sie gibt dir korrekt einen Fehler zurueck > aber du wertest keine Rueckgabewerte aus. So schlecht sind die Arduino-Libs nicht. Die können schon Dateien mehrfach öffnen und schließen, auch wenn der Ansatz des OPs fragwürdig ist.
Joachim B. schrieb: > Die möglichen Fehlerquellen sind schier unendlich. Na dann heul doch! Mann O Mann, was für wertvolle Hinweise! Was würde der OP nur ohne sie machen?
Manfred schrieb: >> Vielleicht sollte man die Datei nicht jede Sekunde schliessen? > > Der Gedanke behagt mir nicht, weil ich dann im Fehlerfalle eine nicht > lesbare Datei habe. Ist deine Hardware SOOO instabil? Sind deine Daten SOOOO wertvoll. Man könnte mindestens darüber nachdenken, das Speicherintervall DEUTLICH zu vergrößeren. 10s, 1min etc.
> Wie kommst Du darauf, am Problem vorbei? Die Library gibt die Anzahl > geschriebener Bytes zurück und ich werte diese aus. Täte ich es nicht, Weil es meiner Erfahrung entspricht als ich vor 20Jahren sowas selber programmiert habe. Alle diese Funktionen koennen Rueckgabewerte liefern wenn man dies denn auch abfragt. Manchmal erst nach langen Timeout. Die Karten liefern dann immer 0xff zurueck und die eigentlich Antwort ist dann ungleich 0xff. Dann trifft du auf Karten die immer sofort antworten, andere erst nach drei 0xff und irgendwann auch mal eine die noch langsamer wird. Es gibt geradezu unglaublich viele unterschiedliche SD-karten und keiner kann alles testen. Daher wird sehr viel Code draussen rumgeistern der da eben nicht optimal ist. Ganz besonders wenn er in irgendeinen Kinderzimmer fuer Arduino entstanden ist. Und das ist auch nicht boese gemeint, aber das kann dann eine Einzelperson nicht leisten. Letztlich programmiert man da der Realitaet immer hinterher. ICh hab z.B noch ein paar Karten die sind sowohl SD-Karte wie auch USB-Stick. Die haben das schraegste Zeitverhalten das ich jemals auf dem Oszi gesehen habe. Vermute weil da ein armer MCS51 schwer ueberfordert ist. Und je neuer die Karten sind um so groesser die internen Sektoren im Flash. DA werden keine 512Byte mehr geschrieben auch wenn die Karte dir das sagt. Deshalb kommen dann manchmal so schraege Wartezeiten zustande. Besonders natuerlich wenn du die Karte deslektierst und sie denkt das sie sich jetzt erstmal um ein paar interne Sachen kuemmern kann. Dein Problem wird sich sicher loesen lassen, ein paar Stunden mit dem Debugger und du hast es im Griff. .-) Aber nur bis naechsten Monat wieder eine KArte kommt die sich leicht anders verhaelt. Olaf
Rein aus dem Blickwinkel der Forderung von Genderistinnen, die Informatik zu enttechnisieren und mit Sozialthemen anzureichern lautet die Problembeschreibung: Zickig ist es, weil es schließlich "die" Karte und nicht "der" oder "das" Karte heißt. (Warnung, der Beitrag könnte Ironie enthalten.)
Falk B. schrieb: > Ich vermute einen Progrmmierfehler in deinem Programm. Vermutlich tust > du die Datei NICHT korrekt schließen und wieder öffnen. Hatte ich auch > mal, da frisst sich dann mal der Arduino fest, weil keine Handles für > neue Dateien mehr vergeben werden können. Ich glaube bei 100 oder 255 > offenen Dateien war Schluß. Am Dienstag wurden ca. 7200 Daten auf die Xmore-Karte geschrieben, ohne dass ein Fehler aufgetreten wäre. Aktuell läuft ein langsamerer Modus, alle 10 Sekunden - es dürften etwa 20.000 Datensätze auf der Karte sein. Ich sage "es dürften", weil noch keine Fehlermeldung geworfen wurde. Das lässt mir den Verdacht auf einen Überlauf geöffneter Dateien sehr unwahrscheinlich erscheinen. Es gibt auch keinen Absturz "frisst sich dann mal der Arduino fest", die Messung läuft sauber weiter, lediglich meine Unterroutine "WriteToCard" gibt einen Fehler zurück. Falk B. schrieb: > Joachim B. schrieb: >> Die möglichen Fehlerquellen sind schier unendlich. > Na dann heul doch! Mann O Mann, was für wertvolle Hinweise! Was würde > der OP nur ohne sie machen? Was soll das? Joachim B. gehört nicht zu den blutigen Anfängern, seine Gedanken bzgl. der Hardware sind es auf jeden Fall wert, darüber nachzudenken! ---- Die Ansätze zum Zeitverhalten der Karten sind die, die ich näher betrachten werde. Ich habe Geräte, die auf der gleichen Softwarebasis nur alle 10..15 Sekunden schreiben und dort noch keine Ausfälle erlebt. Das nachzutesten wird mehrere Tage dauern, abwarten, was dabei herauskommt.
Kioxia bekommst du bei TME GoodRAM industrial und Sandisk ebenso. Das auch in 2 GB, was im Consumerbereich quasi ausgestorben ist. WD purple (3 Jahre Herstellergarantie im 24/7 Betrieb, gedacht für Überwachungskameras, die in Schleife aufzeichnen) gibt es bei Cyberport. WD hat mit Kioxia ein Joint Venture. Hardware wird somit die gleiche sein. Firmware, Wearleveling und Overprovisioning können sich aber durchaus unterscheiden.
Manfred schrieb: > Am Dienstag wurden ca. 7200 Daten auf die Xmore-Karte geschrieben, ohne > dass ein Fehler aufgetreten wäre. > > Aktuell läuft ein langsamerer Modus, alle 10 Sekunden - es dürften etwa > 20.000 Datensätze auf der Karte sein. Ich sage "es dürften", weil noch > keine Fehlermeldung geworfen wurde. Ok, das ist schon mal ein starkes Indiz für eine Kartenproblem. > Das lässt mir den Verdacht auf einen Überlauf geöffneter Dateien sehr > unwahrscheinlich erscheinen. Stimmt. Ist aber noch nicht ganz ausgeschlossen. > Es gibt auch keinen Absturz "frisst sich dann mal der Arduino fest", die > Messung läuft sauber weiter, lediglich meine Unterroutine "WriteToCard" > gibt einen Fehler zurück. Welchen? >> Joachim B. schrieb: >>> Die möglichen Fehlerquellen sind schier unendlich. >> Na dann heul doch! Mann O Mann, was für wertvolle Hinweise! Was würde >> der OP nur ohne sie machen? > > Was soll das? Joachim B. gehört nicht zu den blutigen Anfängern, seine > Gedanken bzgl. der Hardware sind es auf jeden Fall wert, darüber > nachzudenken! Aber nicht mit so einem Gejammer und vollkommen SINNLOSEN und ENTMUTIGENDEM Kommentar! Aber ich bleibe dabei. Die Datei im Sekundentakt zu schließen und zu öffnen ist ein schlechtes Konzept.
Ich hatte vor Jahren mal eine ähnliche Loggingaufgabe. Ich habe ins Flash dann nur roh geschrieben. Initial wurde das gesamte Flash mit 0 vorinititalisiert. Es wurde reingeschrieben mit festem Record, inclusive Zeitstempel. Wenn Inhalt drin stand, dann war den Record auf jeden Fall != 0. Das Programm suchte sich am Anfang die letzte Schreibposition (binary Suche) und fügte dann die Daten an. Ganz ohne Filesystem, nur direktes Flash schreiben. Das System sollte Daten von Maschinen loggen, die auch während des Betriebes hart abgeschaltet werden können. Das hat alles super funktioniert. Überlebte Abstürze, Abschalten etc. Vielleicht noch mal das Konzept überdenken. Man muss dann nur auch unter Windows (oder wo man die Karte ausliest) roh lesen können. Bei Linux geht das.
PittyJ schrieb: > Ich hatte vor Jahren mal eine ähnliche Loggingaufgabe. Ich habe ins > Flash dann nur roh geschrieben. Blöde Idee bei SD Karten, deren Firmware (Wear-Leveling) ist auf FAT/Exfat ausgelegt. Und Chan FatFS ist üblicherweise so klein das man es im µC problemlos rein bekommt. SD Karten dürfen im SPI Mode mal eben 100mA aus den 3,3V saugen - das vergisst man mitunter im Hardware Design. Ich hatte hier auch schon no-name Karten die nach extremst kurzer Zeit ausfielen - grade im MCU SPI Betrieb. Sandisk oder Samsung Karten machen weniger Probleme.
> Aber ich bleibe dabei. Die Datei im Sekundentakt zu schließen und zu > öffnen ist ein schlechtes Konzept. Das denke ich auch. Aber manchmal wohl notwendig. Das Optimum ist natuerlich das ein Anwender jedesmal vor einer Entnahme die Karte erstmal abmeldet. Die Praxis sieht leider anders aus. Wenn dann die Daten wichtiger sind wie die Lebensdauer der Karte ist sowas wohl sinnvoll. Man koennte natuerlich zwischenspeichern und immer die letzen 10 oder 100 Meldungen auf einmal schreiben, aber wenn das wichtige Fehlermeldungen sind die man bei einem Systemausfall haben moechte? Olaf
> ... roh ... Blöde Idee bei SD Karten ...
Wie dem auch sei - eine meiner Anwendungen arbeitet so; ab Adresse 0
einige Blöcke als rudimentäres Inhaltsverzeichnis, dahinter Audio-Daten.
Eine takeMS 1 GB-SDC wird so etwa ein halbes Dutzend mal pro Monat
beschrieben, seit ca. zehn Jahren - hält noch immer durch.
> Eine takeMS 1 GB-SDC wird so etwa ein halbes Dutzend mal pro Monat > beschrieben, seit ca. zehn Jahren - hält noch immer durch. Vermutlich wegen Groesse und Alter noch SLC und nicht MLC. .-) Mein Eindruck ist das neuere Karten zickiger sind. Jedenfalls fuer Messtechnikanwendungen. Diese Industrialkarten gibt es nicht ohne Grund. Die kamen, oh Zufall, ja so vor 10-15Jahren in Mode. Olaf
olaf schrieb: > Man koennte natuerlich zwischenspeichern und immer die letzen 10 oder > 100 Meldungen auf einmal schreiben, aber wenn das wichtige > Fehlermeldungen sind die man bei einem Systemausfall haben moechte? Baut man eine USV für Arme, die zumindest den Controller + Karte noch für ein paar Sekunden am Leben hält, wenn der Strom ausfällt.
S. Landolt schrieb: >> ... roh ... Blöde Idee bei SD Karten ... > > Wie dem auch sei - eine meiner Anwendungen arbeitet so; ab Adresse 0 > einige Blöcke als rudimentäres Inhaltsverzeichnis, dahinter Audio-Daten. Das geht mit FAT genauso gut. Man muss nur am Anfang einmalig die Datei mit maximaler Größe anlegen, dann werden alle Sektoren reserviert und danach einer nach dem anderen geschrieben. > Eine takeMS 1 GB-SDC wird so etwa ein halbes Dutzend mal pro Monat > beschrieben, seit ca. zehn Jahren - hält noch immer durch. Was heißt das? Wieviele Daten kommen dort pro Monat drauf? Wohl kaum 6x1GB, oder?
Falk Brunner schrieb: > Das geht mit FAT genauso gut Das war ja nicht das Thema. > Wieviele Daten ... Spielt das eine Rolle? Jedesmal ein paar Dutzend MB, natürlich mit Überschreiben des Inhaltsverzeichnisses bei Adresse 0.
S. Landolt schrieb: >> Wieviele Daten ... > > Spielt das eine Rolle? Ja sicher. Denn auch auch SD-Karten haben, ebenso wie SSDs, eine maximale Schreibzyklenzahl.
S. Landolt schrieb: > natürlich mit Überschreiben des Inhaltsverzeichnisses bei Adresse 0. Ich gehe mal stark davon aus, dass jede vertrauenswürdige SD Karte das Inhaltsverzeichnis immer wieder woanders hin verschiebt damit sie Karte einigermaßen gleichmäßig verschleißt.
Stefan F. schrieb: > S. Landolt schrieb: >> natürlich mit Überschreiben des Inhaltsverzeichnisses bei Adresse 0. > > Ich gehe mal stark davon aus, dass jede vertrauenswürdige SD Karte das > Inhaltsverzeichnis immer wieder woanders hin verschiebt damit sie Karte > einigermaßen gleichmäßig verschleißt. Die SD-Karte weiß nichts vom Inhaltsverzeichnis, für sie sind es einfach Daten. Wenn die Karte ein Waer-Leveling hat, dann werden die Daten mal hier mal dort geschrieben. Unabhängig vom Inhalt der Daten.
:
Bearbeitet durch User
Jim M. schrieb: > PittyJ schrieb: >> Ich hatte vor Jahren mal eine ähnliche Loggingaufgabe. Ich habe ins >> Flash dann nur roh geschrieben. > > Blöde Idee bei SD Karten, deren Firmware (Wear-Leveling) ist auf > FAT/Exfat ausgelegt. Das war keine SD-Karte. Sondern ein fest verdrahteter Flash-Chip. Ich wollte nur ein Beispiel geben, wie man ohne Filesystem auch fehlertolerantes Logging mit wenig Aufwand machen kann. Zumindest reduziert das ein permanentes Schreiben in Filesystem-Strukturen und erfordert kein Wear-Leveling.
> Ich gehe mal stark davon aus, dass jede vertrauenswürdige SD Karte das
Das ist ein Traum den du so nicht nachgeben solltest.
Das Problem faengt schon damit an das es Dutzende Moeglichkeiten gibt
eine SD-Karte mit unterschiedlichen grossen FAT Inhaltsverzeichnissen in
unterschiedlichen groessen and verschiedenen Stellen abzulegen. Die
Karte koennte eine Superfloppy sein, sie kann eine Partitionstabelle
haben.
Frag dich mal warum jede Kamera in der Lage ist eine SD-Karte mit ihrem
eigenen Format zu formatieren. .-)
Nene, sowas kann der arme Controller nicht leisten.
Die werden eine Etage tiefer ansetzen. Die werden etwas groessere
Speicherbloecke haben als sie das nach aussen anzeigen und dort
Informationen wie Pruefsummen und Wearlevelung halten. Wenn dann die
Fehler pro Sektor an die Grenze der Korrektur kommen dann wird der
Sektor halt kopiert und fuer defekt erklaert.
Aber ich glaube nicht das auf Filesystemlevel gearbeitet wird. Das
wuerde zuviele externe Abhaengigkeiten reinbringen.
BTW: Ich habe SD-Karten auch immer problemlos mit EXT2 genutzt auch wenn
Windowsanwender dann immer gruen vor Besserwissertum wurden. :)
Olaf
olaf schrieb: > Nene, sowas kann der arme Controller nicht leisten. Gut dass es nur den einen Controller gibt, denn kennst du einen kennst du dann alle. Gut das alle Hersteller lügen, die ausdrücklich darauf hinweisen dass man die Karte nicht umformatieren soll bzw. bestimmte Formate vorgeben, insbesondere die "guten" Markenhersteller.
Stefan F. schrieb: > die ausdrücklich darauf hinweisen dass man die Karte nicht umformatieren > soll bzw. bestimmte Formate vorgeben, insbesondere die "guten" > Markenhersteller Hast du dazu mal eine Referenz?
> hinweisen dass man die Karte nicht umformatieren soll bzw. bestimmte > Formate vorgeben, insbesondere die "guten" Markenhersteller. Und die Hersteller deiner Kamera sagen dir: Du hast Probleme? Du willst was wichtiges machen wie Firmwareupdate? Ja dann formatiere erstmal die Karte in der Kamera.... Olaf
900ss D. schrieb: > Hast du dazu mal eine Referenz? Das stand bei bei einer Karte von Sony dabei, die ich damals für meine Digitalkamera kaufte. Das war eine besonders teure Karte mit vielen Jahren Garantie auf Datenerhalt. Die Anleitung ist online nicht verfügbar und ich habe die Kamera samt Karte und Anleitungen verkauft. Es gibt ein Extra Formatier-Tool dass man nehmen soll, um schlechte Performance oder verkürzte Lebensdauer zu vermeiden: https://www.sdcard.org/downloads/formatter/
> Es gibt ein Extra Formatier-Tool dass man nehmen soll, um schlechte > Performance oder verkürzte Lebensdauer zu vermeiden: > https://www.sdcard.org/downloads/formatter/ Das Tool ist bekannt. Eine NoName-SD, die unter Windows komische Dinge machte, war nach Behandlung mit dem SD-Formatter ganz tot. ----------- Mein Akkutester schreibt alle 15s pro Kanal seine Werte auf die Karte, er hat zwei Kanäle. Das ist die gleiche Softwarebasis wie mein aktuelles Sorgenkind und wird seit über 2 Jahren problemlos betrieben, hunderte von Stunden. Auch da habe ich eine Xmore drin. In den habe ich die Problemkarten eingesteckt, ich habe zwei davon - und nach ziemlich genau 11 Minuten steigen die aus. Ist ein Indiz, dass es nicht unbedingt am schnelleren Schreiben liegt. Danach habe ich eine 32Gb-Sandisk Class10 reingetan, breche ich jetzt nach knapp 6 Stunden ab, ohne Probleme 2x1340 Datensätze geschrieben. Mein anderer Aufbau "Sorgenkind" mit 10s-Intervall läuft mit der Xmore-Karte nun seit Donnerstag Mittag durch, etwa 56 Stunden. Das soll er noch bis Montag oder gar Dienstag tun, falls der Akku so lange reicht. Ich habe vorhin mit AutoIT ein Programm gebaut, was am PC etwa jede Sekunde einen Datensatz auf die Problemkarte schreibt. Das läuft jetzt seit knapp 2 Stunden / 7000 Datensätze ohne Ausfall. Was immer da in der Arduino-Umgebung anders ist, ich denke, ich werde es nicht ergründet bekommen.
Stefan F. schrieb: > Es gibt ein Extra Formatier-Tool dass man nehmen soll, um schlechte > Performance oder verkürzte Lebensdauer zu vermeiden Na ja, mag ja sein dass das hilft. Aber ich hab sehr starke Zweifel. Ich habe auf der Seite mal in die PDFs geschaut. Nichts wirklich informatives, eher Hochglanzprospekt mit oberflächlichem Geschwafel. So schätze ich dieses Tool auch ein. Es ist sicher eine Hilfe, damit ein unbedarfter Nutzer eine Karte mit einem ungeeignetem Tool die Karte nicht unbrauchbar macht. Aber vielleicht irre ich auch ;) Wenn eine Karte echtes (gutes) Wear-Leveling beherrscht, dann braucht sie keine Optimierung für irgendein Filesystem.
900ss D. schrieb: > Ich habe auf der Seite mal in die PDFs geschaut. Nichts wirklich > informatives, eher Hochglanzprospekt mit oberflächlichem Geschwafel. Die Details zum Wear Levelling werden leider immer noch streng geheim gehalten. Egal wo du suchst - nichts konkretes. Dazu kommt, dass alle zwei Wochen andere Karten verkauft werden, so dass man Erfahrungswerte anderer (welche Karten gut sind) auch kaum nutzen kann. > Wenn eine Karte echtes (gutes) Wear-Leveling beherrscht, > dann braucht sie keine Optimierung für irgendein Filesystem. Da bin ich bei dir. Bei SSD ist es definitiv so, und zwar allgemein, nicht nur bei bestimmten Modellen.
Stefan F. schrieb: > Die Details zum Wear Levelling werden leider immer noch streng geheim > gehalten. Ja, kein Hersteller lässt sich in die Karten gucken. Ich habe beruflich mit einem Flash "Framework" gearbeitet, da sollen die Algorithmen angeblich sogar mit Patenten geschützt gewesen sein. Aber trotzdem erwarte ich vom Hersteller genauere Angaben über die Massnahmen zum Schutz der Flashbausteine (SD-Karten). So kusieren nur Gerüchte. Bei den professionellen Karten sieht es etwas besser aus.
900ss D. schrieb: > Aber trotzdem erwarte ich vom Hersteller genauere Angaben über die > Massnahmen zum Schutz der Flashbausteine (SD-Karten). So konnte ich vor Jahren weder für SD und SSD nähere Angaben bekommen. Es hat etwas Zeit benötigt, bis herausgefunden werden könnte, dass dahinter nichts anderes Stand als kaschieren von Unwissenheit. Es gibt welche, die können die Ersatzzellen frei zuordnen, andere haben das in Blöcke aufgeteilt und die sind nur zugeordneten Teilbereichen zuzuordnen möglich. Letztere fallen gutmütiger aus, wenn auf der SD für Swap eine eigene Partition angelegt wurde.
900ss D. schrieb: >> Die Details zum Wear Levelling werden leider immer noch streng geheim >> gehalten. > > Ja, kein Hersteller lässt sich in die Karten gucken. Im wahrsten Sinne des Wortes! ;-)
Manfred schrieb: > Ich habe vorhin mit AutoIT ein Programm gebaut, was am PC etwa jede > Sekunde einen Datensatz auf die Problemkarte schreibt. Das läuft jetzt > seit knapp 2 Stunden / 7000 Datensätze ohne Ausfall. Noch eine Weile laufen lassen, und dann die Testdatei genau angeguckt: Anstatt 11.000 Datensätzen stehen nur 10.800 drin, etwa alle 50 fehlt einer! Ich habe heute eine Fehlerabfrage eingebaut, und gucke da, mit dieser gibt es nach einer Weile schreiben einen Abflug :-( Damit ist für mich nun klar, dass die Aurduino-Umgebung nicht der primär schuldige ist. Jetzt muß ich mir überlegen, entweder auf SD-Karten zu hoffen, die keine Pause machen oder meine Fehlerbehandlung zu verändern. Wer das nachvollziehen möchte, kann den Anhang unter AutoIT direkt im SciTE ausführen, sollte auch in der aktuellen Version laufen. Am Anfang Zeile 14 muß die Zieldatei angepasst werden, Zeilen 71..77 kann man auskommentieren, um ohne Fehlerbehandlung zu schreiben. https://www.autoitscript.com/site/autoit/downloads/
olaf schrieb: > Wenn dann die Daten wichtiger sind wie die Lebensdauer der Karte ist > sowas wohl sinnvoll. Das widerspricht sich allerdings, denn wenn die Karte kaputt geht, sind auch die Daten weg. Es sei denn, man tauscht sie so oft aus, dass man sich ausreichend sicher sein kann, dass sie so lange durchhält. Jim M. schrieb: > PittyJ schrieb: >> Ich hatte vor Jahren mal eine ähnliche Loggingaufgabe. Ich habe ins >> Flash dann nur roh geschrieben. > > Blöde Idee bei SD Karten, deren Firmware (Wear-Leveling) ist auf > FAT/Exfat ausgelegt. Sie dürfen unter der Annahme arbeiten, dass das drauf ist. Aber wenn man die Karte so beschreibt, dass kein spezifischer Sektor besonders oft beschrieben wird, sollte das auch auch nach dem Wear-Leveling so einer Karte kein Problem erzeugen. olaf schrieb: > Das Problem faengt schon damit an das es Dutzende Moeglichkeiten gibt > eine SD-Karte mit unterschiedlichen grossen FAT Inhaltsverzeichnissen in > unterschiedlichen groessen and verschiedenen Stellen abzulegen. Das Format ist genau vorgegeben. Wenn man die Karte davon abweichend formatiert, dann funktioniert es natürlich nicht mehr. > Frag dich mal warum jede Kamera in der Lage ist eine SD-Karte mit ihrem > eigenen Format zu formatieren. .-) Wie kommst du darauf, dass jede Kamera das anders macht? Wenn sie zur SD-Spec konform sein will, muss sie es die Karte auch genau so formatieren, wie das dort vorgegeben ist. 900ss D. schrieb: > Ja, kein Hersteller lässt sich in die Karten gucken. Ich habe beruflich > mit einem Flash "Framework" gearbeitet, da sollen die Algorithmen > angeblich sogar mit Patenten geschützt gewesen sein. Dann kann man ja in der Patentschrift nachlesen, wie das Verfahren funktioniert.
> auch die Daten weg. Es sei denn, man tauscht sie so oft aus, dass man > sich ausreichend sicher sein kann, dass sie so lange durchhält. Es gibt Leute die tauschen einmal im Jahr das Oel in ihren Autos aus weil das der Hersteller fuer sinnvoll haelt, es gibt Firmen die tauschen dir alle 2-3Jahre den Laptop aus weil sie hoffen das dann nie einer im Einsatz kaputt geht. Aehnliches kenne ich auch in der Messtechnik zumal es da sowieso viele Verbrauchsmaterialien gibt die ein vielfaches einer SD-Karte kosten. Es gibt sogar Leute die tauschen die Farbpatronen ihres Druckers aus weil der ihnen sagt das die ausgetauscht werden sollen. Und ihr tauscht ja auch die Streamertapes oder Festplatten eurer Backupstrategie aus bevor sie versagen oder? Also machbar ist das und neu ist es auch nicht. Olaf
Rolf M. schrieb: > Dann kann man ja in der Patentschrift nachlesen, wie das Verfahren > funktioniert. Ich muss das nicht wissen. Die SW hat einen guten Job gemacht :)
olaf schrieb: > Also machbar ist das und neu ist es auch nicht. Natürlich, aber welches Intervall würdest du für den Tausch von Noname-µSD-Karten, die im Sekundentakt beschrieben werden, als sinnvoll erachten?
> Noname-µSD-Karten, die im Sekundentakt beschrieben werden, als > sinnvoll erachten? Wieviel Sekunden brauchst du zum wechseln? .-) Ich wuerde weder fuer die Firma noch fuer Privat irgendso einen NoNameunsinn kaufen wenn ich Daten speichern moechte. Olaf
Rolf M. schrieb: > Noname-µSD-Karten Weshalb benutzt man diese wenn doch bekannt ist, dass die viel Probleme machen? Selbst wenn eine mal gut funktioniert ist ja nicht gesagt, dass die nächste auch gut funktioniert. Wenn jemand nach "geiz ist geil" einkauft, dann muss er das eben berücksichtigen und sich über den Ärger nicht wundern.
:
Bearbeitet durch User
>Natürlich, aber welches Intervall würdest du für den Tausch von >Noname-µSD-Karten, die im Sekundentakt beschrieben werden, als sinnvoll >erachten? 42 Tage
900ss D. schrieb: > Rolf M. schrieb: >> Noname-µSD-Karten > > Weshalb benutzt man diese wenn doch bekannt ist, dass die viel Probleme > machen? Das musst du den Threadersteller fragen, nicht mich. > Selbst wenn eine mal gut funktioniert ist ja nicht gesagt, dass > die nächste auch gut funktioniert. Richtig. Deshalb ja die Frage, was man da für ein Intervall ansetzen soll.
Kann es vielleicht sein, dass sich die Karte im SPI-Mode als MMC nur dankenswerterweise nicht verweigert? Ich meine, mal gelesen zu haben, dass die Karten ab 2 oder 4 GByte diesen SPI.Mode nicht offiziell mehr unterstützen, sonder eigentlich im 4-Bit SDIO (heist das so?) laufen sollen? Weiss da jemand was genaueres?
Axel R. schrieb: > Kann es vielleicht sein, dass sich die Karte im SPI-Mode als MMC nur > dankenswerterweise nicht verweigert? Nö, denn dann würde ja gar nichts funktionieren. Das Problem sind sporadische Aussetzer.
> SPI.Mode nicht offiziell mehr unterstützen ... > Weiss da jemand was genaueres? Nur Erfahrungswerte: 8 GB von Intenso sowie diverse Sorten 16 und 32 GB von SanDisk und Samsung laufen alle mit SPI.
> SPI.Mode nicht offiziell mehr unterstützen ... > Weiss da jemand was genaueres? musst du in die Spezifikation schauen. Wenn ich mich recht erinnere: bis SDXC must support, ab SDUC nicht mehr
Wikipedia behauptet: "Der SPI-Busmodus und der 1-Bit-SD-Busmodus sind für alle SD-Familien obligatorisch". Wobei gleich zu Beginn SD, SDHC, SDXC und SDUC aufgeführt sind.
Rolf M. schrieb: > Das widerspricht sich allerdings, denn wenn die Karte kaputt geht, sind > auch die Daten weg da muss ich widersprechen, nicht alle Daten sind weg, die Karte schaltet oft in den read only mode, die Karte ist zwar kaputt aber die letzten Daten sind oft noch lesbar. Ich habe hier mindestens 4 kaputte µSD die lesbar aber kaputt im read only mode sind, denn sie lassen sich mit keinem Tool oder mit gparted oder dd bearbeiten.
Rolf M. schrieb: > Natürlich, aber welches Intervall würdest du für den Tausch von > Noname-µSD-Karten, die im Sekundentakt beschrieben werden, als sinnvoll > erachten? 700ms. Dann hast Du noch 300ms Karenz, bevor der nächste Datensatz geschrieben werden soll. :)
Angehängte Dateien:
-
sd_spec.png
66 KB
dummschwaetzer schrieb: >> SPI.Mode nicht offiziell mehr unterstützen ... >> Weiss da jemand was genaueres? > musst du in die Spezifikation schauen. > Wenn ich mich recht erinnere: > bis SDXC must support, > ab SDUC nicht mehr Physical Layer Simplified Specification Version 9.00 Kapitel 7.1
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.