SD-Card FAT16 Schreibproblem bei vollen Clustern

Nimm FATfs, das funktioniert sehr gut.

@ Peter (Gast)

>Leider habe ich die lib schon vor zwei Jahren implementiert und bin sehr
>zufrieden. Nur nun wird die Datei in die geschrieben wird so groß dass
>es zum Problem kommt. Jeder Datensatz ist 107 Byte lang daher kommt das
>roblem jetzt bei 32768 Sätzen. Der nächste kann nicht geschrieben
>werden.

Vielleicht liegt der Fehler nicht in der FAT Lib sondern bei deiner 
anderen Software?

Peter schrieb:
> Jeder Datensatz ist 107 Byte lang daher kommt das
> Problem jetzt bei 32768 Sätzen. Der nächste kann nicht geschrieben
> werden.

Bei genau 32768*107 Bytes? Du hast eher einen (16-Bit) Integer Überlauf 
im Code, eine "int" Zählvariable kann nur 32767 Sätze addressieren.

Anders ausgedrückt: Zeig uns Deinen Code.

@ Peter (Gast)

>diesen nicht Sinnlos zu blockieren. Das habe ich nun entfernt und fülle
>den neuen Cluster mit Nullen

Was soll der Unsinn?

>und hänge diesen an die Datei an.

Das schon eher.

@Peter (Gast)

>Das Beschreiben mit Hex 0X00 ist kein Unsinn

Aber sicher. Denn der Inhalt von Sektoren/Clustern JENSEITS der 
Dateilänge ist undefiniert. Und er spielt auch keine Rolle, weil man 
dort über solide FAT Libs so oder so NICHT rankommt.

>sondern laut SD-Card Tutorial empfohlen

Welches denn? Mal ganz abgesehen davon, daß du damit deine Sektoren 
doppelt beschreibst bzw. löschst. Das halbiert die statistische 
Lebensdauer und kostet DOPPELTE Schreibzeit, sprich, deine effektive 
Schreibgeschwindigkeit halbiert sich. Prost Mahlzeit!

Der schnellste und PREISWERTESTE Weg etwas zu tun, ist es gleich richtig 
zu tun. Andere Libs können das auch.

>Wenn ein Cluster gerade voll ist wird ein neuer Angefangen.

Das scheint mir falsch zu sein. Ein neuer Cluster wird IMO nur angelegt, 
wenn mindestens 1 Byte geschrieben werden muss. Sprich, wenn beim 
Schreibvorgang ein Sektor voll ist, aber noch Restdaten vorhanden sind 
und diese einen neuen Sektor im neuen Cluster erfordern. Wenn aber das 
letzte Byte eines Schreibzugriffs im letzten Bytes das aktuellen 
Clusters beim Schreiben Platz hat, wirdn nur dieser Sektor geschrieben, 
DANACH muss vorerst kein neuer Cluster angefordert werden! Erst beim 
nächsten Schreibzugriff.

>im Prinzip ist das so

Aber halt nicht im Detail in der Praxis.

>ja nur leider greift die Karte bzw. Lib dann
>daneben.

Deine Lib. Die Karte macht es schon richtig.

>Aus dem Grund hänge ich direkt den nächsten Cluster ran.

Ist auch nur ein Workaround. Damit verschwendet jede Datei mindestens 
einen ganzen Cluster, je nach Länge.

Der schnellste und PREISWERTESTE Weg etwas zu tun, ist es gleich richtig
zu tun. Andere Libs können das auch.

Suche und behebe den Fehler. Es wird dir nicht schaden, im Gegenteil!

Peter schrieb:
> Das Problem ist gefunden.
> Wenn ein Cluster gerade voll ist wird ein neuer Angefangen. Wenn jedoch
> dann keine Daten zu schreiben sind wurde der neue Cluster verworfen um
> diesen nicht Sinnlos zu blockieren. Das habe ich nun entfernt und fülle
> den neuen Cluster mit Nullen und hänge diesen an die Datei an. Somit
> weiß die SD nun beim nächsten beschreiben wo es weiter geht.

 Das ist kein Problem, das ist ein Fehler in der Lib.

 Ein neuer Cluster wird nur dann angefangen, wenn der vorherige voll ist
 und noch weitere Daten anstehen, sonst nicht.
 Besetzte Cluster werden als solche in der FAT vermerkt, somit braucht
 eine Datei mit Cluster + 1Byt Länge 2 Cluster.
 Aber die genaue Dateilänge wird im DIR-Eintrag reingeschrieben, somit
 ist deine Behauptung das irgendwelche Cluster angehängt und dann
 verworfen werden müssen, doch Blödsinn.
 Ein Cluster wird entweder angefangen oder nicht.
 Bereitgestellt weil der vorherige voll ist - das gibt es bestimmt
 nicht.