Wenn ich eine SD Karte beschreibe und dann die Datei schließe, könnte man ja die Karte sofort abschalten. Ist das so oder benötigen SD Karten noch Zeit um das Dateisystem herunterzufahren? Falls ja, wie lange braucht das maximal oder kann man das irgendwie von außen feststellen?
Andreas B. schrieb: > Ist das so oder benötigen SD Karten noch Zeit um das Dateisystem > herunterzufahren? Der Host (PC, Mikrocontroller) ist dafür verantwortlich das Dateisystem in einen konsistenten Zustand zu bringen, das macht die SD-Karte nicht selbst. D.h. der Host muss alle Blöcke der Dateien rausschreiben und die FAT aktualisieren. Der Host muss nach jedem Schreibvorgang auf dessen Beendigung warten. Wenn alle nötigen Schreibvorgänge abgeschlossen sind kann die Karte abgeschaltet werden (Spannungsversorgung kappen). Andreas B. schrieb: > Falls ja, wie lange braucht das maximal Hängt von der Größe des Schreibpuffers und der Implementation des Dateisystemtreibers des Hosts, der SD-Karte und ihrer Speed Class ab. Es liegt also daran, wie du den Host-Treiber implementierst, bzw. davon, wie die verwendete Library es implementiert.
Programmierer schrieb: > D.h. der Host muss alle Blöcke der Dateien rausschreiben und die > FAT aktualisieren. Das ist soweit klar. Ich gehe jetzt davon aus, daß von Host Seite alles fertig ist. Ich meine nur, gelesen zu haben, daß SD Karten (manche?) danach noch etwas Zeit benötigen (buffer runterschreiben oder was auch immer). Daher die Frage.
Hallo Andreas, da du den Thread im "Mikrocontroller und Digitale Elektronik" gepostet hast und nicht in einem der beiden PC-Foren, gehe ich davon aus das du kein OS verwendest. Hier hängt es von deiner (mir unbekannten) Implementierung ab. Solltest du doch über ein OS auf die SD-Karte zugreifen, solltest du auf jeden Fall für die Datei die Funktion 'flush' aufrufen. Das sagt dem OS das es die Puffer mit der "Platte" synchronisieren soll. Wie schnell das geht, hängt vom OS und dem Filesystem ab. Volker
:
Bearbeitet durch User
Volker Z. schrieb: > Solltest du doch über ein OS auf die SD-Karte zugreifen, solltest du auf > jeden Fall für die Datei die Funktion 'flush' aufrufen. Deine Annahme ist korrekt: Es ist ein uC, dem der Strom entzogen wird. Der Zeitpunkt, wo die Datei geflusht und geschlossen wurde, sei bekannt. Von Host Seite ist also alles fertig. Es geht um die SD Karte selbst. Das ist ja nicht einfach nur ein Speicher sondern da ist ja auch ein uC drin, der evt. noch Buffer wegschreiben möchte oder was auch immer. Letztendlich will ich wissen, ob und wie lange ich die Speisespannung noch puffern muß, nachdem die Datei geschlossen wurde.
Andreas B. schrieb: > Ich meine nur, gelesen zu haben, daß SD Karten (manche?) > danach noch etwas Zeit benötigen (buffer runterschreiben oder was auch > immer). Nein, sobald die Karte nicht mehr "busy" signalisiert ist alles fertig und die Spannung kann getrennt werden. Andreas B. schrieb: > Letztendlich will ich wissen, ob und wie lange ich die Speisespannung > noch puffern muß, nachdem die Datei geschlossen wurde. Du vermischst hier die Ebenen. Wenn du eine Datei schließt, muss das OS/Library/Dateisystemimplementation noch lange nicht alles rausgeschrieben haben, d.h. es ist nur auf Anwendungsebene fertig, aber nicht notwendigerweise insgesamt auf Host-Ebene.
Programmierer schrieb: > Nein, sobald die Karte nicht mehr "busy" signalisiert ist alles fertig > und die Spannung kann getrennt werden. OK, dann hoffe ich mal, daß das wirklich so ist und ich das falsch in Erinnerung habe. > Du vermischst hier die Ebenen. Nein, es stimmt schon so. Es geht nicht um irgendein OS, sondern um eine uC Anwendung. Da läuft nichts im Hintergrund. Die Datei ist definitiv geschlossen.
Andreas B. schrieb: > Da läuft nichts im Hintergrund. Die Datei ist definitiv geschlossen. Was ist eine "Datei"? Der uC und die SD-Karte wissen nichts von Dateien. Wenn du in deinem Code mit "Dateien" hantierst, hast du irgendwas im Hintergrund, sei es OS oder Library wie FatFS. Und dieses etwas muss alle Operationen abschließen.
Programmierer schrieb: > Und dieses etwas muss > alle Operationen abschließen. Dieses Etwas ist die Elm chan lib. ;-)
Dann musst du der Elm-Chan-Lib eben mitteilen dass du die Karte abschalten willst, indem du das Dateisystem unmountest: https://stackoverflow.com/a/57671481 http://elm-chan.org/fsw/ff/doc/mount.html > To unregister the work area, specify a NULL to the fs, and then the work > area can be discarded. f_unmount function is implemented as a macro.
1 | #define f_unmount(path) f_mount(0, path, 0)
|
Programmierer schrieb: > Dann musst du der Elm-Chan-Lib eben mitteilen dass du die Karte > abschalten willst, indem du das Dateisystem unmountest: Ja, das ist alles klar. Ich rede auch von der SD Karte, nicht vom Dateisystem. Vom Host aus ist alles zu. Es geht wirklich nur um die SD Karte, ob die jetzt noch ein paar us/ms braucht oder nicht.
Andreas B. schrieb: > Wenn ich eine SD Karte beschreibe und dann die Datei schließe, könnte > man ja die Karte sofort abschalten. > Ist das so oder benötigen SD Karten noch Zeit um das Dateisystem > herunterzufahren? Bei Karten/Sticks (alles dasselbe in den Fall) sollte man mind. 1-2 Minuten warten bis man die abzieht. Ausnahme ist, wenn das Teil eine LED hat die das schreiben signalisiert, was leider oft nur bei Sticks der Fall ist. Ansonsten empfiehlt es sich auch bei Win-10 o.ä. das Teil abzumelden und auf die Rückmeldung zu warten. Zwar ist Standard mäßig kein Cache mehr aktiviert (Was die Wartezeit auf einige Minuten teilweise erhöht hat bei Win-98,und zu vielen Datenverlusten geführt hat). Trotzdem das Dateisystem puffert IMMER. Das ist technisch bedingt. Und eine Rückmeldung des Prg. das alles gespeichert ist, bedeutet NICHT das alles auf den lahmarschigen Datenträger ist. Es bedeutet nur, das das System alles hat, und es GERADE auf die Karte schreibt. Da die meisten Karten/Sticks noch mit FAT arbeiten, wird die Datei selbst wenn drauf,oft nicht in die Fat eingetragen. Und man merkt den Fehler erst wenn es zu spät ist. oft erlebt Man kann bei einen Stick mit LED gut sehen wie die arbeitet. Erst viel Blinken= schreiben, dann 1-2 Sek Pause dann noch einmal kurz blinken (FAT-Schreiben). DANN FERTIG.
Schlaumaier schrieb: > Trotzdem das Dateisystem puffert IMMER. Das ist technisch bedingt. Auch wenn man das Dateisystem bereits unmounted hat (f_unmount mit FatFS), "umount" unter Linux, oder eben Auswerfen unter Windows?
Schlaumaier schrieb: > Bei Karten/Sticks (alles dasselbe in den Fall) und mehr bla bla Bitte, bitte, bleib draußen. Programmierer schrieb: > Auch wenn man das Dateisystem bereits unmounted hat (f_unmount mit > FatFS), "umount" unter Linux, oder eben Auswerfen unter Windows? Natürlich nicht. Du kennst unseren "Spezialisten" wohl noch nicht.
:
Bearbeitet durch User
Entweder du hast ein gutes Datenblatt von der Karte oder du musst mit dem Schlimmsten rechnen. Was ist, wenn der letzte Sektor geschrieben werden soll, aber das Wear Leveling meint, es muss erst einen Block löschen? Das kann einige 100ms dauern. Gute SSDs haben zu dem Zweck intern einen fetten Kondensator, aber SD-Karten? Das ist bei billigen SD-Karten doch alles völlig undefiniert, auch, was eine BUSY-Meldung betrifft. Damit die Karte bei Tests schneller aussieht, kann sie doch schon mal Ready sagen, sobald sie die Daten hat. Und dann macht sie heimlich noch stundenlang weiter. Evt. findest du etwas bei www.swissbit.com/de/ -- was dann aber auch nur für deren SD-Karten gilt, aber es wäre ein Anhaltspunkt.
Programmierer schrieb: > Auch wenn man das Dateisystem bereits unmounted hat (f_unmount mit > FatFS), "umount" unter Linux, oder eben Auswerfen unter Windows? JA, und zwar solange bis die offizielle Meldung kommt, "Sie dürfen den Datenträger nun entfernen" o.ä. unter Linux . Das ist von OS unabhängig. Genau dafür ist der Befehl ja da. Bei auslösen wird extra geprüft ob der Puffer leer ist, und alle I.O. . Weshalb die Ausführung des Befehls auch einige Sekunden (o.länger) braucht. Es gilt: Nur weil du was hast, heißt das nicht, das das System das schon erledigt hast.
Bauform B. schrieb: > Das ist bei billigen SD-Karten doch alles völlig undefiniert, auch, was > eine BUSY-Meldung betrifft Paranoia. Die SD-Spec sagt eindeutig, dass das Schreiben abgeschlossen sein muss (!!) wenn das Busy Signal abgeschaltet wird. Alle Geräte welche SD-Karten nutzen (Handies, Kameras, ...) verlassen sich darauf. Wenn du davon ausgehst dass Karten das nicht einhalten, musst du auch davon ausgehen dass die Karte überhaupt keinen Flash enthält und die Daten einfach ins Nirvana schießt. Schlaumaier schrieb: > JA, und zwar solange bis die offizielle Meldung kommt, "Sie dürfen den > Datenträger nun entfernen" o.ä. unter Linux . Das ist von OS unabhängig. Also wenn "umount" bzw. "f_unmount" zurück kehrt. Also genau das was ich vorhin sagte und was allen völlig klar ist. Und weil dieses Warten normalerweise höchstens 1-2 Sekunden dauert muss man da nicht noch 2 Minuten warten.
Andreas B. schrieb: > und dann die Datei schließe, könnte > man ja die Karte sofort abschalten. Nein. Die meisten Betriebssysteme leeren die Schreibpuffer beim einfachen Schließen der Datei nicht sofort.
Bauform B. schrieb: > Was ist, wenn der letzte Sektor geschrieben > werden soll, aber das Wear Leveling meint, es muss erst einen Block > löschen? Genau solche Sachen meinte ich. > Das ist bei billigen SD-Karten doch alles völlig undefiniert, auch, was > eine BUSY-Meldung betrifft. Damit die Karte bei Tests schneller > aussieht, kann sie doch schon mal Ready sagen, sobald sie die Daten hat. > Und dann macht sie heimlich noch stundenlang weiter. Ich nutze zwar keine billigen Karten, aber wer sagt denn daß nicht alle Hersteller solche Tricks nutzen. > www.swissbit.com/de/ Danke! Da schau ich mal rein.
Programmierer schrieb: > Die SD-Spec sagt eindeutig, dass das Schreiben abgeschlossen > sein muss (!!) wenn das Busy Signal abgeschaltet wird. Hast Du da eine konkrete Quelle?
Ich habe einen uralten aber wunderschönen in Leder gefassten USB-Stick mit 1 GB. Wenn ich von mein Win-7 Rechner da 100 MB drauf kopiere, sagt das Prg. mir nach 2 Sek. Alles Erledigt. Wenn ich dann raus ziehe, ist das NIX erledigt. Wenn ich den nach der "erledigt" Meldung abmelde, dauert es fast 1 Minute bis die Meldung kommt "Sie dürfen den Datenträger nun entfernen". Genau DAS meine ich. Und ich habe den Systemcache nicht geändert. Ist reiner Schreibpuffer der da sein Zeug nicht schnell genug auf den Stick bekommt". Der Unterschied zum Cache ist, das Daten bei aktivierten Cache im Ram zwischengespeichert werden und es auch mal 1-2 Minuten dauern kann bis Windows die zu Festplatte schafft, wobei die Daten dann auch wieder durch den Schreibpuffer müssen. Oder was meint Ihr wieso ihr oft Datenverlust auf der Festplatte habt bei Stomausfall. Dieser Schreibpuffer ist einigen vielleicht noch bekannt aus der Anfängerzeit der CD-Brennerei. Da kam dann die Meldung "Datenpuffer leer" (Auf Deutsch schlecht übersetzt für "Buffer-Underrun" ).
Programmierer schrieb: > nd weil dieses Warten > normalerweise höchstens 1-2 Sekunden dauert muss man da nicht noch 2 > Minuten warten. Ist eine Frage des Datenträger. Bei SDHC Karten würden mich 5 Sekunden bei einen nicht voll belasteten Rechner auch sehr wundern. Bei meinen Leder-USB-Stick eher misstrauisch machen ;) Der ist halt 12 Jahre alt und extra lahm aber so schöööön ;)
Rüdiger B. schrieb: > Dann musst du dir das wohl durchlesen: > https://www.convict.lu/pdf/ProdManualSDCardv1.9.pdf Das ist ja uralt. Wie wäre es mit der aktuellen Spezifikation? https://www.sdcard.org/downloads/pls/pdf?p=Part1_Physical_Layer_Simplified_Specification_Ver8.00.jpg&f=Part1_Physical_Layer_Simplified_Specification_Ver8.00.pdf&e=EN_SS1_8 Da steht es irgendwo drin, ich weiß nicht mehr wo, ist zu lange her. Das neu hinzugekommene Kapitel "5.8.1.3 Power Off Notification" dürfte auch interessant sein. Schlaumaier schrieb: > Genau DAS meine ich. Das ist ein uralter Hut, und dass man nach dem Abmelden warten muss weiß jeder. Was ein Schreibcache ist dürfte hier auch jeder wissen. Dein Win98-Wissen dürfte für die Nutzung von FatFS nicht besonders relevant sein. Schlaumaier schrieb: > Oder was meint Ihr wieso ihr oft Datenverlust auf der Festplatte habt > bei Stomausfall. Nicht wenn man Journaling-Dateisysteme nutzt...
PS: Aktuelle Windows-Versionen sind so clever bei Wechseldatenträgern alles sofort rauszuschreiben bzw. wenig Cache zu verwenden. Wenn also das jeweilige Anwendungsprogramm mit Schreiben fertig ist, stehen die Chancen gut, dass man das Medium sofort trennen kann ohne Datenverlust. Es manuell abzumelden ist natürlich trotzdem eine gute Idee.
Programmierer schrieb: > Nicht wenn man Journaling-Dateisysteme nutzt... Quatsch mit Sosse. Diese "Journaling-Dateisysteme" sind zwar in der Lage Datenstrukturfehler zu erkennen, aber was nicht auf der Platte ist, ist weg bei Stromausfall. Einfach gesagt. "die verhindern ziemlich brauchbar das Chkdsk ne Menge File000*.CHK auf die Platte knallt. ;) Oder glaubst du das diese Speicherplatzfressenden "Journaling-Dateisysteme" wissen was da noch aus den Puffer auf die Platte will. Die sind höchstens gut, damit man nachsehen kann welche Datei du gelöscht hast. ;)
Schlaumaier schrieb: > aber was nicht auf der Platte ist, ist weg bei Stromausfall. Logisch. Aber was vorher drauf war bleibt konsistent.
Programmierer schrieb: > Logisch. Aber was vorher drauf war bleibt konsistent. Halbroh ist auch nicht gar. ;) Und was soll ich mit einer halben Datei anfangen ??
Programmierer schrieb: > https://www.sdcard.org/downloads/pls/pdf?p=Part1_Physical_Layer_Simplified_Specification_Ver8.00.jpg&f=Part1_Physical_Layer_Simplified_Specification_Ver8.00.pdf&e=EN_SS1_8 > > Da steht es irgendwo drin, ich weiß nicht mehr wo, ist zu lange her. Das > neu hinzugekommene Kapitel "5.8.1.3 Power Off Notification" dürfte auch > interessant sein. Das ist ausgesprochen interessant. Hier sieht man auch, daß man die Karten eben nicht einfach nach dem umounten abschalten darf. Jetzt muß ich nur noch schauen wie ich das in meine SW bekomme. In umount würde es ja reinpassen. ;-)
Schlaumaier schrieb: > Und was soll ich mit einer halben Datei anfangen ?? Bei Logdateien kann das schon helfen. Außerdem geht es ja auch um zuvor auf der Platte existierende Dateien. Eine kaputt geschriebene FAT32-FAT kann prinzipiell alle Daten zerwürfeln... Andreas B. schrieb: > Hier sieht man auch, daß man die > Karten eben nicht einfach nach dem umounten abschalten darf. Kann eigentlich nicht, denn dann wären ja alle alten Geräte nicht mehr "sicher". Nach der alten Spec ist das nämlich nicht nötig.
Journalling schützt in seiner üblichen Form nur die Metadaten, nicht die Fileinhalte. Damit wird sichergestellt, dass Blöcke nicht doppelt belegt werden oder weder frei noch irgendwo belegt sind. Dass Directory-Einträge nicht ins Leere zeigen und Files nicht ohne Directory-Eintrag sind. Aber der Inhalt von Files kann völliger Schrott sein. Manche Filesysteme sind vielleicht auch in der Lage, Journalling auch auf Inhalte auszudehnen. Aber m.W. nicht als Standardeinstellung. Wer in diese Richtung sucht, sollte sich auch Copy-on-Write Filesysteme wie ZFS und btrfs ansehen. Die tun sich damit leichter.
:
Bearbeitet durch User
Programmierer schrieb: > Eine kaputt geschriebene FAT32-FAT > kann prinzipiell alle Daten zerwürfeln... nönö Da ist das sogar sehr einfach. Man aktiviert per Rettungsprogramm einfach das Backup. Alle FAT's legen eine Kopie bevor sie Daten schreiben. Also ist mein Verlust = 1 Datei die nicht in der aktiven FAT stehen. ;) Deine Aussage ist aber richtig. Da Problem ist, das damals CHKDSK damit nix anfangen konnte und dann die Backup-Datei durch seine Rettungsaktion mit gekillt hat. Weshalb ich IMMER das CHKDSK abgebrochen habe. Und es erst durchgeführt habe wenn Windows gestartet wurde. ;) Da waren dann die Datenbestände wieder richtig und es wurden nur echte Fehler gefunden. ;9
Schlaumaier schrieb: > Da ist das sogar sehr einfach. Man aktiviert per Rettungsprogramm > einfach das Backup Und das ist genau so gut wie ein Journaling Dateisystem? Warum macht man sich damit überhaupt die Mühe?
Programmierer schrieb: > Andreas B. schrieb: >> Hier sieht man auch, daß man die >> Karten eben nicht einfach nach dem umounten abschalten darf. > > Kann eigentlich nicht, denn dann wären ja alle alten Geräte nicht mehr > "sicher". Nach der alten Spec ist das nämlich nicht nötig. Mit alten Karten wären sie sicher. Aber wenn ich neue einsetze, dann scheint das so nicht mehr zu sein.
Schlaumaier schrieb: > Man aktiviert per Rettungsprogramm einfach das Backup. Ich bitte, beim Thema zu bleiben. Es geht hier um einen SD-Shutdown am µC - und nicht um einen PC. Bitte die zuoberst stehenden Beiträge erst lesen, bevor man reflexartig antwortet. Das Verhalten eines Betriebssystems wie Windows oder Linux steht hier nicht zur Debatte. Wir sind hier unter "µC und Elektronik", nicht unter "PC Hard & Software". Der TO hat die Karte bereits mittels mittels FatFs von Elm Chan (http://elm-chan.org/fsw/ff/00index_e.html) unmounted. Die Frage bezieht sich auf das Verhalten der Karte nach f_unmount(). EDIT: Link eingefügt.
:
Bearbeitet durch Moderator
Andreas B. schrieb: > Mit alten Karten wären sie sicher. Aber wenn ich neue einsetze, dann > scheint das so nicht mehr zu sein. Das wäre dann nicht mehr abwärtskompatibel. Neue SD-Karten funktionieren in alten Geräten entweder ganz oder gar nicht (Initialisierung scheitert).
Programmierer schrieb: > Das wäre dann nicht mehr abwärtskompatibel. Stimmt. Wer sagt denn, daß das so sein muß? Die specs der aktuellen Karten zeigen das ja wohl. Interessant wäre ja mal zu wissen ab wann diese power down specs dazugekommen sind. Es gibt ja genug alte Geräte die mit Karten von z.B. >2GB nicht mehr zurechtkommen. Evt. fallen diese Specs dann mit irgendeiner neu eingeführten Speichergröße zusammen. Außerdem kann es ja sehr gut sein, daß auch alte Kameras ect. nach dem Ausschalten die Karte noch ein paar ms länger an der Spannung lassen. Kennst Du die FW irgendeiner Kamera?
:
Bearbeitet durch User
Programmierer schrieb: > Und das ist genau so gut wie ein Journaling Dateisystem? Warum macht man > sich damit überhaupt die Mühe? Weil FAT alt ist, und ein Bill Gates "angeblich" gesagt hat, kein Mensch braut mehr als 512 KB RAM. Größere Dateisysteme brauchen halt eine andere Verwaltung. Frank M. schrieb: > Die Frage bezieht > sich auf das Verhalten der Karte nach f_unmount(). Ich denke wenn die Rückmeldung des OS (egal welches) erfolgt ist, das die Karte komplett fertig ist. Wo drauf soll man sich als User den sonst verlassen. Selbst die Hersteller sagen das man sie "abmelden" soll. Irgendwie musst du doch irgendwas vertrauen. Also wird das verhalten der Karte sein, das sie "heia macht". Was bedeutet ihr Verhalten ist das selbe wie in meiner SD-Karten-Tasche :). Und bevor sie nicht elektrisch getrennt und wieder verbunden ist, redet das OS eh nicht mehr mit ihr.
Schlaumaier schrieb: > Ich denke wenn die Rückmeldung des OS (egal welches) erfolgt ist, das > die Karte komplett fertig ist. Das ist schlicht und ergreifend falsch. FatFS behandelt selbst kein PowerDown. Warum meldest Du Dich, wenn Du von der FatFs-Implementation von Elm Chan keine Ahnung hast? Es geht hier nicht um eine Rückmeldung eines OS, sondern um die korrekte Implementation des Power-Downs einer SD-Karte. Diese muss vom Entwickler selbst als medienspezifische Erweiterung/Anpassung des f_unmount()-Befehls (http://elm-chan.org/fsw/ff/doc/mount.html) eingebaut werden. Es geht hier um einen Physical Layer, der im Kapitel "5.8.1.3 Power Off Notification" der SD-Specification vom September 2020 beschrieben ist. In kurzen Worten:
1 | 1. POFS-Bit checken. |
2 | 2. Wenn POFs = 0, dann weiter bei 7. |
3 | 3. POFN-Bit auf 1 setzen. |
4 | 4. Busy-Signal testen, weiter, wenn Ready. |
5 | 5. POFR-Bit checken. |
6 | 6. Wenn POFR = 0, weiter bei 5. |
7 | 7. Power ausschalten. |
Timeout-Behandlungen habe ich hier mal weggelassen. Und nochmal: FatFs ist eine Lib für FAT-Filesysteme auf µC-Systemen ohne OS und behandelt kein konkretes Medium, z.B. eine SD-Karte. Die Implementation des "Treibers" ist Sache des Anwenders, hier des TOs.
:
Bearbeitet durch Moderator
Andreas B. schrieb: > Wenn ich eine SD Karte beschreibe und dann die Datei schließe, könnte > man ja die Karte sofort abschalten. Andreas B. schrieb: > Letztendlich will ich wissen, ob und wie lange ich die Speisespannung > noch puffern muß, nachdem die Datei geschlossen wurde. Das "schließen" der Datei ist eine Aktion, die sich im Betriebssystem des Rechners abspielt, der auf die Karte Zugreift. Auf der Karte selbst gibt es keine solche Operation. Da werden nur Blöcke gelesen und geschrieben. Die Karte braucht nach dem letzten Block eine Menge Takte, um den Schreibvorgang zu beenden. Das kann bis zu 200ms dauern, soweit ich mich erinnere. Danach kannst du sie abschalten, sprich: Nicht mehr takten oder gar ganz Stromlos machen. Bei der FatFs von Elm Chan beinhaltet das Schließen einer Datei den Aufruf der Funktion f_sync(), welche erst fertig wird, wenn die Karte es ebenfalls ist. Bei PC Betriebssystemen ist das anders. Da muss man die sync() Funktion extra aufrufen, bevor man die Karte entfernt. Kann man z.B. mit der Rechten Maustaste im Dateimanager und in der Task-Leiste machen. Bei Kameras und Smartphones muss man in der Regel das Gerät aus schalten, bevor man die Karte entfernen darf.
Stefan ⛄ F. schrieb: > Bei der FatFs von Elm Chan beinhaltet das Schließen einer Datei den > Aufruf der Funktion f_sync(), welche erst fertig wird, wenn die Karte es > ebenfalls ist. Genauer: f_sync() ruft disk_write() auf, welche (wie Frank M. schon schrieb) nicht Bestandteil von FatFs ist. Ob diese Funktion wirklich alles zu Ende bringt, bevor sie fertig wird, ist offen. "FatFs expects delayed write function of the disk control layer. The write operation to the media does not need to be completed when return from this function by what write operation is in progress or data is only stored into the write-back cache." Danach wird außerdem automatisch die Funktion sync_fs() aufgerufen, welche disk_ioctl(...CTRL_SYNC...) enthält. "Makes sure that the device has finished pending write process. If the disk I/O layer or storage device has a write-back cache, the dirty cache data must be committed to the medium immediately. Nothing to do for this command if each write operation to the medium is completed in the disk_write function." Also wenn der untere hardwarespezifische Layer richtig implementiert wurde, dann sollte nach dem Schließen der Datei wirklich alles abgeschlossen sein. Um ganz sicher zu gehen solltest du einen Blick in deine Funktionen disk_write() und disk_ioctl() werfen. Eine der beiden muss den Schreibzugriff vollständig abschließen, damit es so funktioniert, wie du willst.
Frank M. schrieb: > Das ist schlicht und ergreifend falsch. FatFS behandelt selbst kein > PowerDown. Warum meldest Du Dich, wenn Du von der FatFs-Implementation > von Elm Chan keine Ahnung hast? Die Frage des TO lässt nicht darauf schließen das er einen Treiber für die Karte schreiben will, bzw. deren Schreibprozesse kontrollieren will. Wenn er das wollte, würde ich ihm vorschlagen sind mit der passenden Dokumentation (einige Links wurden hier genannt) zu beschäftigen. Ich bin bei der Frage davon ausgegangen das er als User wissen will, wie lange er warten muss, bis er die Karte raus ziehen kann. 90% aller User die ich kenne melden nämlich keine Karten/Sticks mehr ab. Jedenfalls würde ich niemals in einen Forum fragen, wenn es um die Normen von SD-Karten und deren Handhabung geht. Erst recht nicht in diesen hier.
Schlaumaier schrieb: > Jedenfalls würde ich niemals in einen Forum fragen, wenn es um die > Normen von SD-Karten und deren Handhabung geht. Kannst du eine bessere Quelle empfehlen, an die man ohne besondere Mitgliedschaft in einem Club heran kommt? > 90% aller User die ich kenne melden nämlich keine Karten/Sticks mehr ab. Klingt dumm und unprofessionell. In meinem Umfeld ist es genau umgekehrt. Selbst meine Kinder machen das richtig, ohne dass ich es ihnen großartig erklären musste. Denn die haben aus ihren Fehlern selbst gelernt.
Die Abmelderei/Umonterei, wie es die LINUX'er so lieben, braucht es seit XP nicht mehr. Das BS kann damit umgehen. Höchstens ist die letzte geschriebene Datei weg. Man sollte auf das kleine Lämpchen am Kartenleser achten. Ich habe hier seit 15 Jahren einen kleinen Überwachungsrecorder. Da wird die Spannung immer hart abgeschalten. Nie Probleme mit dem Dateisystem der SD gehabt. Außer, dass vielleicht die letzte Datei nicht geschrieben wurde.
Stefan ⛄ F. schrieb: > Genauer: f_sync() ruft disk_write() auf, welche (wie Frank M. schon > schrieb) nicht Bestandteil von FatFs ist. Ob diese Funktion wirklich > alles zu Ende bringt, bevor sie fertig wird, ist offen. Sie bringt alle Schreibvorgänge zu Ende. Aber natürlich noch nicht das Warten auf die Karte selbst. (siehe o.g. Doc und die Ausführungen von Frank dazu) Der SD Teil ist übrigens auch von Elm chan. Es ist die sdmm.c. Ich habe es mal angehängt, falls es jemanden interessiert Schlaumaier schrieb: > Ich bin bei der Frage davon ausgegangen das er als User wissen will, wie > lange er warten muss, bis er die Karte raus ziehen kann. 90% aller User > die ich kenne melden nämlich keine Karten/Sticks mehr ab. Nein, weil Du nämlich weder den Thread gelesen hast, noch beachtet hast unter welchem Thema das hier läuft: Nicht PC, sondern uC. Du bist die ganze Zeit völlig am Thema vorbei. Was glaubst Du warum ich Dich gebeten habe, drau0en zu bleiben? michael_ schrieb: > Nie Probleme mit dem Dateisystem der SD gehabt. > Außer, dass vielleicht die letzte Datei nicht geschrieben wurde. Toll. So einen Murks möchte ich eigentlich nicht. Das geht so auf den Level wie die LEDs ohne Vorwiderstände.
Gann bleib bei deinem LINUX! Was geht mir dort das Gemaunte auf den Sack! Sogar bei Disketten. Sowas gab es unter WIN noch nie.
Gut, jetzt mitgekriegt, du meinst den kleinen Recorder. Aber das liegt in der Natur der Sache. Geht nicht anders. Außer du beschreibst die Karte Bit für Bit. Bsp.: Man kommt in den Raum, der Bewegungsmelder aktiviert den Recorder. Der ist auf 30sec eingestellt. Du nimmst ihn nach 20sec den Saft. Natürlich ist da die letzte Sequenz nicht mehr drauf. Mit einem MC wird es nicht anders gehen. Außer du hast Marsraketentechnik.
michael_ schrieb: > Aber das liegt in der Natur der Sache. Geht nicht anders. Doch, tut es. > Außer du beschreibst die Karte Bit für Bit. Ja, wenn man keine Ahnung hat. Für Dich gilt das gleiche wie für Schlaumeier: Euch habe ich mit diesem Thread eigentlich nicht adressiert. > Außer du hast Marsraketentechnik. Nein, aber Elkos und evtl. Pufferbatterie. Und um diese Dimensionierung geht es letztendlich. Und nein, ich werde keine Autobatterie anschließen.
Dein Elko nutzt dir da auch nichts, wenn der Kontroller kein Bit mehr rübrerschiebt. Eine Datei schließen kann nur der Kontroller. Die SD selbst ist da zu doof. Dann solltestdu nach jedem Bit die Datei schließen. Dann mach das doch.
michael_ schrieb: > Die SD selbst ist da zu doof. Eben nicht! Du scheinst eine vollkommen falsche Vorstellung von SD-Karten zu haben. Die sind alles andere als doof - auf denen werkelt ein Mikrocontroller (häufig ARM), der sich um die ganzen lästigen Details kümmert (wear leveling, error/defect management, reblocking, garbage collection, scrambling, etc), vergleichbar mit dem Controllern auf Festplatten. Deine Vorstellungen passen zu NAND-Flash - da muß sich der Host um den Kram kümmert (und das ist kompliziert). SD-Karten (und auch eMMC) sind NAND-Flash plus Controller, die dann eine Festplattenähnliche API bieten.
Andreas B. schrieb: > Nein, aber Elkos und evtl. Pufferbatterie. 5.8.2: 'Card shall complete Cache flush within 1 second.' Bei den nicht immer ganz kleinen (Schreib)Strömen dürfte ein passender Elko recht groß ausfallen.
michael_ schrieb: > 1. Die Abmelderei/Umonterei, … braucht es seit XP nicht mehr. > 2. Das BS kann damit umgehen. > 3. Höchstens ist die letzte geschriebene Datei weg. Sag mal, liest du eigentlich was du so schreibst, oder schlägst du nur gelegentlich mit der Stirn auf der Tastatur auf?
michael_ schrieb: > Die Abmelderei/Umonterei, wie es die LINUX'er so lieben, braucht es seit > XP nicht mehr. > Das BS kann damit umgehen. > Höchstens ist die letzte geschriebene Datei weg. Wenn du denkst, dass das bei Linux anders sei, hast du keine Ahnung.
Schlaumaier schrieb: > Die Frage des TO lässt nicht darauf schließen das er einen Treiber für > die Karte schreiben will Bei aufmerksamen Lesen der Beiträge vor Deinem hättest Du folgende Aussagen von Andreas B. wahrgenommen: > Es ist ein uC, dem der Strom entzogen wird. ... > Letztendlich will ich wissen, ob und wie lange ich die Speisespannung > noch puffern muß, nachdem die Datei geschlossen wurde. ... > Es geht nicht um irgendein OS, sondern um eine uC Anwendung. .. > Dieses Etwas ist die Elm chan lib. ;-) Dies hat er alles unter "µC & Elektronik" (!) geschrieben, bevor Du Dich gemeldet hast. Wenn man die Beiträge aber nur querliest und meint, schneller antworten zu müssen als man lesen kann, dann kann es natürlich passieren, dass man komplett am Thema vorbeiredet, da gebe ich Dir recht.
> Wenn man die Beiträge aber nur querliest und meint, schneller antworten
ICh hab den Eindruck die meisten hier wissen gar nicht was eine SD-Karte
so ist und labern vollkommen merkbefreit.
Wenn man selbst schon mal eine SD-Karte angesprochen hat dann sollte
man wissen das die zufrieden ist sobald sie nach einer Uebertragung
aufhoert 0xff als Busy zu senden. Und das kann auch garnicht anders sein
weil ich ja sobald die Karte mir ihr Okay gibt auch sofort ihre Buffer
wieder frisch vollballern kann ohne das es sie stoert.
Und selbst wenn man elm-chans Implementation nutzt, die es jetzt ja
schon ein paar Jahre gibt, sollte man doch den Lowlevel selber
geschrieben haben damit er zur eigenen Anwendung passt. Aber ich rate
mal, auch das kennen 90% der Helden hier nur als Kopie aus dem Internet.
Allerdings, auch ich waere bei manchen der modernen Karten heute
vorsichtig. Ich glaube naemlich nicht das sich jeder Hersteller immer
perfekt an die Standards gehalten hat. Besonders dann nicht wenn die
Karte selber noch exotisch ist, als z.B diese SD-Karten mit integriertem
WLAN(z.B von Toshiba), oder SD-Karten die auch noch ein USB-Interface
enthalten. Da hab ich selber auch schon echt schraeges Zeitverhalten
gesehen.
Olaf
Olaf schrieb: > Allerdings, auch ich waere bei manchen der modernen Karten heute > vorsichtig. Während die SANDisk-Dokumentation von 2003 (Link steht oben) einen etwaigen Power-Down komplett ignoriert, gibt es in der 2020er SD-Spezifikation (Link steht ebenfalls oben) ein neues Kapitel "Power-Down Notification". Offenbar sind modernere Karten intelligenter, so dass man durchaus davon ausgehen kann, dass sie eventuell noch "nebenbei" andere Sachen veranstalten wie "Wear Leveling" oder anderes. Von daher kann eine korrekte Behandlung eines Power-Downs bei Spannungsabschaltung des µC-Boards durchaus sinnvoll sein. Das Kapitel ist nicht von ungefähr dazugekommen. Hier wird auch von Timeout-Behandlungen in der Größenordnung von einer Sekunde gesprochen. Das ist schon eine Hausnummer. Ob tatsächlich eine Spannungsabschaltung nach kompletter Datensynchronisierung - jedoch ohne Power-Down-Behandlung - schädlich für eine moderne Karte sein kann, entzieht sich meiner Kenntnis. Aber genau das ist das Thema dieses Threads.
:
Bearbeitet durch Moderator
Olaf schrieb: > ICh hab den Eindruck die meisten hier wissen gar nicht was eine SD-Karte > so ist und labern vollkommen merkbefreit. +1 EDLC schrieb: > Bei den nicht immer ganz kleinen (Schreib)Strömen dürfte ein passender > Elko recht groß ausfallen. Um dieser Diskussion zuvorzukommen (sonst artet das hier noch aus, siehe BS Diskussionen hier im Thread): Der Logger (ja es ist ein Logger) läuft mit 24V, die er aus der D-Sub Buchse der RS232 bezieht. Diese 24V werden mit einem Elko gebuffert und via DC Wandler auf 3,3V geregelt. Diese 24V werden überwacht und bei ca. 20V das herunterfahren ausgelöst. Falls am DC Wandler nur noch 5V anliegen und die Karte noch nicht fertig ist, wird die 3.3V Backupbatterie (ja, die kann den Strom liefern) der RTC nach dem Wandler zugeschaltet (quasi als Notprogramm). Letzteres soll nur im Notfall und auch möglichst kurz erfolgen. D.h. sobald ich sicher bin, daß die Karte fertig ist -> power off. Das Device hat keine Schalter o.ä. weil es sehr miniaturisiert ist. Der Anwender soll den Logger abziehen, das Ding fährt runter und fertig.
Ich habe da was auf Reddit gefunden: https://www.reddit.com/r/raspberry_pi/comments/ex7dvo/quick_reminder_that_sd_cards_with_wearleveling/ Demnach wird Wear-Leveling (WL) durchaus auf größeren SD-Karten (ab 64 GB) eingesetzt.
Frank M. schrieb: > Demnach wird Wear-Leveling (WL) durchaus auf größeren SD-Karten (ab 64 > GB) eingesetzt. Sogar bei allen modernen Karten so wie es aussieht: https://de.transcend-info.com/Embedded/Essay-22 https://media.kingston.com/pdfs/MKF_283.1_Flash_Memory_Guide_DE.pdf usw.
Andreas B. schrieb: > Sogar bei allen modernen Karten so wie es aussieht Ich weiß nicht, ob Du meinen Beitrag von 10:13 Uhr (über Deinem) gelesen hast, da er sich zeitlich überschnitten hat. Mit dieser Info, dass WL auf SDs durchaus existiert, würde ich an Deiner Stelle die Power-Down-Notification mit aufnehmen. Ich vermute, dass man zusammen mit der in der Spezifikation dokumentierten Timeout-Behandlung auch abwärtskompatibel zu älteren SD-Karten ist. Ich persönlich verwende auch die elm chan Lib auf STM32, zum Beispiel im Projekt STECCY. Da ich hier jedoch ältere Karten mit maximal 4 GB verwende, gehe ich davon aus, dass man in diesem Fall die ältere Karte nach f_umount() einfach rausziehen könnte - wenn ich denn wollte. Bei neueren (größeren und auch teureren) SD-Karten bin ich mir da nicht so sicher....
:
Bearbeitet durch Moderator
Frank M. schrieb: > Mit dieser Info, dass WL auf SDs durchaus existiert, würde ich an Deiner > Stelle die Power-Down-Notification mit aufnehmen. Ich vermute, dass man > zusammen mit der in der Spezifikation dokumentierten Timeout-Behandlung > auch abwärtskompatibel zu älteren SD-Karten ist. Ja, das ist ja schon seit gestern klar. Ich habe auch geschrieben, daß ich das genauso das in die umount reinmachen will. Du hast es schön zusammengefaßt, aber einige haben das hier immer noch nicht begriffen. Mit diesem aktuellen doc der SD Karten (spec 8.0) das programmierer hier verlinkt hat ist meine Anfrage eigentlich auch schon beantwortet. Gerade noch ein interessantes doc gefunden: https://www.kingston.com/datasheets/SDCIT-specsheet-8gb-32gb_de.pdf Biss 32GB scheint ein einfacher power down (zumindest bei Kingston) möglich zu sein.
:
Bearbeitet durch User
Andreas B. schrieb: > Gerade noch ein interessantes doc gefunden: > https://www.kingston.com/datasheets/SDCIT-specsheet-8gb-32gb_de.pdf > Biss 32GB scheint ein einfacher power down (zumindest bei Kingston) > möglich zu sein. Ich würde das nicht an der Größe festmachen, sondern eher an Hersteller und Typ, bzw Anwendungsfall. Klassische SD-Karten sind auf den use case "Digitalkamera" optimiert. Also sequentielles Vollschreiben gefolgt von einer Komplettlöschung. In Raspis und Embedded-Anwendungen hast Du eher random access, und damit braucht man wear levelling. Da werden die Hersteller schon drauf reagiert haben.
Soul E. schrieb: > Klassische SD-Karten sind auf den use case > "Digitalkamera" optimiert. Also sequentielles Vollschreiben gefolgt von > einer Komplettlöschung. Die müssen aber schon »sehr klassisch« sein. Seit wie vielen Jahren gibt's eigentlich Wischfernsprecher (neudeutsch: Smartphones) und wie viele SD-Karten stecken da drin?
Soul E. schrieb: > Ich würde das nicht an der Größe festmachen, sondern eher an Hersteller > und Typ, bzw Anwendungsfall. An der Größe selbst würde ich es auch nicht festmachen, eher an den Zeitpunkt als diese Größen auf dem Markt kamen.
> Während die SANDisk-Dokumentation von 2003 (Link steht oben) einen > etwaigen Power-Down komplett ignoriert, gibt es in der 2020er > SD-Spezifikation (Link steht ebenfalls oben) ein neues Kapitel > "Power-Down Notification". Das entspricht auch meiner Erfahrung. Ich hab mich so 99-2000 intensiver mit den Karten beschaeftigt. Am Anfang sogar 8MB Karten mit FAT12. :-D Bei neueren spezialkarten nach 2010 oder 2015 hab ich dann auch ein paar Merkwuerdigkeiten im Timing gesehen. Olaf
Olaf schrieb: > Bei neueren spezialkarten nach 2010 oder 2015 hab ich dann auch ein paar > Merkwuerdigkeiten im Timing gesehen. "Neu" ist auch schon 10 Jahre her. ;-)
Frank M. schrieb: > Ich habe da was auf Reddit gefunden: Blödsinnsartikel: Ich hab nur den ersten Satz gelesen, aber das reicht: "Vast majority of SD cards do not have wear-leveling, and might keep on writing to the same blocks over and over." ist schon Unsinn. Ernstzunehmende Hersteller haben das Feature schon seit gefühlt einer Ewigkeit. Datenblätter für SD-Karten sind ja eher selten, daher aus einem allgemeinen Dokument von Sandisk aus 2010!: "Wear leveling is an intrinsic part of the erase pooling functionality of cards in the SanDisk microSD Card Product Family using NAND memory."
Zum Thema Wear-Leveling Alle brauchbaren FLASH basierten speicher systeme nutzen Wear-Leveling. Eine SD-Karte ohne währe innerhalb kürzester zeit tot. Für SD-Karten wird typischer weise FAT verwendet. Und das hat so seine eigenheiten, ... Gerade die FAT Tabelle ist mit einer der am stärksten belasteten bereiche, sollte das OS diese sektoren nicht Cashen. Zum Controller, ich hatte in errinerung das dort aufgeborte 8051 zum einsatz kommen. gab vor jahren auf dem CCC einen netten vortrag dazu, ... Zu den SD-Card Spezificationen / MMC-Spezificationen (Sind beide artverwand die MMC ist nur besser verfügbar) Alles was in den alten spezificationen drin steht sollte so auch für die neuen gelten. Den alte geräte sollten/müssen auch mit neuren karten laufen. genug öl ins feuer gegossen.
michael_ schrieb: > Gann bleib bei deinem LINUX! > Was geht mir dort das Gemaunte auf den Sack! > > Sogar bei Disketten. Sowas gab es unter WIN noch nie. Ist ja gut tätschel. Hast Du wieder Deine Medikamente vergessen?
BLE schrieb: > Zu den SD-Card Spezificationen / MMC-Spezificationen (Sind beide > artverwand die MMC ist nur besser verfügbar) SD und (e)MMC sind aber divergiert, d.h. neuere MMC (für eMMC) und SD Spec sind nicht mehr ernsthaft kompatibel IMHO. Wenn man sich für den SPI Mode bei SD Karten interessiert: Der war bei MMC bis 4.5 mit drin und dort etwas detaillierter spezifiziert, allerdings nur mit 20 statt 25MHz Takt.
> Für SD-Karten wird typischer weise FAT verwendet. Und das hat so seine > eigenheiten, ... Gerade die FAT Tabelle ist mit einer der am stärksten Ich hab sogar die Theorie das der Grund wieso Kameras ueblicherweise auch SD-Karten formatieren koennen, darin besteht das die Hersteller Angst haben auf ein FAT-Format (Partition, Superfloppy, 1,2,x FATs, Clustergroesse, reservierte Sektoren) zu treffen an das der Firmwareprogrammierer nicht gedacht hat. Olaf
Olaf schrieb: > Ich hab sogar die Theorie das der Grund wieso Kameras ueblicherweise > auch SD-Karten formatieren koennen, Das ist 100% so. Nicht umsonst empfehlen ja viele Kamerahersteller, die Karten in der Kamera zu formatieren. Und mal ehrlich: Würdest Du es als FW Programmmierer anders machen?
Andreas B. schrieb: > Nicht umsonst empfehlen ja viele Kamerahersteller, die > Karten in der Kamera zu formatieren. Nur blöd, dass die meisten Hersteller SD karten ausdrücklich davon abraten, ihre Karten zu formatieren. Sogar Sony, eine Firma die sowohl Kameras als auch SD Karten vermarktet.
Stefan ⛄ F. schrieb: > Sogar Sony, eine Firma die sowohl Kameras als auch SD Karten vermarktet. Und deshalb hat auch Sony eine Menüpunkt in der Kamera "Formatieren". ;-) Ich vermute einfach daß die Hersteller davon ausgehen, daß die meisten Leute zu blöd zum richtigen formatieren sind.
Andreas B. schrieb: > Und deshalb hat auch Sony eine Menüpunkt in der Kamera "Formatieren". > ;-) Das keine ich ja. Da steht in der Anleitung der Kamera, man soll die Karte nur mit der Kamera formatieren und in der Anleitung der Karte steht, man soll sie gar nicht formatieren. So kann man sich natürlich leicht aus jeglicher Gewährleistung oder bei Kompatibilitätsproblemen heraus reden.
Sony wird (wie andere SD Karten Hersteller), im Gegensatz zu MS, genau wissen wie man eine SD Karte korrekt formatiert. Es wird schon Gründe geben warum die SD association extra einen Formatter kreiert hat: https://www.sdcard.org/downloads/formatter/
Stefan ⛄ F. schrieb: > So kann man sich natürlich leicht aus jeglicher Gewährleistung oder bei > Kompatibilitätsproblemen heraus reden. Immer diese "bösen" Hersteller.... Das soll nur das Hickhack mit nicht so technisch firmen Usern reduzieren. Hab gestern auch wieder nen Lieverschein bekommen, mit nem Hinweis in extra groß und in Fettschrift: !!ACHTUNG!! Die Abkürzung MFG=Manufacturing=Herstellungsdatum!!
Ja formatieren von SD - Karten ist nicht trivieal, vorallem wenn das noch flash schonend und hinterher performant sein soll, ... Das betrift aber nciht nur SD-karen sondern auch USB-Sticks und SSDs. Das thema ist des cluster grösse (Zuordnungseinheit, ein vielfaches eines sektors 512Byte) sowie, und die position des ersten Datenclussters. im verhältniss zur internen flash kachel (die ist meist im ein vielfaches grösser als ein sektor / ein cluster meist faktor 2^n) Da sind Flash speicher gegenüber sich drehenden Festplatten etwas eigen, ... Wenn die positionierung falsh gemacht wird müssen für einen cluster immer 2 Flash kacheln verändert werden anstelle von nur einer, ... (sollte die Flash kachel kleiner als ein cluster sein, gibt es die probleme micht normalerweise nicht) neuere Windows versionen machen das eigentlich recht gut, bzw so gut wie sie es halt ohne informationen der internas halt machen können.
BLE schrieb: > neuere Windows versionen machen das eigentlich recht gut, bzw so gut wie > sie es halt ohne informationen der internas halt machen können. Das wäre mir neu. Das Formatter Tool sieht immer noch so aus wie in 1999, und kennt halt die Eigenheiten einer SD(HC, XC) Karte nicht. Übrigens käme man an die entsprechenden Daten über normale USB SD Kartenleser gar nicht ran AFAIK.
> Sony wird (wie andere SD Karten Hersteller), im Gegensatz zu MS, genau > wissen wie man eine SD Karte korrekt formatiert. Mit solchen Aussagen waere ich aber bei so grossen Firmen sehr vorsichtig. Was meinst du wieviele Entwicklungsabteilungen ein Konzern wie Sony haben wird die noch nicht mal voneinander wissen.... Olaf
>Den alte >geräte sollten/müssen auch mit neuren karten laufen. nein. Ein SD-Kartenlese kann nur bis 2G. Mit SD-XC, -HC... kann der nichts anfangen, da er die Geometrie der Karte nicht entschlüsseln kann. Anders herum: neue Geräte sollten auch alte Karten können.
BLE schrieb: > neuere Windows versionen machen das eigentlich recht gut, bzw so gut wie > sie es halt ohne informationen der internas halt machen können. Jetzt könnte aber doch endlich Schluß sein, mit den Hinweisen auf Windoof und andere BS! Der Faden ist doch hochinteressant, auch wenn ich nichts Wirkliches beitragen kann...aber in jedem dritten Beitrag erneut lesen zu müssen, was Windoof mittlerweile oder schon seit der Steinzeit "richtig" macht, ist einfach ätzend!! Und seit ich vor etlichen Jahren auf Linux/Ubuntu umgestiegen bin, stöpsel ich meinen USB-Stick jeweils nach Verschwinden des Fortschrittsfensters einfach ab. Mag sein, dass das mit SD-Karten problematischer sein kann, hier geht es aber um eine andere Welt. Sicher kommen noch einige interessante Hinweise. Ich würde mich freuen! Gruß Rainer
Hier gibts den für DAUs gemachten SD-Memory-Card-Formatter und die Infos die Du sicher suchst: https://www.heise.de/download/product/sd-formatter-74314
Olaf schrieb: >> Sony wird (wie andere SD Karten Hersteller), im Gegensatz zu MS, genau >> wissen wie man eine SD Karte korrekt formatiert. > > Mit solchen Aussagen waere ich aber bei so grossen Firmen sehr > vorsichtig. Was meinst du wieviele Entwicklungsabteilungen ein Konzern > wie Sony haben wird die noch nicht mal voneinander wissen.... Stimmt. Da hast Du auch wieder Recht. Rainer V. schrieb: > stöpsel ich meinen USB-Stick jeweils > nach Verschwinden des Fortschrittsfensters einfach ab. Das wirst Du auch in Zukunft bei jedem OS so machen können. Von dem Zeitpunkt an, in den der Fortschrittsbalken verschwunden ist, bis zu dem Zeitpunkt, in der sich Deine Hand Richtung USB Stick bewegt, dürfte eine gute Sekunde vergangen sein. Das passt aber nur dann wenn Dein OS direkt auf die Karte schreibt und nicht buffert. Ohne umounten bleibt das Risiko. Teo schrieb: > Hier gibts den für DAUs gemachten SD-Memory-Card-Formatter und die Infos > die Du sicher suchst: Na ja, bevor ich mir das von einer dubiosen Heise Seite herunterlade, gehe ich doch lieber direkt zu den o.a. Link der SD Association.
:
Bearbeitet durch User
Andreas B. schrieb: > Das passt aber nur dann wenn Dein OS direkt auf die Karte schreibt und > nicht buffert. Ohne umounten bleibt das Risiko. Interessant ist doch hier nur, was der Controller macht und wann ich wirklich die Karte sicher entfernen kann. Ich würde auf jeden Fall eine LED vorsehen, die aufleuchtet, wenn's soweit ist! Und damit kann man auch abschätzen, wie lange die Versorgung gepuffert werden muß. Und warum sollte es nicht das Busy-Signal sein, welches eben "fertig zum Auswerfen" signalisiert. Klar, hängt natürlich alles davon ab, welche Software man da verwendet. Meine doch gelesen zu haben, dass es ein komplettes Machwerk auf Git-Hub gibt. Das wäre mein Ansatzpunkt. Gruß Rainer
Rainer V. schrieb: > Ich würde auf jeden Fall eine > LED vorsehen, die aufleuchtet, wenn's soweit ist! Und damit kann man > auch abschätzen, wie lange die Versorgung gepuffert werden muß. Lies mal meine Anforderung weiter oben. Insbesondere das Konzept (19.10. 09:21)
Hrrrr... Die Uhrzeit ist anscheinen zeitzonen behafftet, ... bei mir taucht die unter 10:21 auf, ... Aber ggf noch ein paar tips, SD Karten sollten "eigentlich" Power Fail Save sein. Sollten somit immer entweder den alten oder den neue zustand eines sektors haben, ... FAT dateisysteme brauchen beim schreiben von dateien einige zusätzliche schreiboperationen auf der SD-karte: FAT-verkettungen aktuallisieren, Dateieinträge aktuallisieren, datenschreiben. 1. Versuch dateien immer 512Byte weise zu schrieben mit offsetzs auf n*512 Damit schreibst du immer genau einen sektor auf der SD - karte. 2. leg die Datei in der du arbeitest vorher in der benötigten grösse an. und arbeite danach in der FW nur noch in den bereits existirenden datei unter berücksichtigung von 1. Damit sind FAT verkettungen schon angelegt und müssen nicht mehr aktuallisiert werden. und der Dateieintrag existiert auch schon. und wird ggf je nach verwendtem FAT stack auch nicht mehr aktuallisiert.
BLE schrieb: > Hrrrr... Die Uhrzeit ist anscheinen zeitzonen behafftet, ... bei mir > taucht die unter 10:21 auf, Nein, sorry, das war nur eine falsche Umrechnung meinerseits (von JP aus). Und den ganzen Thread hast Du auch nicht gelesen. Sonst hättest Du festgestellt, daß das von der Elm-chan lib schon alles erledigt wird. Also wie so einige hier im Thread: Am Thema vorbei.
Hi, ja habe ich gelesen und ich dachte nur, dass es gerade auch zum Testen ganz hilfreich ist, wenn man eine (optische) Rückmeldung hat. Wenn du bei Stromausfall noch die Arbeit mit der Karte sicher beenden willst, dann mußt du das wohl mühevoll austesten oder eine gehörige Pufferzeit einbaun, mit der ganz sicher nicht schief gehen kann. Stromausfall ist die eine Sache, Entfernen der Karte im "normalen" Betrieb wäre die andere. Auch hierzu fände ich eine LED als Meldung ganz angebracht. Wenn's ganz elend werden soll, dann könnte man auch über eine mechanische Verriegelung nachdenken...aber das ist vielleicht jetzt am Thema vorbei... Gruß Rainer
Rainer V. schrieb: > Wenn's ganz elend werden soll, dann könnte man auch über > eine mechanische Verriegelung nachdenken... Laufwerke von SUN haben die Diskette nur per Motor ausgeworfen. Aber Andreas mag Geräte, die man jederzeit einfach ausstecken darf. Der Fehler liegt doch eindeutig bei den SD-Karten, weil "klein" und "schnell" total überbewertet werden, gegenüber "funktioniert". Na gut, insofern sind die Benutzer selbst schuld und wir müssen machen, dass es trotzdem kein Unglück gibt :(
Bauform B. schrieb: > Aber Andreas mag Geräte, die man jederzeit einfach ausstecken darf. Ich versuche die Anwendung halt so einfach zu möglich für einen Anwender zu machen und investiere etwas Hirnschmalz dazu. Ist das jetzt so falsch? Rainer V. schrieb: > Wenn du bei Stromausfall noch die Arbeit mit der Karte sicher beenden > willst, dann mußt du das wohl mühevoll austesten oder eine gehörige > Pufferzeit einbaun, mit der ganz sicher nicht schief gehen kann. Nein. Du hast auch das doc der SD Association dazu nicht gelesen das weiter oben hier verlinkt und auch kommentiert wurde. Das ist alles wohldefiniert und meine Anfrage dazu ist damit also längst zu meiner Zufriedenheit beantwortet.
Andreas B. schrieb: > Du hast auch das doc der SD Association dazu nicht gelesen das > weiter oben hier verlinkt und auch kommentiert wurde. Das ist alles > wohldefiniert und meine Anfrage dazu ist damit also längst zu meiner > Zufriedenheit beantwortet. Natürlich habe ich die Doc nicht gelesen :-) und das damit deine Fragen beantwortet sind, habe ich wohl überlesen...sorry Rainer
Andreas B. schrieb: > Bauform B. schrieb: >> Aber Andreas mag Geräte, die man jederzeit einfach ausstecken darf. > Ich versuche die Anwendung halt so einfach zu möglich für einen Anwender > zu machen und investiere etwas Hirnschmalz dazu. > Ist das jetzt so falsch? Nein, ganz im Gegenteil, genau so muss es funktionieren! Aber anscheinend versteht das hier kaum jemand :(
Bauform B. schrieb: > Nein, ganz im Gegenteil, genau so muss es funktionieren! Aber > anscheinend versteht das hier kaum jemand :( Quatsch. Wenn man mal die Leute ignoriert, die ignorieren, dass es sich um einen Controller handelt, dann zeigt sich doch, dass man die Karte nicht einfach ziehen kann (wie zu erwarten war) und ich verstehe nicht, dass das nicht signalisiert werden sollte. Sonst reißt dir doch jeder Depp die Karte nach Belieben raus. Andreas B. schrieb: > Ich versuche die Anwendung halt so einfach zu möglich für einen Anwender > zu machen und investiere etwas Hirnschmalz dazu. > Ist das jetzt so falsch? Es ist für mich an der Realität vorbei! Aber es ist ja dein Projekt und wenn du alle Probleme zu deiner Zufriedenheit lösen konntest, um so besser (für dich) Gruß Rainer
Rainer V. schrieb: > Sonst reißt dir doch jeder > Depp die Karte nach Belieben raus. Du hast es immer noch nicht gelesen. Es geht nicht um die Karte rausziehen, sondern um den Logger der an der RS232 hängt von der er auch die Versorgungsspannung bekommt. -> 19.10. 10:21h Rainer V. schrieb: > Es ist für mich an der Realität vorbei! Nö. Wenn man es richtig macht, nicht.
Beitrag #6863782 wurde von einem Moderator gelöscht.
Tut mir leid, wenn ich mich hier verschwendet habe, aber ich kapiers nicht...ok ist nicht euer Problem. Sorry und Gruß, Rainer
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.