SD-Card FAT16 Schreibproblem bei vollen Clustern

[Peter (Gast)]

Hallo,

im Thread 
Beitrag "Re: MMC SD library FAT16 FAT32 read write"
wurde erwähnt, dass es bei der behandelten SD-Karten Lib ein Problem 
gibt beim schreiben auf die SD-Karte wenn gerade vorher ein Cluster voll 
ist. Das Problem habe ich jetzt auch. Ist der Cluster voll so kann ich 
zwar lesen und auch wenn ich am PC die karte weiter beschreibe (denn 
vollen Cluster praktisch überspringe) kann ich über MCU auch wieder 
weiter schreiben. Nur wenn man mit der MCU direkt nach einem vollen 
Cluster schreiben möchte klappt es nicht.

Hat irgendjemand dieses Problem gelöst? Leider wurde der Thread nicht 
mehr gepflegt und ist etwas in Vergessenheit geraten.

[Falk B. (falk)]

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 
Problem jetzt bei 32768 Sätzen. Der nächste kann nicht geschrieben 
werden.

[Peter (Gast)]

Habe folgende Code im oberen genannten Thread gelesen welcher wohl 
zunächst erfolg brachte dann aber wohl nicht. Leider wurde es nicht 
weiter erörtert.

while( offset >= 512 ){
    sectors += 1;
    offset -= 512;
    file.seek += 512;   
            
    if(offset > 0)
    {
      chain.cntSecs -= 1;
    }
    
    if ( chain.cntSecs == 0 ){
      fat_getFatChainClustersInRow(fat_getNextCluster( chain.lastCluster ));
      sectors = chain.startSectors;
    }
  }

Hat jemand einen Hinweis?

[Falk B. (falk)]

@ 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 (Gast)]

Da das weiter schreiben klappt würde ich eher auf die FAT Lib tippen

[Jim M. (turboj)]

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)]

Dachte zunächst auch an eine falsch große Variable aber warum gehen dann 
weiter größere Datensätze?

[Peter (Gast)]

Jim M. schrieb:
> 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.

Als Code verwende ich die oben erwähnte lib und diese wird mit ffwrites 
zum beschreiben einer Sd-Karte verwendet!

[Olaf (Gast)]

> Jeder Datensatz ist 107 Byte lang daher kommt das
> Problem jetzt bei 32768 Sätzen.

Das liesst sich so als wenn du den Fehler einfach so reproduzieren 
kannst. Warum machst du das nicht und geht einmal im Debugger im 
Singlestep durch dein Programm. Dann musst du nicht labern, raten und 
hoffen sondern weisst genau woran es liegt. Das scheint mir schneller 
zum Ziel zu fuehren als hier zu fragen.

Olaf

[Peter (Gast)]

Danke für die teilweisen netten Antworten :P Labern gehört nicht dazu 
Olaf :P

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.

[Falk B. (falk)]

@ 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)]

@Falk

Das Beschreiben mit Hex 0X00 ist kein Unsinn sondern laut SD-Card 
Tutorial empfohlen

[Falk B. (falk)]

@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.

[Peter (Gast)]

@Falk,

klingt logisch! Werde es ohne die Nullen einfach noch einmal probieren.

[Falk B. (falk)]

>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.

[Peter (Gast)]

@Falk

im Prinzip ist das so ja nur leider greift die Karte bzw. Lib dann 
daneben. Aus dem Grund hänge ich direkt den nächsten Cluster ran.

[Peter (Gast)]

Mir ist bewusst, dass ich im Prnzip ein Cluster Sinnlos blockiere jedoch 
ist das bei meiner Anwendung unkritisch.

[Falk B. (falk)]

>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.

[Falk B. (falk)]

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!

[Marc V. (Firma: Vescomp) (logarithmus)]

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.