Hi Meine DIY elektronische Last/Logger Projekt nähert sich dem Ende und mein STM32G071 kommuniziert erfolgreich via SPI mit der SD Karte. Ich bin nun an dem Punkt die Daten des Loggers aller 1 bis 10 Sekunden auf die SD Karte mit "f_puts()" zu schreiben. Weniger als eine Sekunde wird nicht nötig sein. Die "Daten" ist einfach nur ein float Wert (z.Bsp. 2.352) pro Zeile als reiner Text. Muss ich das ganze irgendwie buffern? Oder kümmert sich fatfs komplett darum und ich kann einfach meine f_puts() hintereinander laufen lassen bis der Logger fertig ist und dann schließe ich die Datei einfach und unmounte die Karte? Ich habe gelesen das es bei größeren Datenmengen sinnvoll wäre das ganze als vielfaches von 512B zu buffern um effektiv auf die Karte zu schreiben. Aber ich verstehe noch nicht wirklich wie fatfs das intern Handhabt.
Dem FAT Dateisystem ist es Wurst, interessant ist die Implementierung von dessen. Denn da liegt noch eine Menge dazwischen... Welche Bibliotheken benutzt denn? Dort ist auch die Antwort auf deine Frage zu suchen. Dir schon klar das die SD-Karte keine große Lebenserwartung hat...
Paul G. schrieb: > Muss ich das ganze irgendwie buffern? Nicht unbedingt. > Oder kümmert sich fatfs komplett > darum und ich kann einfach meine f_puts() hintereinander laufen lassen > bis der Logger fertig ist und dann schließe ich die Datei einfach und > unmounte die Karte? In Prinzip ja. FatFS nutzt einen 512 Byte Puffer, wenn man den nicht explizit deaktiviert (Header-Datei). Wie bei allen SD-Karten kann es beim Schreibzugriff zu Wartezeiten von um die 0,1-0,3s kommen. Wenn deine Anwendung während dieser Zeit UNBEDINGT verzögerungsfrei und gleichmäßig Daten erfassen will, muss man diese in einem FIFO zwischenspeichern. Dieser FIFO muss dann über einen Interrupt gefüllt werden, denn nur dort kann ein Wartezustand beim Zugriff auf die SD-Karte unterbrochen werden. Sprich: Timerinterrupt erfaßt Daten und schreibt sie in den FIFO Periodische Funktion in der Hauptschleife prüft FIFO-Inhalt und schreib diesen auf SD-Karte
Marco H. schrieb: > Denn da liegt noch eine Menge dazwischen... Welche > Bibliotheken benutzt denn? Dort ist auch die Antwort auf deine Frage zu > suchen. Anfrage gelesen? Fatfs ist das hier, vom Meister Chan aus dem fernen Osten. http://elm-chan.org/fsw/ff/00index_e.html >Dir schon klar das die SD-Karte keine große Lebenserwartung hat... Was soll der Unsinn? Schon mal ausgerechnet, wie lange ein Mikrocontroller Daten auf eine SD-Karte schreiben muss, damit diese ihre elektrische Lebensdauer erreicht (=maximale Anzahl von Schreibzyklen auf dem Flashspeicher).
:
Bearbeitet durch User
Marco H. schrieb: > interessant ist die Implementierung von dessen. Wie ich schon schrieb "FatFs" von elm-chan. Die SPI Umsetzung geschiet über Code von diesem Herrn: https://blog.naver.com/eziya76/221188701172 gezeigt in diesem Video: https://www.youtube.com/watch?v=spVIZO-jbxE > Dir schon klar das die SD-Karte keine große Lebenserwartung hat... Hmm, also sämtliche SD Karten die ich in den letzten 5 Jahren gekauft habe leben noch alle... Es ist ja nicht so das ich 365 Tage lang permanent Daten auf die Karte schreiben will.. es geht hier maximal um 1-2 Tage.
Paul G. schrieb: > Wie ich schon schrieb "FatFs" von elm-chan. > Die SPI Umsetzung geschiet über Code von diesem Herrn: > https://blog.naver.com/eziya76/221188701172 > gezeigt in diesem Video: > https://www.youtube.com/watch?v=spVIZO-jbxE Häää? Gibt es jetzt schon VIDEOs um zu zeigen, wie ein Stück Code funktioniert? OMG!
Falk B. schrieb: > kann es beim Schreibzugriff zu Wartezeiten von um die 0,1-0,3s kommen. Was passiert wenn es doch mal länger dauert? Hätte ich dann einfach nur eine Ungenauigkeit im Intervall meiner Messpunkte? Wenn ich 24-48 Stunden logge dann wären mir 5 Minuten jitter in den Daten eigentlich egal... Dann könnte ich mir das ganze FIFO zeug sparen. Oder ich beiß in den sauren Apfel und muss den FIFO doch mal versuchen umzusetzten :D
> Häää? Gibt es jetzt schon VIDEOs um zu zeigen, wie ein Stück Code > funktioniert? OMG! Sei froh das es noch nicht getwittert wird. Olaf
Paul G. schrieb: > Ich habe gelesen das es bei größeren Datenmengen sinnvoll wäre das ganze > als vielfaches von 512B zu buffern um effektiv auf die Karte zu > schreiben. > > Aber ich verstehe noch nicht wirklich wie fatfs das intern Handhabt. die Karte ist hardwaremäßig in Blöcken zu 512 Byte organisiert. Wenn du innerhalb eines Blocks 1 Byte änderst werden von der Lib 512 Byte gelesen, dann das/die Byte[s] im Puffer geändert und der Block mit 512 Byte wieder zurückgeschrieben. Bei kleinen Datenmengen (wie bei Dir ca. 6Byte) ist das natürlich wenig effizient. Bei 6Byte würde also ein Block 85mal gelesen und geschrieben bis er voll ist - das senkt auf Dauer natürlich die Lebensdauer - ob für deine Anwendung relevant weiß ich nicht. Inwiefern die Lib dafür sorgt/sorgen kann das solange die Datei offen ist die Änderungen erst mal nur im Puffer der Lib gemacht werden hab ich mir nicht angesehen. Sascha
Paul G. schrieb: > Falk B. schrieb: > >> kann es beim Schreibzugriff zu Wartezeiten von um die 0,1-0,3s kommen. > Was passiert wenn es doch mal länger dauert? Das ist praktisch auszuschließen. Wenn du eine SEHR schlechte Karte hat, dann geht das vielleicht ab und an auf 0,5-1s hoch, aber das ist so selten wie ein 6er im Lotto. > Hätte ich dann einfach nur > eine Ungenauigkeit im Intervall meiner Messpunkte? Wenn ich 24-48 > Stunden logge dann wären mir 5 Minuten jitter in den Daten eigentlich > egal... Dann brauchtst du keinen FIFO.
Sascha W. schrieb: >> Aber ich verstehe noch nicht wirklich wie fatfs das intern Handhabt. > die Karte ist hardwaremäßig in Blöcken zu 512 Byte organisiert. Wenn du > innerhalb eines Blocks 1 Byte änderst werden von der Lib 512 Byte > gelesen, dann das/die Byte[s] im Puffer geändert und der Block mit 512 > Byte wieder zurückgeschrieben. Nö. Das passiert bestenfalls bei Petitfs ohne Sektorpuffer. Sowas macht man aber nur, wenn es denn WIRKLICH sein muss und man keine 512 Bytes übrig hat.
Paul G. schrieb: >> kann es beim Schreibzugriff zu Wartezeiten von um die 0,1-0,3s kommen. > Was passiert wenn es doch mal länger dauert? Dann ist der Schreibvorgang etwas später fertig als sonst. Passiert selten, aber passiert - SD-Karten machen keine harte Echtzeit. > Hätte ich dann einfach nur eine Ungenauigkeit im Intervall > meiner Messpunkte? Wenn ich 24-48 Stunden logge dann wären > mir 5 Minuten jitter in den Daten eigentlich egal... Wenn du im Hintergrund (z.B. per Timer-Interrupt) misst, dann passiert eigentlich nichts. Ein bisschen Jitter bekommst du, wenn du in einer gemeinsamen Schleife abwechselnd schreibst und misst. Das kannst du aber auch rausrechnen, wenn du Timestamps mit abspeicherst. Ist sowieso zu empfehlen. > Dann könnte ich mir das ganze FIFO zeug sparen. Kannst du.
Es gibt hier auch wieder mehrere Levels. Die ebene das FAT System und eine I/O ebene. Beide haben Buffer. f_write() löst nicht unmittelbar eine Aktion auf der SD-Karte aus. Es sei denn man löst es explizit mit f_sync aus. In der I/O Ebenen wird dann entschieden wann auf die Hardware geschienen wird. Ohne Sync()besteht bis zum close() das die Daten futsch sind. Es kann durchaus passieren das es lange dauert bis die I/O Ebene die Daten wirklich schreibt wenn du nur ein paar Bytes schreibst. Das auch noch auf dem selben Block, das kann die I/O Ebene sogar veranlassen sie erst garnicht zu schreiben bis der Block voll ist. A: du machst dir keine Gedanken und baust auf die Lib.. B: Du füllst selbst einen Buffer und schreibst diesen auf der SD weg und machst den sync() an geeigneter stelle -> zwischen der Messung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.