FAT für SD

hier in der Codesammlung findest du einiges, z.B. hier:
Beitrag "MMC/SD-Karte mit FAT16 an AVR"

Hi,

das hier:
http://elm-chan.org/fsw/ff/00index_e.html
ist eigentlich gar nicht schlecht, nur mit der Schreibfunktion hab ich 
so meine Probleme (gehabt). Irgendwo ist da ein Sektor-Offset falsch... 
Hab an irgendeiner Stelle im Quellcode "+32" eingefügt, seitdem geht es, 
hab das aber leider nicht hier und kann dementsprechend nicht 
nachschauen, wo das war.
Wollte das nochmal genauer untersuchen, aber mir fehlt die Zeit...

Gruß,
Christian

>Hab an irgendeiner Stelle im Quellcode "+32" eingefügt, seitdem geht es,
>hab das aber leider nicht hier und kann dementsprechend nicht
>nachschauen, wo das war.
>Wollte das nochmal genauer untersuchen, aber mir fehlt die Zeit...
klingt als wenn du eine SD mit Partitionssektor hast, diese aber vorher 
als Superfloppy angesprochen hast

Hi Wolfram,

ist schon ein paar Tage her, das ich das gemacht habe, und ich habe 
leider von FAT nicht so wahnsinnig viel Ahnung. Auf jeden Fall habe ich 
mit einigen unterschiedlichen Einstellungen bei Partitionierung und 
Formatierung herumgespielt, alles hat nichts genutzt. Soweit ich mich 
erinnern kann:

- mkdosfs /dev/sda (d.h. den ganzen Datenträger ohne Partionstabelle 
formatiert)
 -> mounten war nicht möglich

- mkdosfs /dev/sda1
  -> Datenträger ließ sich normal ansprechen etc., aber mittels 
Controller darauf schreiben ging nicht
     (D.h. die Dateien wurden schon angelegt und waren auch sichtbar, 
jedoch haben sie nicht den geschriebenen Text sondern nur Leerzeichen 
angezeigt. Mit "hexdump /dev/sda(1)" habe ich dann herausgefunden, daß 
die Daten schon geschrieben wurden, nur halt mit falschen Offset... Seit 
ich dann die genannte "Korrektur" durchgeführt habe, funktioniert es 
eigentlich ganz ok...)

Die FAT-Implementierung von elmchan.org bietet jedenfalls keine 
Einstellmöglichkeiten für derlei Sachen, demnach sollte das eigentlich 
automatisch erkannt werden. Ich hab den Code zwar mal überflogen, um den 
jedoch vollends zu verstehen, müßte ich mich etwas mehr mit dem 
FAT-Dateisystem an sich beschäftigen, was ich z.Zt. nicht möchte.

Naja, immerhin funktionierts.

Gruß,
Christian

Hi!
deine 32 sind die $20 von Adresse $1C6/1C7 im Sektor0. Da müssen aber 
nicht immer $20 drinnstehen. Du musst also einfach ein Dateisystem 
verstehen, wenn du es richtig verarbeiten willst. Wie willst du sonst 
Fehler finden. Schaue dir bitte den Dateianhang an unter:
Beitrag "Re: MMC/SD  Adresse"
Da steht alles Wichtige  für Fat16 drinn. Wenn du dich dann noch bischen 
mit Fat beschäftigst bekommst du das auch gebacken.

Viel Erfolg, Uwe

Hallo,
danke für eure Tips. Habe mir die gennanten Websites mal angeschaut. Die 
Mehrheit der Sachen ist leider für avr Controller geschrieben. Habe im 
Forum von Microchip jedoch folgenden Beitrag gefunden:

http://forum.microchip.com/tm.aspx?m=199006&mpage=1

Laut der Aussage dort brauche ich mit meinem PIC16F877a gar nicht erst 
anzufangen das FAT-System für eine SD Karte zu implementieren da der PIC 
zu wenig RAM besitzt und man mindestens 1.5 Kbyte benötigt (mindestblock 
ist 512 Byte.)Der PIC16F877 hat laut Datenblatt 386 Byte RAM und 256 
Byte EEPROM, also zu wenig.

Leider stehen mir nur die PIC Controller zur Verfügung und ich habe auch 
nur ein Brenngerät für PIC16 und nicht für die neueren PIC18.

Weiss da jemand eine Lösung oder bin ich komplett am A......?

Danke für Antworten
Gruss
Uli

Und Du kannst auch wirklich kein Geld ausgeben um das Ziel zu erreichen? 
Weil  vor allem weil man bei den AVRs ja auch relativ günstig zu einem 
programmierbaren Chip kommt. (Mega8, STK200 kompatibler 
Programmieradapter (oder eben paralleles Kabel), AVR GCC)

Gruss, Sebastian

http://www.cc5x.de/MMC/index.html

Hallo,

was ist denn mit einem externen Ram!?
Dennis

@ Sebastian Eckert

Die Seite kannte ich auch schon. Da wird aber nur eine Routine zum lesen 
der SD Karte mit dem PIC16 beschrieben. So wie ich das verstanden habe 
brauche ich beim lesen nicht unbedingt den 512 byte speicher, die Sache 
wird halt nur langsamer.
Anders beim schreiben:

Zitat:

Hier sieht es jetzt völlig anders aus ! Wenn die SD beschrieben
werden soll muß immer ein kompletter Sektor geschrieben werden.
Es ist möglicherweise auch hier egal wie lange es von Byte zu Byte
dauert bis der komplette Sektor beschrieben wurde. Für einen
Datensektor gibt es bis hier noch keine Probleme wenn die Daten
Byte für Byte sofort zur SD gesendet werden.

Die Probleme fangen an wenn man die FAT aktualisieren muß. Man muß
immer einen kompletten Sektor ins RAM lesen um den Verzeichniseintrag
oder die FAT zu aktualisieren und dann auf die SD zurückschreiben.
Das geht nicht anders. Ein Sektor ist 512 Bytes groß. Man braucht auch
noch einiges für die Verwaltung der Daten. Sagen wir mal 50 Bytes. FAT
zu schreiben braucht also mindestens 562 Bytes. Eher mehr.

Zu Externem RAM: Hmm, habe keine Ahnung davon aber es scheint die Sache 
wohl noch mehr zu komplizieren.

Vielleicht sollte ich doch schauen auf einen besseren PIC18 umzusteigen.

Gruss
Uli

Ja, das stimmt wohl, leider. Externer RAM benötigt entweder, parallel 
angesteuert, eine ganze Menge Portpins, die man sicher für andere Zwecke 
besser gebrauchen könnte, oder bringt, seriell angesteuert, recht viel 
programmiertechnischen Overhead mit sich. Es gab mal RAMs mit I2C, wenn 
ich mich richtig erinnere, wahrscheinlich von Philips. Ist aber lange 
her, ob es die noch gibt, ist fraglich.

Wenn Geschwindigkeit eine Rolle spielt, hilft wohl doch nur ein größerer 
Controller mit internem RAM, oder einer, der, im Gegensatz zu den 
üblichen PICs, ein Interface für externen statischen RAM hat (8051er, 
AT90S8515... aber wahrscheinlich gibt es das bei den "großen" PICs 
auch.)