mikrocontroller.net

Forum: Compiler & IDEs Fileoperation: in Zeile zurück springen


Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe folgendes Problem. Ich erstelle mit einem Atmega eine 
Log-Datei. Am Ende der Datei muss immer "end" stehen. Jedes Log-Event 
bekommt eine Zeile und nach dem Ende des Loggens wird dann in die letzte 
Zeile "end" geschrieben. Soweit geht das alles. Probleme treten jetzt 
auf, wenn zum Beispiel das Loggen plötzlich durch Stromausfall beendet 
wird. Meine Idee ist, nach jeder Log-Zeile "end" in die nächste Zeile 
einzutragen und dann beim nächsten Log eine Zeile zurückspringen oder 
einfach das "end" löschen. Beides hab ich bis jetzt noch nicht 
hinbekommen. Alle Versuche endeten mit Datenmüll in der log-Datei. 
Vieleicht hat ja von euch einer eine gute Idee.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Log-Datei?
Hast du eine Festplatte angeschlossen?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
POSIX hält für diese Fälle die Funktionen
- fgetpos() und fsetpos() sowie
- ftell() und fseek()
bereit. Muss man halt zuerst die aktuelle Position ermitteln, dann das 
'end' schreiben und danach zurückhüpfen.

Hast du das mit dem 'end' selbst festgelegt? Wenn ja: Warum reicht das 
tatsächliche Dateiende denn nicht?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:
> POSIX hält für diese Fälle die Funktionen
> - fgetpos() und fsetpos() sowie
> - ftell() und fseek()
> bereit.

Da der OP ja irgendwo her die Implementierung eines Dateisystems
haben muss, muss er wohl in dessen API nachsehen, ob's was
vergleichbares gibt.

> Hast du das mit dem 'end' selbst festgelegt? Wenn ja: Warum reicht das
> tatsächliche Dateiende denn nicht?

In etwas verschärfter Form hat man das gleiche Problem (das man dort
nicht ,,wegdefinieren'' kann), wenn man in XML-Dateien loggt.  Der
Garmin beispielsweise scheint eine Vorgehensweise wie die genannte
implementiert zu haben: egal, wie das Teil außer Betrieb geht, die
Logdatei ist immer "well-formed XML".

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joa, ist halt nicht alles Gold, was glänzt, nich? :-)

Ich weiß ja nichtmal, auf welcher Plattform wir uns grad befinden...

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven P. schrieb:

> Ich weiß ja nichtmal, auf welcher Plattform wir uns grad befinden...

Atmega ist ja wohl eindeutig genug, oder?

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja schon, gehört aber bissl mehr dazu. Ich meine: SD-Karte? Fetplatte? 
Was gibts denn überhaupt schon? Und wenn er in 'Dateien protokolliert', 
kanns schonmal nicht mehr der ATMega alleine sein...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:

> In etwas verschärfter Form hat man das gleiche Problem (das man dort
> nicht ,,wegdefinieren'' kann), wenn man in XML-Dateien loggt.  Der
> Garmin beispielsweise scheint eine Vorgehensweise wie die genannte
> implementiert zu haben: egal, wie das Teil außer Betrieb geht, die
> Logdatei ist immer "well-formed XML".

Wobei sowas gar nicht so simpel zu implementieren ist wenn es unter 
allen denkbaren Umständen funktionieren soll. Wie behandelt man den 
Fall, dass exakt während des Schreibens der Strom weg ist?
Die einfachste Variante die ich kenne ist: Man hat 2 Dateien in die 
abwechselnd geschrieben wird. Erst dann, wenn der Schreibvorgang 
komplett abgeschlossen ist, wird diese zum Master erklärt und der 
nächste Schreibvorgang landet in der anderen.
Und selbst da ist der Umschaltzeitpunkt immer noch der Knackpunkt im 
Dateisystem. Aber zumindest existiert immer mindestens 1 well-formed 
File.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Wie behandelt man den Fall, dass exakt während des Schreibens der Strom weg ist?

Mit einer USV :-)

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Log-Datei befindet sich auf einer SD-Karte. Das "end" muss da 
stehen, da die Datei nachher am PC mit einem externen Programm behandelt 
wird, auf das ich leider keinen Einfluss habe.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne es ausprobiert zu haben:

1.) File Pointer auf das "e" vom end stellen (z.B. Pointer auf das 
Dateiende und dann die entsprechende Anzahl an Positionen 
dekrementieren)
2.) Wert in die Zeile schreiben (wobei das "end" dabei vollständig 
überschrieben werden sollte)
3.) Newline schreiben
4.) "end" schreiben
5.) EOF-Kennung für das Dateiende schreiben.

Gibt natürlich immer noch Müll, wenn während des Zugriffs auf die 
SD-Karte die Spannung ausfällt. Wirklich verhindern kann man das meiner 
Meinung nach nur durch eine alternative Spannungsquelle bei Ausfall der 
primären, also nichts anderes als eine USV.

Ach so, ja:
Auf dem PC kann man natürlich auch ein Progrämmchen schreiben, das die 
Log-Datei einliest und bei Fehlen der "end"-Kennung diese nachträglich 
hinzufügt.

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark Brandis schrieb:
> Karl heinz Buchegger schrieb:
>> Wie behandelt man den Fall, dass exakt während des Schreibens der Strom weg 
ist?
>
> Mit einer USV :-)

Ich habe kürzlich bei einem Logging-System das Stromausfallproblem 
dadurch gelöst, daß ich ein 24V-Netzteil mit großem Elko (10.000uF) 
eingebaut habe, dessen Spannung mit einem Schaltregler auf 5V gebracht 
wird; vor dem Gleichrichter habe ich die Wechselspannung mittels Diode 
separat abgezweigt und auf einen kleinen Elko gegeben, mit kurzer 
Zeitkonstante; dieser führt zu einem Komparator, der mir einen 
Power-Down-Interrupt liefert. Dann hat das Prozesorsystem 3-4 Sekunden 
Zeit, alles schön abzuschließen.

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
vielen dank für die Hinweise. Die Idee mit dem kleinen Programm was auf 
dem PC die Datei mit "end" versieht, hatte ich natürlich auch, aber 
irgendwie halte ich das für eine Schumellösung :-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan schrieb:

> Die Log-Datei befindet sich auf einer SD-Karte.

Damit bist du uns immer noch die Antwort schuldig, mit welcher Software
du auf die SD-Karte schreibst.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wer nicht will...

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Jan schrieb:
>
>> Die Log-Datei befindet sich auf einer SD-Karte.
>
> Damit bist du uns immer noch die Antwort schuldig, mit welcher Software
> du auf die SD-Karte schreibst.

Die Software freilich will ich sehn, der Spannungsausfälle nichts 
anhaben können...

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
U_B++;

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann erklär doch mal, was für einen Unterschied es macht wie die 
SD-Karte beschrieben wird. Wenn während des Schreibvorgangs die Spannung 
ausfällt und es weder eine USV noch eine Schaltung mit einem großen 
Kondensator gibt (wie oben beschrieben) die ein geordnetes 
Herunterfahren ermöglicht, wird es immer das Problem einer 
unvollständigen Log-Datei geben. Da ist es ganz schön egal wie die 
Funktion oder Bibliothek oder Schnittstelle oder Schlagmichtot zur 
SD-Karte heißt.

Ah ja, noch ne Idee: Man könnte den µC so programmieren, dass er vor 
Beginn des Logvorgangs die Datei auf der SD-Karte auf Konsistenz prüft 
und ggf. ein fehlendes "end" am Ende einfügt und ggf. die letzte zuvor 
unvollständig geschriebene Zeile löscht. Das funktioniert prima. Bis zum 
nächsten Spannungsausfall. Ich glaube, wir drehen uns im Kreis... :-)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Originalfrage war doch, wie man etwas schreibt (end), dann wieder
zurückgeht und das end überschreibt.
Das hat schon irgendwie mit der verwendeten Bibliothek zu tun, denke 
ich.

Er hatte nicht nach einer prinzipiellen Strategie gefragt, wie man
so etwas lösen könnte, sondern wollte wissen, wie er seine Idee
umsetzen kann.
Trotzdem verrät er nicht, womit er arbeitet.

(Abgesehen davon, dass eine Speicherkarte mit FAT m.E. für so
etwas maximal unglücklich gewählt ist, aber danach fragt ja auch
keiner.)

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> Er hatte nicht nach einer prinzipiellen Strategie gefragt, wie man
> so etwas lösen könnte, sondern wollte wissen, wie er seine Idee
> umsetzen kann.
> Trotzdem verrät er nicht, womit er arbeitet.

Ja gut, Themenersteller und fehlende Angaben... das gibt es hier 
gaaaaaanz selten... man ist es beinahe schon nicht anders gewohnt.

> (Abgesehen davon, dass eine Speicherkarte mit FAT m.E. für so
> etwas maximal unglücklich gewählt ist, aber danach fragt ja auch
> keiner.)

Dann frag ich jetzt mal. Welches Medium/Dateisystem wäre denn besser 
geeignet?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan schrieb:
> vielen dank für die Hinweise. Die Idee mit dem kleinen Programm was auf
> dem PC die Datei mit "end" versieht, hatte ich natürlich auch, aber
> irgendwie halte ich das für eine Schumellösung :-)

Eigentlich nicht.
Im Endeffekt wird dir gar nichts anderes übrig bleiben, als das genau so 
zu machen.

Das Einleseprogramm muss prinzipiell mit einem korrpten Log-File 
klarkommen. Da du darauf keinen Einfluss hast, bleibt dir nichts anderes 
übrig, als das mit einem Vorsatzprogramm zu erledigen. Der Aufwand auf 
dem µC sicherzustellen, das das Log-File immer und in allen Fällen 
korrekt ist, ist so dermassen hoch, dass sich das einfach nicht lohnt. 
Du kannst einen Stromausfall nicht vorhersagen und du hast auch keine 
Chance: Wenn der Strom weg ist, ist er weg und dein LogFile hat eine 
gute Chance korrupt zu sein. Wenn dein Benutzer just in diesem 
Stromlosen Moment die SD-Karte abzieht um am PC im Log nachzusehen, ob 
sich dort etwas über den Grund des Ausfalls findet, hat dein PC-Programm 
ein Problem.

Autor: Michael W. (retikulum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Du kannst einen Stromausfall nicht vorhersagen und du hast auch keine
>Chance: Wenn der Strom weg ist, ist er weg und dein LogFile hat eine
>gute Chance korrupt zu sein.

Selbstverständlich kann man einen Stromausfall nicht vorhersagen. Aber 
hier geistern 1001 Schaltungen herum, wie bei Dimmer eine 
Nullpunkterkennung gemacht wird. Dann bekommt man alle 10 ms einen 
Interrupt. Sollte er nach 12 ms nicht kommen, Daten speichern und ende.

Michael

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:

> Das Einleseprogramm muss prinzipiell mit einem korrpten Log-File
> klarkommen. Da du darauf keinen Einfluss hast, bleibt dir nichts anderes
> übrig, als das mit einem Vorsatzprogramm zu erledigen.

Falls eine Speicherkarte mit FAT Dateisystem verwendet wird, dann dürfte 
das fehlende end das kleinste Problem sein. Wenn man die Dateifragmente 
per Hexeditor zusammensucht, da die FAT Tabelle nicht aktualisiert wurde 
kann man das end gleich mit einfügen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael W. schrieb:
>>Du kannst einen Stromausfall nicht vorhersagen und du hast auch keine
>>Chance: Wenn der Strom weg ist, ist er weg und dein LogFile hat eine
>>gute Chance korrupt zu sein.
>
> Selbstverständlich kann man einen Stromausfall nicht vorhersagen. Aber
> hier geistern 1001 Schaltungen herum, wie bei Dimmer eine
> Nullpunkterkennung gemacht wird. Dann bekommt man alle 10 ms einen
> Interrupt. Sollte er nach 12 ms nicht kommen, Daten speichern und ende.

Schön.
Was machst du bei einem Kurzschluß?

Ich steh immer noch dazu: Ein Auswerteprogramm eines Log-Files muss mit 
allen Log-Files klar kommen, nicht nur wohlgeformten.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:

> Was machst du bei einem Kurzschluß?

Denjenigen erschlagen, der den Kurzschluss produziert hat. :.)

Im Ernst: gegen alle Eventualitäten einschließlich eines EMP bist
du sowieso nicht gewappnet.  Es genügt (in der Regel, also außerhalb
besonders sicherheitskritischer Anwendungen), wenn du gegen alle im
gewöhnlichen Betrieb vorhersagbaren Fälle Vorkehrungen getroffen
hast.  Dazu gehört bei einem batteriebetriebenen Gerät der Zustand
,,Batterie verbraucht'' oder bei einem netzbetriebenen Gerät der
Zustand ,,Netzausfall'', nicht jedoch der Zustand ,,ein Idiot hat
die Kiste aufgeschraubt und mit Lötzinn ausgegossen''.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ein Idiot hat die Kiste aufgeschraubt und mit Lötzinn ausgegossen

Wobei das von genialer destruktiver Kreativität zeugen würde :D

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark Brandis schrieb:
> Klaus Wachtler schrieb:
> ...
>> (Abgesehen davon, dass eine Speicherkarte mit FAT m.E. für so
>> etwas maximal unglücklich gewählt ist, aber danach fragt ja auch
>> keiner.)
>
> Dann frag ich jetzt mal. Welches Medium/Dateisystem wäre denn besser
> geeignet?

Eine Möglichkeit:

Flash hat ja im Originalzustand lauter Einsen bzw. kann durch Löschen
dahin gebracht werden (sektorweise).
Jetzt kann man sich seinen Flashspeicher in 2 Bereiche unterteilen:
Für die eigentlichen Daten definiert man sich in Gedanken eine Folge
von Sektoren, die immer komplett frei sind oder gültig.
In einem kleineren Teil hält man eine Bitmap, in der jedes Bit
anzeigt, ob genau einer der Datenblöcke frei ist (1) oder schon
beschrieben und gültig (0).
Zu Beginn werden alle Sektoren gelöscht (1), die Datensektoren
gelten damit als frei.
Um etwas zu schreiben, löscht man erst den nächsten freien
Datenblock (zu 1), schreibt dann und ändert erst danach sein
Bit in der Bitmap von 1 zu 0.
Egal, wann der Strom ausfällt, hat man immer über die Bitmap
die Info, wieweit man lesen kann. Die Bitmap hat immer den alten
oder den neuen Zustand und keinen dazwischen.
Es geht im Zweifelsfall der eine Sektor verloren, bei dessen
Ausgabe gerade der Strom weg war.

Hat nur nicht viel mit FAT zu tun, klar.
Auf der PC-Seite muß man mit einem Programm dann sektorweise
auf die Karte zugreifen und den Aufbau mit Bitmap und Datenbereich
kennen.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das geht sogar noch einfacher wenn man ausschließen kann, dass mehrere 
Werte hintereinander 0xFF haben:
Dann sucht man einfach solange bis 0xFF im Speicher stehen und hat das 
Ende der Daten gefunden.
Ansonsten hat man wieder das Problem, wenn zwischen dem Schreiben der 
Daten und dem der Belegt-Tabelle die Spannung ausfällt.

Autor: Michael W. (retikulum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit drei redundante Tabellen gehts. Wenn immer Tabelle eins, zwei drei 
(sitzen machen) geschrieben wird, hat bei korrupter Tabelle eins die 
zwei anderen die letzten Messwerte. Bei beschädigter Tabelle zwei hat 
eins die neuen und drei die alten Daten. Bei korrupter Tabelle drei 
haben eins und zwei die aktuellen Daten. Richtig?

Michael

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... wenn nicht das komplette FAT-System zerschossen ist.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt übrigens auch Journaling File Systems, die sind ausfallsicher, 
soweit ich weiß.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber eher nicht an einem AVR auf einer SD-Karte?

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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