Forum: Mikrocontroller und Digitale Elektronik fatfs schreib buffer notwendig?


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 Paul G. (paul_g210) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Marco H. (damarco)


Bewertung
-1 lesenswert
nicht lesenswert
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...

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
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

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
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
von Paul G. (paul_g210) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Paul G. (paul_g210) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Sascha W. (sascha-w)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Falk B. (falk)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
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.

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Marco H. (damarco)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.