Hallo Leute, betreibe eine SD-Karte am Atmega64 per Hardware-SPI, funktioniert auch soweit problemlos. Als Lib wurde dafür AVR FAT32 von dieser Seite genutzt. Allerdings habe ich das Problem, wenn eine Datei erstellt wird auf der SD-Karte, keine Daten hineingeschrieben wurden diese unter Windows nicht gelesen werden kann (Datei beschädigt etc...). Mitunter kommt es auch zu einem Bluescreen mit Fehler in der fastfat.sys! Komischerweise wenn man mit Windows eine Datei erstellt und nichts reinschreibt und mit einem Hex-Editor mit der Datei vergleich die der Mikrocontroller reingeschrieben hat, ergibt es keine unterschiede. Das lässt mich zu der Annahme kommen, dass die Nutzdaten der Dateien gleich sind. Ein unterschied muss dann wohl in den Dateiheader sein. Kennt jemand dieses Problem?
SD finde ich OK schrieb: > Das lässt mich zu der > Annahme kommen, dass die Nutzdaten der Dateien gleich sind. eine Leere Datei hat keien Nutzdaten? Was willst du da vergleichen? Du hast ein defekte Dateisystem, also arbeitet die lib fehlerhaft oder du benutzt sie falsch.
Außderdem kann die "beschädigte" Datei auch nicht über das normale Windows löschen gelöscht werden. Diese Verschwindet dann kurz, aktualisiert man den Inhalt des Fensters taucht diese dann aber wieder auf. Sie kann nur über ein komplettes Formatieren der SD-Karte entfernt werden.
SD finde ich OK schrieb: > Außderdem kann die "beschädigte" Datei auch nicht über das normale > Windows löschen gelöscht werden. ist doch klar, weil das Dateisystem nicht sauber ist. Da kann alles mögliche passieren. Du kannst mal chkdsk drüber laufen lassen, aber eine lösung ist das auch nicht.
Peter II schrieb: > eine Leere Datei hat keien Nutzdaten? Was willst du da vergleichen? Ja ist mir bewusst. > Du hast ein defekte Dateisystem, also arbeitet die lib fehlerhaft oder > > du benutzt sie falsch. Ja vllt. aber eig. nutze ich nur die Funktionen die in der file.c bereitgestellt werden. Also könnte es sich vllt. um einen Fehler in der Dateizuordnungstabelle handeln (FAT)? Weiterhin nutze ich auch die Möglichkeit ein Datum/Uhrzeit in den Dateiheader zu schreiben über die in der Library dafür zur verfügung gestellten Funktionen. Die Uhrzeit/Datum bekomme ich von einer RTC.
Peter II schrieb: > Du kannst mal chkdsk drüber laufen lassen, aber eine > > lösung ist das auch nicht.Beitrag melden Bearbeiten Löschen Ja hab ich mal gemacht, chkdsk löscht dann die korrupierte Datei. Wie lässt sich den eingrenzen wo der Fehler liegen könnte?
Was hat den FAT für Begrenzungen hinsichtlich der Dateinamenlänge? Könnte das möglicherweise ein Problem sein?
so kompliziert ist die FAT nicht. Dann musst sie halt wirklihc mal jedes byte analysieren und schauen wo der fehler ist.
>Was hat den FAT für Begrenzungen hinsichtlich der Dateinamenlänge?
ca. 260 Zeichen glaub ich.
Schau mal nach ob im Directory ein Cluster eingetragen ist.
Windows legt leere Dateien ohne Clustereintrag an, bzw.
reserviert keinen Cluster in der FAT.
Hmm, fehler besteht immer noch. Bin jetzt mal mit chkdsk in der Konsole durchgegangen. Fehlermeldung lautet: dateiname.txt Erste Zuordnungseinheit ist ungültig. Der Eintrag wird abgeschnitten.
Hast du Karte einfach so vom Atmega getrennt? Ich glaube, soetwas muss demountet werden, sonst kommt es zu solchen Problemen.
ja, habe ich allerdings wenn ich die Datei mit fclose schließe die ich erzeugt habe tritt der fehler auch auf. Erst wenn ich die Datei öffne und daten in diese schreibe ist diese fehlerfrei.
Woher weiß ich den wo ersten die FAT anfängt und zweitens wo meine Nutzdaten beginnen.
SD finde ich OK schrieb: > Woher weiß ich den wo ersten die FAT anfängt und zweitens wo meine > Nutzdaten beginnen. Hier AVR FAT32 findest du eine kleine Übersicht, wie das ganze Filesystem eigentlich funktioniert. Wobei man klären müsste, welches eigentlich die richtige Vorgehensweise bei einer Datei mit Länge 0 ist: Ist im Directory ein Startcluster eingetragen oder nicht. Da wohl die wenigsten eine leere Datei erzeugen, wird das wohl noch nie jemandem aufgefallen sein, dass es da ein 'Problem' gibt.
Vllt. hat ja jemand die Library AVR FAT32 im einsatz und könnte es mal testen, ob eine datei erzeugen mittels fopen() mit anschließenden fclose() ohne schreiben von nutzdaten zu einer beschädigten datei führt.
Ich vermute, dass soetwas von der Library einfach nicht vorgesehen ist. Versuch doch wenigstens mal, zwischen open und close einen leeren write-Aufruf oder ein seek zu machen.
ja sobald ich einen write aufruf nach dem fopen durchführe ist die datei nicht beschädigt. Scheint wohl doch ein fehler in der Library zu sein und nicht an mir zu liegen.
SD finde ich OK schrieb: > Scheint wohl doch ein fehler in der Library zu sein > und nicht an mir zu liegen. It's not a bug. It's a feature.
Ja, gut mach ja eigentlich auch keinen Sinn eine Datei zu öffnen respektive anzulegen und dann nicht rein schreiben. Hatte mich nur gewundert unter Windows geht es ja, eine Datei anlegen die keine Nutzdaten enthält, hat aber wohl der Ersteller der Library nicht dran gedacht.
Karl Heinz Buchegger schrieb: > Wobei man klären müsste, welches eigentlich die richtige Vorgehensweise > bei einer Datei mit Länge 0 ist: Ist im Directory ein Startcluster > eingetragen oder nicht. Es wird kein Speicherplatz belegt. Erst, wenn Du ein Byte reinschreibst, hast Du 2kB weniger auf der Festplatte frei. Ich hatte früher mal ein leere Datei angelegt für meine Routine zur Zeitumstellung, die hieß "Sommer" oder "Winter", damit sie weiß, ob schon vor- oder zurückgestellt wurde. Früher hatte man kein DSL und die PCs wurden nachts noch richtig ausgeschaltet. Peter
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.