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.
Jo, das wär mal interessant. Denke auch dass der Code in ASM effektiver wäre.
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
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.