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.
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?
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".
Joa, ist halt nicht alles Gold, was glänzt, nich? :-) Ich weiß ja nichtmal, auf welcher Plattform wir uns grad befinden...
Sven P. schrieb:
> Ich weiß ja nichtmal, auf welcher Plattform wir uns grad befinden...
Atmega ist ja wohl eindeutig genug, oder?
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...
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.
Karl heinz Buchegger schrieb:
> Wie behandelt man den Fall, dass exakt während des Schreibens der Strom weg ist?
Mit einer USV :-)
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.
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.
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.
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 :-)
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.
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...
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... :-)
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.)
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?
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.
>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
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.
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.
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''.
> ein Idiot hat die Kiste aufgeschraubt und mit Lötzinn ausgegossen
Wobei das von genialer destruktiver Kreativität zeugen würde :D
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.
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.
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
... wenn nicht das komplette FAT-System zerschossen ist.
Es gibt übrigens auch Journaling File Systems, die sind ausfallsicher, soweit ich weiß.
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.