mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik FAT16 auf SD mit PIC18 in ASM


Autor: PICPiggy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: stepp64 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: BitSchubser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jo, das wär mal interessant. Denke auch dass der Code in ASM effektiver 
wäre.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: PICPiggy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.