Hallo, ich suche eine möglichst ausgereifte Version einer Fat16/32 implementierung. Zudem wäre es interessant die spec der Fat8 12 16 und wenn möglich infos zur Fat32 zu bekommen, speziell die einteilung des speichers, beginn von Fat und Root tabellen und des datenbereichs auf dem tragenden medium. Vielleicht hat ja auch noch jemand eine schöne zusammenfassung über die initialisierung und ansteuerung von sd und cf karten. Ich weiß es gibt unmengen an links und zusammenfassungen, genau das ist mein problem. ich suche einen möglichst ausgereiften code für eine fat, mit read/write funktionen, funktionen um dateien/verzeichnisse anzulegen und zu löschen, um das medium zu formatieren, um einen kompletten dateinamen auszulesen, um die fat auf dem medium selbst eigenständig zu erkennen, möglichts prozessor und medium unabhängig um ihn dann für meine zwecke anzupassen. Vielleicht existieren in der richtung ja ansätze und überlegungen, in bezug auf die gestaltung einer hardwareunabhängigen schnittstelle usw... specs über sd karten und cf karten habe ich bereits, hierzu wäre speziell eine struktur bei der ansteuerung der karte interessant... welche kommandos müssen in welcher reihenfolge gesendet werden usw....also ein paar hardwareerfahrungen... vielleicht gibts ja so etwas, wäre aber warscheinlich einfach zu schön um war zu sein :-) freue mich auf eure antworten... Dennis
> ich suche eine möglichst ausgereifte Version einer Fat16/32 > implementierung. Wenn dir Bastelloessungen nicht gefallen, wieviel kEur bist du denn bereit fuer eine professionelle Lizenz auszugeben? Geben tut es sowas ja, wie man an jeder Digitalkamera sehen kann. Olaf p.s: FAT8 gibt es aber nicht .-)
Welcher Prozessor? Im Linux-Kernel ist das alles drin.
> Welcher Prozessor? Sollte egal sein da man sowas sowieso in C oder einer anderen Hochsprache macht. > Im Linux-Kernel ist das alles drin. Stimmt. :-) Aber die meisten hier basteln ja mit irgendwelchen kleinen Microcontrollern rum und dafuer ist FAT eigentlich schon eine Nummer zu gross. Sowas ist nur dann sinnvoll wenn man nur einen Teil der Funktionalitaet unterstuetzt und Kompromisse mit der Leistungsfaehigkeit eingeht. Und aus genau diesem Grunde ist es auch sinnvoll sich seine eigene Implementation zu schreiben weil man die auf seine Beduerfnisse anpassen kann. Aber das macht es natuerlich schwer wenn man alles anderen abschreiben will da die eigenen Beduerfnisse oft anders sind als die des Autors. So unterstuetzt z.B meine eigene Implementation nur immer maximal ein geoeffnetes Files und auch keine Unterverzeichnisse. Mir reicht das, anderen wahrscheinlich nicht. Dafuer leiste ich mir den Luxus das Direktory komplett im Ram zu halten. Das koennte wiederum kleinen AVRs den Schweiss auf die Bits treiben. Olaf
FAT32 http://www.microsoft.com/whdc/system/platform/firmware/fatgendown.mspx? http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html http://en.wikipedia.org/wiki/FAT32
Achso, die CF-Specifikation http://www.compactflash.org/specdl1.htm die "vereinfachte" SDCard Spezifikation gibt's hier http://www.sdcard.org/sd_memorycard/Simplified%20Physical%20Layer%20Specification.PDF
in dem EFSL Projekt ist doch schon eine ganze Menge drin, auch für verschiedene Prozessoren: http://www.efsl.be/ Aber alle denkbaren Features per Compilerschalter wählbar einzubauen wird wohl ein Lebenswerk werden. Irgendeine Anwendung/Prozessor hat mit Sicherheit wieder andere Anforderungen und erfordert Codeänderungen.
Angehängte Dateien:
-
Fat.JPG
30 KB
Hallo Olaf, natürlich gibt es das alles zu kaufen, im anhang befindet sich eine grobe schnittstellengliederung. Ist von einer Fat der Firma Segger. ...mein interesse ist dem bastelwesen gewidmet. es gibt leider nur so viele unterscheidlich ausgeprägte versionen, -die einen müssen die karte im rechner vorvormatieren und schreiben dann wohl NUR einfach in den datenbereich der fat... -die nächste gruppe kann in zwischen dateien unterscheiden, aber die nicht anlegen oder löschen,müssen vorhanden sein... -dann gibts welche die lesen den namen der dateien, aber nur die ersten 8 zeichen, die nächsten suchen sich noch den rest aus der fat.. .... klar, mann kannn das beliebig tief aufziehen, also z.B. auch beim schreiben der datei die "lücken" in der fat, die duch zuvoriges löschen entstanden sind, wieder auffüllen usw... ich dachte nur, das geradei in dem bereich, in dem wirklich viel gemacht wird, rein basteltechnischer natur, auch komplexere software existieren müsste.... und ansonsten könnte man diese hier langsam mal ansammeln und in die codesammlung stellen.. alle 2-3 tage sind fragen zur fat und zu den aktuellen speichermedien, doch in der codesammlung habe ich noch nichts vergleichbares gefunden, oder irre ich mich. ich wollte für mich vermeiden das rad ganz neu zu erfinden, und bin überzeugt das es da auch einen anderen weg geben wird - "c" ist wirklich nicht umsonst erfunden worden.. :-) Hallo Name, du brauchst keine angst zu haben, aber deinen namen kannst du hier ruhig verraten :-)) ...über die möglichkeit habe ich auch schon nachgedacht. würdest du mir den entsprechenden code aus dem linux kernel zusammenstellen und erklären? ich denke das ist eine gute sache...da wird ja auch die fat 32 unterstützt :-) Dennis
hmm... das mit der teilimplementierung mag ja sein, und vielleicht hast du recht und die fat mit all ihren implementierungen ist einfach zu "umfangreich" um sie strukturiert und möglichst flexibel zu implemntieren... den "weitblick" habe ich momentan leider noch nicht... @ arc - danke für die links.. @ jojo - mag sein das das so ist... die kleine übersicht die ich eingestellt habe, zeigt zumindest eine denkbare unabhängige struktur... meine intension ist es nicht etwas abzuschreiben, vielmehr mir einen möglichst weitläufigen überblick zu verschaffen, bevor ich mich daran setze und in die tasten haue.... etwas ähnliches habe ich schonmal mit einer möglichst flexiblen pixel grafik "codesammlung" versucht - ist nicht so einfach das alles unter einen hut zu bringen, da es meist so ist wie olaf schon sagt - die bedürfnisse müssen den "beschränkten" leistungen der controller angepasst werden, und das erlaubt meist nicht diesen weitblick, der bei so vielen projekten doch so vieles einfacher machen könnte... dennis
> etwas ähnliches habe ich schonmal mit einer möglichst flexiblen pixel > grafik "codesammlung" versucht - ist nicht so einfach das alles unter Sowas geht aber eigentlich noch. Ich habe das so geloest das ich mir fuer des Display eine function schrieb welches dort ein beliebiges Pixel setzen kann, alles andere setzt dann darauf auf. Das ist natuerlich extrem ineffizient, vor allem wenn man mal an die Ausgabe eines Zeichens denkt das so Pixelweise gemahlt wird. Oder gar das loeschens eines Bildschirms. Aber da man an den kleinen Controllern meist auch nur kleine Displays verwendet und auch immer nur wenig auf dem Bildschirm aendert, ist das normalerweise kein Problem. Der groesste Engpass bei FAT dagegen ist Ram. Hinzu kommt noch das man sicher gerade bei FAT auch nur schlecht auf bestimmte Groessen verlassen kann. Je nachdem wer da formatiert, kann z.B die FAT bei einem Medium derselben groesse durchaus unterschiedlich gross sein. Und genauso ihre Position. Also dann Speicher dynamisch allozieren? Bei Anwendungen unter den beengten Verhaeltnissen eines Controllers auch nicht gerade eine Garant fuer Zuverlaessigkeit. Sinnvoll waeren vermutlich zwei Implementationen. Eine minimalistische welche mit 512Byte Buffer fuer einen Sektor und etwa 100Byte als Merker auskommt, dafuer aber nicht viel mehr kann als ein File schreiben und lesen und das auch noch grottenlahm. Und eine weitere Sache die etwas Dicker ist, sagen wir mal 5-10kRam und 20-30k Flash wo man sich dann mehr erlauben kann. Olaf
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.