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?
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.
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.
> 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.
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.
>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.
:)
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
Front.jpg
(31 KB)
Gravur.jpg
(30 KB)
Xmore.jpg
(36 KB)
