FAT16 auf SD-Card im PIC18 in ASM

[PICPiggy]

Hallo,
nachdem ich mich bereits im Mikrocontroller.net-Forum zum Thema gemeldet hatte ( http://www.mikrocontroller.net/topic/140518) hatte möchte ich hier mein Anliegen noch mal vorbringen (dies hier scheint ja ein reines PIC-Forum zu sein):
Ich hätte mal eine Frage ans geneigte Fachpublikum, zunächst ein paar Erläuterungen:
Ich möchte von einer externen Datenquelle einen seriellen Datenstrom (Mediadaten) mit einem PIC18 via SPI entgegennehmen und via SPI auf einer SD-Card, welche mit einem FAT16-System formatiert ist, ablegen.
Folgende Anforderungen an die ‚Bedienung’ des FAT16-Systems durch den PIC18 werden gestellt:
- lesender UND schreibender Zugriff auf die SD-Card
- garantiert KEINE Fragmentierung der Daten auf der SD-Card
- Operationen (Lesen/Schreiben) NUR im Root-Verzeichnis mit max. 255 Dateien
Grundkenntnisse (was die oben angesprochenen drei Punkte betrifft) des FAT-Dateisystems und des lesenden Zugriffes auf eine SD-Card sind vorhanden.
Bis hier hin (wahrscheinlich) alles kein Problem (außer dem Timing am SPI), aber jetzt der Hammer: Ich möchte den Code in Assembler umsetzen !
Ach, und ja, ich habe einen Klatsch und nein, ich möchte keinesfalls eine Hochsprache (C oder Pascal ö.ä.) verwenden.
Nun die Frage: Hat jemand so etwas schon einmal realisiert und wäre dieser Jemand bereit evtl. mit Quellcode zu helfen ?
Für eine rasche Hilfe danke ich schon mal im Voraus.

[theborg]

Hi, klar warum nicht es gibt auch leute die benutzen nen ASM USB Stack da sollte FAT nen Kinderspiel sein.

Aber warum unbedingt FAT warum nicht RAW des auswerten geht da recht einfach.

[PICPiggy]

@theborg
Zwei Gründe: Mittelfristig sind die Mediadaten schon formatiert (8.3-Dateiname) und die Dateien sollen mit allen PC-Standardanwendung handhabbar sein.

[Coltfisch]

Sorry, mir fehlt da so ein wenig das Verständnis.
Offensichtlich willst Du diese FAT-Library in Assembler ausschließlich zu Deiner persönlichen Befriedigung schreiben (denn andere triftige Gründe für die Wahl Deiner "Programmiersprache" nennst Du ja nicht.).
Aber warum fragst Du dann nach fremden Quellcode?
Setz Dich auf Deinen Hosenboden, fahr Dir das hier rein:
http://staff.washington.edu/dittrich/misc/fatgen103.pdf
...und fang an zu programmieren.
Eine FAT-Implementierung zu schreiben ist nicht schwer, es ist aber sogar bereits in einer Hochsprache einfach nur eine Fleißaufgabe.
Du scheinst enorm viel Freizeit und Langeweile zu haben, um Dir so ein Projekt mit sehr zweifelhaftem Ziel vornehmen zu können. Andererseits bittest Du hier aber um "schnelle Hilfe". Das passt irgendwie nicht zusammen.

Ich will Dich da jetzt keinesfalls von Deinem Plan abhalten und machbar ist dieses Projekt sowieso, aber überlege Dir besser noch einmal genau, welchen Nutzen Du aus Deinem Vorhaben ziehen kannst, denn meine Freizeit wäre mir dafür definitiv zu schade! Einen erhöhten Lerneffekt gegenüber einer Hochsprachenimplementierung wirst Du sicherlich nicht haben. Geschwindigkeitsvorteile? Naja,... potentielle Flaschenhälse wirst Du auch in einer Hochsprachenimplementierung mit Inlineassembler entschärfen können.

Wünsche Dir aber trotzdem viel Erfolg! 

[PICPiggy]

@Coldfish
Ich würde Dich bitten Dich im Ton etwas zu mässigen und vom 'hohen Ross' herabzusteigen. In Deinem Beitrag kann ich leider keinerlei Konstruktives erkennen und so bleiben 16 Zeilen Polemik und auch etwas Arroganz zurück.
Es sind Typen wie Du die mir und vielleicht auch andernen jeden Lust am Wissens- und Informationsaustausch auf gleicher Ebene vergehen lassen. Aber vielleicht trollst Du ja auch gern ...

[Coltfisch]

Na jetzt fühl Dich mal nicht gleich auf den Schlips getreten 

Es sind Typen wie Du die mir und vielleicht auch andernen jeden Lust am Wissens- und Informationsaustausch auf gleicher Ebene vergehen lassen

Genau hier liegt das Problem: In diesem speziellen Fall sind wir nicht auf einer Ebene. Denn ich habe bereits 1,75 FAT-Implementierungen geschrieben (allerdings "nur" in einer Hochsprache) und meine daher, den Aufwand sowie den Nutzen einer Hochsprachen- gegenüber Assemblerimplementierung recht gut einschätzen zu können.
Ich würde sehr gerne mit Dir konstruktiv über Deine Beweggründe diskutieren, leider hast Du Deine Angaben etwas knapp formuliert:

Ach, und ja, ich habe einen Klatsch ...

Da fällt es einem schon mal schwer, Dein Vorhaben ernst zu nehmen.

In Deinem Beitrag kann ich leider keinerlei Konstruktives erkennen

Ooooch, das ist gemein. Immerhin hab ich Dir den Link zu der allerbesten Informationsquelle geschickt, die Du benötigst, um eine FAT-Lib zu schreiben.

In meinem vorherigen Beitrag habe ich übrigens nur meine eigene Meinung zu Deinen Plänen kundgetan. Abgesehen davon waren meine Wünsche für ein erfolgreiches Gelingen völlig ernst gemeint und - da ich mich mit der Materie tatsächlich auch auskenne - würde ich Dir auch bei Problemen zur Seite stehen. Sogar Quelltext könntest Du von mir haben... aber nur in C 

[Stampede]

Hallo,

ich habe sowas schon mal realisiert, jedoch eine HDD beutzt. Mein Code hat sich erst mal auf Lesen und Navigieren durch dir FAT32(!) begrenzt, Schreiben sollte dann aber auch nicht mehr das Problem sein. Jedoch ist das eine irrsinnige Arbeit, solltest dir gut überlegen, ob es das bringt.
Ich hatte das auf einem 18F4550 realisiert, mit USB-Schnittstelle als MSD. Das ging alles schon recht flott, selbst Ordner mit 1000 Einträgen gingen noch ganz gut. Über USB waren knapp 600kb/s lesen drin.
Ich sehe das Problem bei dir, dass der PIC sehr viele Daten durch das SPI schicken muss, was recht langsam ist. Kein 18F hat mehr als 4kB RAM, sodass du maximal 6-7 Blocke auf einmal Schreiben kannst (reduziert schon mal den Overhead was FAT, LBA, etc. anbelangt).
Wie schnell ist denn der Datenstrom?
Ich sehe am meisten das Problem, wenn eine neue Datei erstellt werden soll. Dann muss der ganze FAT-Klimbims ausgelesen und neu geschrieben werden. Das dauert einige ms. Diese Zeit muss du im RAM alle Daten ablegen, die über SPI reinkommen. Bei 3kB verwendetem RAM (Rest wirst du zum Erstellen der Datei brauchen) und sagen wir mal 25ms zum Erstellen der Datei sind das rund 122kB/s, damit der PIC aber auch nebenbei die Datei Erstellen kann sollten es nicht mehr als vielleicht 100kB/s sein.  Das ist aber nur mal sehr grob geschätzt, und hängt sehr stark!!! von der Effektivität deines Codes ab. Mit guter Interruptlogik sollte das schon machbar sein, garantieren kann ich dir das aber nicht.
Wenn es also ein MP3 Stream mit 128kBit/s ist, sollte das machbar sein. Eine Datenaufzeichnung beispielsweise von Flugdaten oder Wetterstation ist bestimmt auch gerade noch machbar.
Mit einem PIC mit DMA (wie zB die 16Bit oder 32Bit Prozis) sollte dein Vorhaben besser zu realisieren sein, leider wirds da mit Assembler richtig schwer.

Gruß
Stefan

[Steffen]

Hab das Thema mal dort hin verschoben, wo es hingehört.

@PICPiggy
Mach dir doch bitte die Mühe die Beiträge zu lesen, bevor Du hier Leute beleidigst, die dir eigentlich nur helfen wollten!

Gruß
Steffen

[dsPIC-Fan]

Schade dass es zu diesem Missverständnis kam. Wer öfters im Forum liest kennt Coltfisch's hilfreiche Beiträge.

Ich habe mit viel Mühe und Unterstützung von CCS einen dsPIC33 mit einem 5,7"-TFT-Display, CAN-Bus und per RS232 angeschlossenem Bluetooth-Modul zum Laufen bekommen und bin eigentlich von der Leistung und Geschwindigkeit dieses Prozessor trotz der vielen Erratas begeistert.

Nun ist ein altes Problem aufgetaucht: Ich kann zwar die Dateien von der am SPI1 angeschlossen SD-Card lesen, wenn ich den Sector kenne. Die von CCS gelieferten Libraries mmcsd.c und fat.c sind nicht an den PCD angepasst und funktionieren nicht richtig. Ich bräuchte mal zumindest einen Code, mit dem man unter Windows gespeicherte Dateien (Bitmaps) nach ihrem Namen suchen kann und deren Start-Sector auslesen kann. Wer kann helfen ?

Gruß Bernhard.