Ich würde gerne eine SD-Karte mit meinem PIC24F16KA102 ansprechen. Vorerst will ich nur *.txt Files von der Karte lesen. Von Microchip gibt es dazu die MLA/FILEIO [1]. Ich habe mit die AN1045 von Microchip angesehen und bind damit nicht sehr gut zurechtgekommen. Wie ich die einzelnen Funktionen, wie FSfread,.. anwende habe ich verstanden. Ich verstehe aber nicht, wie ich alles Einstellen muss, damit ich die Funktionen verwenden kann. Weiß jemand wo ich eine Seite finde, auf der gut beschreiben ist, wie ich die MDD Lib konfiguriere? Vielen Dank und Grüße [1] http://www.microchip.com/pagehandler/en-us/devtools/mla/ P.S. Ich verwende MPLAB IDE mit dem XC16 Compiler.
Hallo, vermutlich ist dein PIC zu klein (das Demoprojekt braucht 47% Flash wenn man es compiliert, bei einem 128k-PIC). Zum Portieren: Ich würde mir das vorgefertigtes Projekt für das Teil mal in MPLAB öffnen und mir das dort abschauen. Das für dich relevante ist das Demonstration2.c. Da muss man sich leider durchbeißen und das zumindest so ungefähr verstehen. Am besten kopiert man sich das Projekt und kürzt das erst einmal auf einen PIC zusammen. (diese ganzen #ifdefs) Die HardwareProfile.h musst du sicher anpassen. Danach die main() in Demonstration2.c anschauen, was dort gemacht wird. Da wirst du zumindest die SPI-Init anpassen müssen. Was vielleicht eine Alternative ist: http://elm-chan.org/fsw/ff/00index_e.html Da gibt es ein komplett fertiges Projekt für einen PIC24. Es gibt eine abgespeckte Variante mit weniger Speicherverbrauch.
Ich habe das mit dem Filesystem (FS) vorerst aufgegeben und entschieden mein Glück ohne FS zu versuchen... Ich habe dazu ein Dokument gefunden: http://www.uni-koblenz.de/~physik/informatik/ECC/sd.pdf Es hat viele meiner Fragen beantwortet, aber leider noch eine aufgeworfen: Bei der Init (S. 14): > Beispiel-Initialisierung mit ACMD41: > Send: 0x77 0x00 0x00 0x00 0x00 0x01 (CMD55, das "Prefix" fur ein ACMD) > Recv: 0x01 (R1-Antwort mit dem "In Idle State"-Bit gesetzt.) Hab ich das richtig verstanden, dass ich erst die 6 Byte senden muss und dann ein 0xFF um die Antwort zu lesen? Beim Lesen von Daten (S. 15): Beispiel: > Send: 0x51 0x00 0x00 0x08 0x00 0x01 (CMD17, Lese Block ab Byte 2048) > Recv: 0x00 (R1-Antwort: Alles OK) > Recv: 0xfe 0x4e 0x65 0x72 0x64 0x21 ..... 0xa7 0x22 Muss ich hier dann nach dem Befehl (6 Bytes) 0xFF senden um die R1 Antwort zu erhalten und dann so lange 0xFF bis ich den Data Token 0xFE erhalte und dann noch 512+2 (Daten + CRC) mal bis ich alle Daten habe. Vielen Dank im Voraus :-)
holger schrieb: > Hat jemand eine Ahnung von der Ansteuerung ohne FS? > > Ja. Da du anscheinend mit absoluter Sicherheit sagen kannst, dass jemand Ahnung von der Ansteuerung ohne FS hat gehe ich davon aus, dass es auf dich zutrifft. Würdest du oder jemand anderes der sich damit auskennt bitte meine Frage beantworten? Danke
@ Max H. (hartl192) >Ich habe das mit dem Filesystem (FS) vorerst aufgegeben und entschieden >mein Glück ohne FS zu versuchen... Ich habe dazu ein Dokument gefunden: Keine weise Entscheidung. Das FATfs von ELM Chan läuft super, kann ich wärmsten empfehlen. http://elm-chan.org/fsw/ff/00index_e.html
Das Problem dabei ist nur, dass mein PIC zu wenig ROM und RAM hat. Mittlerweile habe ich entschlossen, dass ich keine Fertige Lib verenden will, sondern erst verstehen will wie man ohne FS schreibt und liest. Wenn ich irgendwann mit FS arbeiten will, werde ich auf die Lib von ELM Chan oder das FILEIO von Microchip zurückkommen.
@ Max H. (hartl192) >Das Problem dabei ist nur, dass mein PIC zu wenig ROM und RAM hat. ROM sowieso nicht, eher Flash ;-) Wieviel hat er denn? Mal die Seite gelesen? http://elm-chan.org/fsw/ff/00index_p.html >Mittlerweile habe ich entschlossen, dass ich keine Fertige Lib verenden >will, sondern erst verstehen will wie man ohne FS schreibt und liest. Ob das soo sinnvoll ist? Schließlich ist der Inhalt deines Projektes NICHT einen SD-Kartenzugiff neu zu machen sondern was anderes. Der SD-Zugiff ist nur Mittel zum Zweck. >>Wenn ich irgendwann mit FS arbeiten will, werde ich auf die Lib von ELM >Chan oder das FILEIO von Microchip zurückkommen. Damit hebelst du das Konzept einer derartigen Bibliothek zu 100% aus. Glückwunsch! Denn der Sinn liegt ja gerade da drin, dass man sich NICHT um die internen Details kümmern muss, sondern recht einfach un komfortabel die Sache nutzen kann. Du musst schließlich auch kein Auto bauen, um es zu fahren! Wenn man immer und überall JEDES Detail verstehen will, kommt man nicht vorwärts.
>Du musst schließlich auch kein Auto bauen, um es zu fahren!
Er muss aber auch kein LKW besitzen, nur um Auto zu fahren.
Falk Brunner schrieb: > ROM sowieso nicht, eher Flash ;-) > Wieviel hat er denn? 16kB (5632 Instructions) > Mal die Seite gelesen? > http://elm-chan.org/fsw/ff/00index_p.html Diese nicht, ich habe aber gesehen, dass das Demoprojekt für PIC241 ca. 16200 Byte brauch. > Ob das soo sinnvoll ist? Schließlich ist der Inhalt deines Projektes > NICHT einen SD-Kartenzugiff neu zu machen sondern was anderes. Der > SD-Zugiff ist nur Mittel zum Zweck. Ich plane eigentlich kein Projekt, ich will nur ein bisschen mit der SD-Karte spielen um mich hochzuskillen (skill: engl. Fähigkeit). > Damit hebelst du das Konzept einer derartigen Bibliothek zu 100% aus. > Glückwunsch! > Denn der Sinn liegt ja gerade da drin, dass man sich NICHT um die > internen Details kümmern muss, sondern recht einfach un komfortabel die > Sache nutzen kann. > Du musst schließlich auch kein Auto bauen, um es zu fahren! > Wenn man immer und überall JEDES Detail verstehen will, kommt man nicht > vorwärts. Wenn man das Auto verstehen will, hilft es einem nicht viel damit ein paar Runden zu drehen. Wieso nimmt jemand einen µC um eine LED blinken zu lassen, das geht ja viel einfacher mit 4 Widerständen, 2 Kondensatoren und zwei Transistoren?
@Max H. (hartl192) >Ich plane eigentlich kein Projekt, ich will nur ein bisschen mit der >SD-Karte spielen um mich hochzuskillen (skill: engl. Fähigkeit). Aua! Früher hies das lernen, weiterbilden, experimentieren. Heute ist es Assi-Denglisch! WÜRG Na dann mal viel FUN beim hochskillen.
Wenn mir jemand meine Frage von oben* beantworten würde könnte ich auch mit dem verbessern meiner Fähigkeiten anfangen... *Beitrag "Re: SD-Karte mit PIC24" Falk Brunner schrieb: > Früher hies das lernen,[...] Ich bin noch nicht so lange dabei, aber war es früher üblich Fragen zu beantworten und nicht einfach zu einem Fertigen, nicht gefragten, Code zu verweisen, weil man keine Ahnung hat?
Hallo Max, ich habe leider Deinen Post erst jetzt gesehen. Prinzipiell bist Du aus meiner Sicht nicht weit daneben. Nach dem Absetzen eines Kommandos kann es einige Zeit gehen bis die Response und danach die Daten von der Karte kommen. Die Karte braucht ja intern auch eine Zeit um das Kommando zu verarbeiten respektive danach die Daten aus dem Flash rauszulesen und in den Datenbuffer zu laden. Das 0xFF muss allerdings nicht der Host "senden", sondern die Datenleitung der Karte bleibt oben und der Host samplet in dieser Zeit den High-Pegel der SOMI/DO Leitung ein, bis er eine Response der Karte bekommt. Die Karte darf zwischen 1 bis max. 8 Units von 8 Clock-Zyklen "busy" sein bevor die Response auf das CMD kommt. Das heisst, du wirst zwischen 1 bis 8 Mal "0xFF" einsamplen müssen bevor die Response oder das Start-Token für die Daten kommt. Je nach Karte dauert diese Zeit NCR (Command Response) wie gesagt zwischen 1*8 Clock Zyklen und 8*8 Clock Zyklen lang. Nach der Response muss bei einem Lesebefehl wie z.B. CMD 17 ebenfalls so lange gewartet werden (NAC). Eine Ausnahme gibt es hier beim Lesen des CID oder des CSD Registers, hier kann die Karte zwischen NULL und 8 solcher Clock-Zyklen brauchen (NCX), es ist also nicht zwingend so, dass an dieser Stelle 0xFF eingesamplet werden, evtl. kommt die Response direkt. Max H. schrieb: > Ich habe das mit dem Filesystem (FS) vorerst aufgegeben und entschieden > mein Glück ohne FS zu versuchen... Ich habe dazu ein Dokument gefunden: > http://www.uni-koblenz.de/~physik/informatik/ECC/sd.pdf > Es hat viele meiner Fragen beantwortet, aber leider noch eine > aufgeworfen: > Bei der Init (S. 14): >> Beispiel-Initialisierung mit ACMD41: >> Send: 0x77 0x00 0x00 0x00 0x00 0x01 (CMD55, das "Prefix" fur ein ACMD) >> Recv: 0x01 (R1-Antwort mit dem "In Idle State"-Bit gesetzt.) > Hab ich das richtig verstanden, dass ich erst die 6 Byte senden muss und > dann ein 0xFF um die Antwort zu lesen? > > Beim Lesen von Daten (S. 15): > Beispiel: >> Send: 0x51 0x00 0x00 0x08 0x00 0x01 (CMD17, Lese Block ab Byte 2048) >> Recv: 0x00 (R1-Antwort: Alles OK) >> Recv: 0xfe 0x4e 0x65 0x72 0x64 0x21 ..... 0xa7 0x22 > Muss ich hier dann nach dem Befehl (6 Bytes) 0xFF senden um die R1 > Antwort zu erhalten und dann so lange 0xFF bis ich den Data Token 0xFE > erhalte und dann noch 512+2 (Daten + CRC) mal bis ich alle Daten habe.
Danke für deine Antwort, ich habe es aber mittlerweile geschafft die SD-Karte zu Initialisieren und zu lesen.
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.