Forum: Mikrocontroller und Digitale Elektronik SD Karte shutdown


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Andreas B. (bitverdreher)


Lesenswert?

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?

von Programmierer (Gast)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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.

von Volker Z. (vzavza)


Lesenswert?

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
von Andreas B. (bitverdreher)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

Programmierer schrieb:
> Und dieses etwas muss
> alle Operationen abschließen.
Dieses Etwas ist die Elm chan lib. ;-)

von Programmierer (Gast)


Lesenswert?

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)

von Andreas B. (bitverdreher)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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?

von Andreas B. (bitverdreher)


Lesenswert?

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
von Bauform B. (bauformb)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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?

von Rüdiger B. (rbruns)


Lesenswert?

Dann musst du dir das wohl durchlesen:
https://www.convict.lu/pdf/ProdManualSDCardv1.9.pdf

von Schlaumaier (Gast)


Lesenswert?

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" ).

von Andreas B. (bitverdreher)


Lesenswert?

Rüdiger B. schrieb:
> Dann musst du dir das wohl durchlesen:

Super. Danke!

von Schlaumaier (Gast)


Lesenswert?

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 ;)

von Programmierer (Gast)


Lesenswert?

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...

von Programmierer (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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. ;)

von Programmierer (Gast)


Lesenswert?

Schlaumaier schrieb:
> aber was nicht auf der Platte ist, ist weg bei Stromausfall.

Logisch. Aber was vorher drauf war bleibt konsistent.

von Schlaumaier (Gast)


Lesenswert?

Programmierer schrieb:
> Logisch. Aber was vorher drauf war bleibt konsistent.

Halbroh ist auch nicht gar. ;)

Und was soll ich mit einer halben Datei anfangen ??

von Andreas B. (bitverdreher)


Lesenswert?

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. ;-)

von Programmierer (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Schlaumaier (Gast)


Lesenswert?

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

von Programmierer (Gast)


Lesenswert?

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?

von Andreas B. (bitverdreher)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von Programmierer (Gast)


Lesenswert?

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).

von Andreas B. (bitverdreher)


Lesenswert?

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
von Schlaumaier (Gast)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von Stefan F. (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von michael_ (Gast)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Angehängte Dateien:

Lesenswert?

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.

von michael_ (Gast)


Lesenswert?

Gann bleib bei deinem LINUX!
Was geht mir dort das Gemaunte auf den Sack!

Sogar bei Disketten. Sowas gab es unter WIN noch nie.

von michael_ (Gast)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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.

von michael_ (Gast)


Lesenswert?

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.

von foobar (Gast)


Lesenswert?

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.

von EDLC (Gast)


Lesenswert?

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.

von Norbert (Gast)


Lesenswert?

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?

von Stefan F. (Gast)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Olaf (Gast)


Lesenswert?

> 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

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von Andreas B. (bitverdreher)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

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
von Andreas B. (bitverdreher)


Lesenswert?

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
von Soul E. (Gast)


Lesenswert?

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.

von Norbert (Gast)


Lesenswert?

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?

von Andreas B. (bitverdreher)


Lesenswert?

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.

von Olaf (Gast)


Lesenswert?

> 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

von Andreas B. (bitverdreher)


Lesenswert?

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. ;-)

von M.M.M (Gast)


Lesenswert?

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."

von BLE (Gast)


Lesenswert?

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.

von Nur_ein_Typ (Gast)


Lesenswert?

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?

von Jim M. (turboj)


Lesenswert?

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.

von Olaf (Gast)


Lesenswert?

> 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

von Andreas B. (bitverdreher)


Lesenswert?

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?

von Stefan F. (Gast)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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.

von Stefan F. (Gast)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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/

von Teo D. (teoderix)


Lesenswert?

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!!

von BLE (Gast)


Lesenswert?

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.

von Jim M. (turboj)


Lesenswert?

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.

von Olaf (Gast)


Lesenswert?

> 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

von dummschwaetzer (Gast)


Lesenswert?

>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.

von Rainer V. (a_zip)


Lesenswert?

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

von Teo (Gast)


Lesenswert?

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

von Andreas B. (bitverdreher)


Lesenswert?

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
von Rainer V. (a_zip)


Lesenswert?

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

von Andreas B. (bitverdreher)


Lesenswert?

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)

von BLE (Gast)


Lesenswert?

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.

von Andreas B. (bitverdreher)


Lesenswert?

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.

von Rainer V. (a_zip)


Lesenswert?

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

von Bauform B. (bauformb)


Lesenswert?

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 :(

von Andreas B. (bitverdreher)


Lesenswert?

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.

von Rainer V. (a_zip)


Lesenswert?

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

von Bauform B. (bauformb)


Lesenswert?

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 :(

von Rainer V. (a_zip)


Lesenswert?

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

von Andreas B. (bitverdreher)


Lesenswert?

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.
von Rainer V. (a_zip)


Lesenswert?

Tut mir leid, wenn ich mich hier verschwendet habe, aber ich kapiers 
nicht...ok ist nicht euer Problem. Sorry und Gruß, Rainer

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
Noch kein Account? Hier anmelden.