Hallo,
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.
DAS würde mich auch interessieren. Ich bin zwar noch beim 16F Assembler,
plane aber in nächster Zeit mal mit den 18F anzufangen, da die 8kByte
Assemblercode der 16F bei meinem aktuellen Projekt langsam an ihre
Grenzen stosen (ich muss nun schon die ganzen Displaytexte in einen
externen EPROM auslagern um noch ein wenig PLatz für den Code zu
bekommen...). Und, ja ich habe auch keine Ambitionen auf eine
Hochsprache umzusteigen.
Was heißt "garantiert keine Fragmentierung"? Sobald du zu einer
vorhandenen Datei was hinzufügst kann eine Fragmentierung nötig sein.
Oder wenn du eine von mehreren Dateien löscht ist der freie Platz
fragmentiert, womit du v.a. bei einer volleren SD-Karte auch
zurechtkommen musst.
Wie schnell ist denn der Datenstrom? Du wirst ihn puffern müssen um
keine Daten zu verlieren, wenn die SD ihr Wear-Leveling durchführt.
Eventuell musst du dafür einen externen Ram vorsehen. Ich weiß nicht,
was die PICs so intern haben.
Ehrlich gesagt bezweifel ich aber, dass es viele Leute gibt, die auf
PIC-Assambler sich sowas schonmal angetan haben. Du krigst halt vor
allem beim FAT viele Mehr-Byte-Operationen...
Ich weiß nich wie das bei deidem Compiler ist, aber vielleicht wäre es
ja ne Option nur die Low-Level Routinen in Assambler zu schreiben. Das
bringt dann die nötige Performance. High-Level-Seitig muss man sich
dafür nicht mit 16bit Operationen rumschlagen.
Aber du kannst mal bei den mp3-Player-Bastlern suchen. Da gibts auch ein
paar Projekte die auf PICs basieren. Weiß aber nicht, in was die
programmiert haben.
Hast du dir denn schon konkrete Gedanken gemacht über den Aufbau deiner
Software? Bisschen Ablaufdiagramme gemalt? Wenn nicht, dann mach das mal
als erstes. Wenn doch: Wo hängst du denn?
Sebastian
@Sebastian
Na, da hat sich mal einer der Sache angenommen. Kommentare wie folgt:
> Was heißt "garantiert keine Fragmentierung"? Sobald du zu einer> vorhandenen Datei was hinzufügst kann eine Fragmentierung nötig sein.> Oder wenn du eine von mehreren Dateien löscht ist der freie Platz> fragmentiert, womit du v.a. bei einer volleren SD-Karte auch> zurechtkommen musst.
Begründung: Auf der SD-Card einmal vorhandene Dateien werden NICHT mehr
schreibend angefasst. Ist die SD-Card voll (oder eine gewisse Anzahl an
Dateien erreicht) wird alles manuell auf den PC kopiert und die SD-Card
manuell gelöscht.
> Wie schnell ist denn der Datenstrom? Du wirst ihn puffern müssen um> keine Daten zu verlieren, wenn die SD ihr Wear-Leveling durchführt.> Eventuell musst du dafür einen externen Ram vorsehen. Ich weiß nicht,> was die PICs so intern haben.
Das ist natürlich ein Thema. Vorgesehen ist, dass ein oder zwei Blöcke
zu 512 Byte im RAM des PIC's zwischengespeichert werden und dann
blockweise auf die SD-Card wandern. Bei PIC18Fxxxx sollte der zur
Verfügung stehende RAM ausreichend sein.
> Ehrlich gesagt bezweifel ich aber, dass es viele Leute gibt, die auf> PIC-Assambler sich sowas schonmal angetan haben. Du krigst halt vor> allem beim FAT viele Mehr-Byte-Operationen...
Ich will ja auch kein Kreuzfahrerheer sammeln, mir reichen ein paar
Einzelkämpfer doch vollkommen aus. Und die müssen doch ihr Wissen auch
nicht vollständig preisgeben, das steckt i.d.R. viel Arbeit drin.
Anregungen oder Informationsquellen sind vielfach sehr hilfreich.
Ausserdem ist es doch interessant zu wissen ob man unter den gegebenen
Umständen und Anforderungen überhaupt erfolgreich sein könnte.
Und ob ich diese PIC-Spezies hier im Forum finde weiss ich nicht, aber
ich gebe die Hoffnung nicht auf ;)
> Ich weiß nich wie das bei deidem Compiler ist, aber vielleicht wäre es> ja ne Option nur die Low-Level Routinen in Assambler zu schreiben. Das> bringt dann die nötige Performance. High-Level-Seitig muss man sich> dafür nicht mit 16bit Operationen rumschlagen.
Ich habe auch schon darüber nachgedacht vorhandene C-Quellen zu
compilieren und, jetzt bitte nicht lachen, dann den ASM-Quellcode wieder
zu deassemblieren.
Ich bin zwar recht fit im PIC-Programmieren in Assembler und im Einlesen
in fremde Quelltexte aber bei dieser Größenordung Quellcode werde ich
alt drüber, denke ich.
> Aber du kannst mal bei den mp3-Player-Bastlern suchen. Da gibts auch ein> paar Projekte die auf PICs basieren. Weiß aber nicht, in was die> programmiert haben.
Das habe ich in der Tat gemacht. Jedoch findet man fast immer nur
Projekte in C. Ausnahmen sind selten und betreffen meist (nur) den
lesenden Zugriff auf MMC/SC-Cards mit mehr FAT16-Funktionen als ich
eigentlich brauche, das wäre auch noch nicht einmal das Problem. Zum
schreibenden Zugriff aber habe ich bisher noch nichts gefunden, für
Quellenangeabe wäre ich sehr dankbar.
> Hast du dir denn schon konkrete Gedanken gemacht über den Aufbau deiner> Software? Bisschen Ablaufdiagramme gemalt? Wenn nicht, dann mach das mal> als erstes. Wenn doch: Wo hängst du denn?
Ja, habe ich. Blockschaltbilder, Schaltplanfragmente, Flussdiagramme,
Code-Schnipsel: eben alles was so dazugehört. Ich bin noch in der Phase
der Prüfung der Machbarkeit, speziell eben bei der Realisierung ALLER
notwendigen Funktionen in PIC-Assembler. Und dort komme ich mit dem
Datenmanagement '(Datenquelle)<->PIC<->SD-Card' nicht weiter.
Aber trotzdem erst einmal vielen Dank für Deine Bemerkungen.
>Das ist natürlich ein Thema. Vorgesehen ist, dass ein oder zwei Blöcke>zu 512 Byte im RAM des PIC's zwischengespeichert werden und dann>blockweise auf die SD-Card wandern.
Ein Block wird nur bei einem seeehr langsamen Datenstrom wirklich
ausreichen. Eben wegen besagtem WearLeveling. In der Codesammlung hat
jemand einen Wave-Recorder mit nem AVR XMega und SD-Karte. Soweit ich
mich erinnere hat der 64kByte Ram dazugebaut. Kommt halt stark auf deine
Quelle an.
>Ich habe auch schon darüber nachgedacht vorhandene C-Quellen zu>compilieren und, jetzt bitte nicht lachen, dann den ASM-Quellcode wieder>zu deassemblieren.
Ich denke das macht reichlich wenig sinn. Dann solltest du lieber den
C-Code "händisch compilieren". Also aus dem C-Code Flussdiagramme
extrahieren und diese dann in ASM umsetzen. Je nach dem wie gut deine
C-Kenntisse sind dürfte das wohl der beste weg sein, wenn du auf ASM
bestehst.
>Ich will ja auch kein Kreuzfahrerheer sammeln, mir reichen ein paar>Einzelkämpfer doch vollkommen aus.
Ja, das ist mir klar. Ich wünsch dir auch viel Glück dabei. Ich fürchte
nur, dass die paar Einzelkämpfer ihre Sourcen dann auch nicht
veröffentlicht haben. Ich hab hier auch nen mp3-Player mit HDD und FAT32
komplett in ASM in Arbeit. Den Code werde ich wohl auch nie
veröffentlichen, weil er für andere schlicht nicht nachvollziebar ist.
> Und dort komme ich mit dem Datenmanagement '(Datenquelle> <->PIC<->SD-Card' nicht weiter.
Wo genau liegt das Problem. Prinzipiell ist es ja recht einfach. Die
Datenquelle wird in einen Ringpuffer eingelesen. Sobald ein Block
zusammengekommen ist versucht man dann diesen auf die SD zu schreiben.
Der Ringpuffer kann ja durchaus in 512-Byte-Blöcken organisiert sein.
Daten in den Puffer einlesen macht man im Hintergrund über einen
Interrupt (entweder isochron über Timer, oder eben per Pin-Interrupt, je
nach Quelle). Wenn der Kontroller sonst nichts mehr tun muss kann mann
das Daten-auf-die-SD-schicken schön gemächlich in der main erledigen.
Dort kann man dann ruhigen gewissens in Endlosschleifen den Zustand der
SD abfragen und mit Senden anfangen, sobald sie bereit ist.
Sebastian
