Hallo, ich habe den Arduino Due mit dem SAM3X8E und programmiere den mit dem Atmel Studio. Nun will ich eine SD-Karte anschließen und die AFS-Funktionen dafür nutzen. Das Beispiel für den SAM3X habe ich gefunden, leider geht daraus aber nicht hervor, wie die SD-Karte hardwaremäßig an die Ports anzuschließen ist. Da es ein SPI-Bus ist, dürften die Ports für SPCK, MOSI und MISO klar sein (PA27, PA26, PA25). Aber welcher Port wird für den CS benutzt? Für den SPI gibt es 4 Signale NPCS0-3 die auf verschiedene Pins gelegt werden können. Wie kann ich herausbekommen, welchen NPCSx das Example benutzt? welcher Port dazugehört, könnte ich notfalls aus den Statusregistern für die Portdefinitionen auslesen. Außerdem weiß ich nicht, ob der Modus für 4 getrennte CS-Pins oder der für einen Decoder, mit dem man dann bis zu 15 SPI-Slaves anschließen kann, benutzt wird. Noch habe ich auch keine Defines gefunden, mit denen der CS-Pin definiert wird, ebenso die Pins für carddetect und writeprotect. Der Code für SD-Karten scheint sehr universell ausgelegt zu sein, da müßten die Pins auch konfigurierbar sein. Doku dazu kann ich aber nicht finden, erst welche für die Funktionen in fatfs, z.B. zum öffnen und lesen einer Datei. Das ist aber schon ein Layer höher und hat nichts mehr mit den Portpins zu tun... Leider ist die Suche nach den Defines nahezu hoffnungslos, solange man nicht weiß, die die heißen könnten. Für den ATMEGA gibt es mehr Informationen, aber nicht für den SAM3X8E. Gruß
Andreas W. schrieb: > Das Beispiel für den SAM3X Zu einem Beispiel Code gibt es auch ein Beispiel Board, und davon meistens auch den Schaltplan. Dort kann man sich dann die Pinbelegungen raussuchen.
Außerdem könnte man Beispiel Code auch mit dem Debugger durchsteppen...
Hallo, war nicht leicht, überhaupt herauszukriegen, welche Hardware zum Beispielcode gehört. Das Schaltbild ist dann leider überhaupt nicht hilfreich: die SD-Karte wird nicht per SPI angesprochen, sondern offensichtlich mit 4 Bit parallel. Die Fassung in der Schaltung hat aber 14 Pins, eine SD-Karte aber nur 9, hinzu kommen noch carddetect und writeprotect, in der Schaltung gibt es noch weitere Signale... Ich habe aber noch einen LPCXpresso incl. dazugehöriger Entwicklungsumgebung, der aber nicht mehr ausreichte. Aber damit hatte ich schon eine SD-Karte erfolgreich ansprechen können und der Code ist wesentlich verständlicher als der von Atmel. Wichtig sind vor allem die Low-Level Funktionen disk_status - Get device status disk_initialize - Initialize device disk_read - Read sector(s) disk_write - Write sector(s) disk_ioctl - Control device dependent features get_fattime - Get current time die direkt auf die Karte zugreifen. Die entsprechenden Atmelfunktionen sind überhaupt nicht zu verstehen, die vom LPCXpresso dagegen sind sehr klar, da sind die benutzten SPI-Funktionen leicht zu finden. Und in den SPI-Funktionen kann ich selber festlegen, welche Pins ich benutze. Also werde ich die Source davon in mein Projekt übernehmen und versuchen, ob die FatFs Funktionen damit zusammenspielen. Wenn nicht, nehme ich auch noch die vom LPCXpresso... Das liefert bestimmt erheblich schneller eine funktionierende Lösung als wenn ich mich mit den Atmelfuntionen weiterquäle. Es ist ja nicht einmal gesagt, daß eine SPI-Lösung für SD-Karten vorhanden ist... Den Debugger habe ich bisher noch nicht erfolgreich verwenden können, zuerst überprüfte ich angesprochene Pins mit dem Scope bis schließlich das LCD funktionierte, dann konnte ich das für eine Art "printf" mit Debuggerergebnissen benutzen. Inzwischen läuft schon ziemlich viel, neben dem 7"-LCD mit Touchscreen ein optischer Drehgeber, IIC-Bus, ADC, Batteriemanagement, SPI-Bus usw. Gruß
Andreas W. schrieb: > die SD-Karte wird nicht per SPI angesprochen, sondern > offensichtlich mit 4 Bit parallel. Das wäre dann SDIO, dann müsste IMO auch der CS Pin feststehen - da er dann zur SDIO Schnittstelle mit dazu gehört. Andreas W. schrieb: > [...]die direkt auf die Karte zugreifen. Die entsprechenden Atmelfunktionen > sind überhaupt nicht zu verstehen Wieso nicht? Zeigt Dir Deine IDE nicht den dahinter liegenden Code an? Wenn das SDIO und nicht SPI ist, müsste man sich das Handbuch daneben legen, das hätte ich auch nicht im Kopf. Das heisst beim ATSAM3X8E übrigens "HSMCI". Damit stehen IMO auch die Pins für die SD Karte fest. Andreas W. schrieb: > Den Debugger habe ich bisher noch nicht erfolgreich verwenden können, Dann nimm dir mal Blinky vor bis Du es einzeln durchsteppen kannst. Der Debug Stecker ist der kleine (1.27mm Raster für Cortex M) 10-polige. Das will man bei Cortex M eigentlich immer haben.
Hallo, die Atmelfunktionen enden irgendwann bei irgendwelchen Macros, die den Datentransfer machen, heißt irgendetwas mit MEM_2_RAM, verfolgt man das weiter, kommen weitere Macros, die auch USB im Namen enthalten. Zu Funktionen, die dann wirklich den Zugriff machen, komme ich so nicht. Wenn das Ganze dann noch mit DMA gemacht sein sollte, ist eine Codeanalyse kaum noch zu schaffen, da ist der andere Code einfacher implementiert. Geschwindigkeit spielt keine so große Rolle. außerdem brauche ich den SPI auch noch für andere Bausteine, der SAM3X8E hat nur eine SPI-Schnittstelle, die auf externe Pins herausgeführt wird. Die SD-Karte bekommt noch einen Tristatebuffer, der mit dem CS gesteuert wird, falls Signale (SPCK und MOSI) für andere Devices stören sollten. Der Anschluß mit SDIO geht bei mir nicht, da die Pins dafür teilweise schon vergeben sind. Zum Flashen habe ich den Atmel ICE mit dem kleinen 10poligen Kabel. Trotzdem hakt der Debugger irgendwie, irgendeine Projekteinstellung scheint diesbezüglich nicht zu passen. Gruß
Hallo, mit den Atmelfunktionen kam ich nicht weiter. Wohl aber mit dem Quelltext vom LPCXpresso. In mmc.c mußte ich die SPI-Funktionen an meine Hardware und meine SPI-Treiber anpassen, die Sourcen für Funktionen wie f_open usw. konnte ich unverändert übernehmen. Nach einigen weiteren Anpassungsproblemen und vor allem den fiesen Fehler, daß in der SD-Fassung, die bereits mal funktioniert hatte, der Anschluß für MISO am falschen Pin lag, funktioniert der SD-Kartenzugriff nun. Dann fiel mir ein, daß bei der Fassung ein Draht mal abgerissen war und ich den wieder angelötet hatte - einen Pin daneben... Hat mich fast zwei Tage gekostet, den Fehler zu finden. So bleiben die Atmelfunktionen ungenutzt, so wie auch die anderen Funktionen z.B. für PIO, IIC-Bus, SPI-Bus, ADC usw. auch, für alles habe ich eigene Funktionen geschrieben. Entweder, weil die originalen nicht richtig funktionierten oder weil ich teilweise anch weitere Funktionen brauchte, z.B. mehrere Pins eines PIO gleichzeitig als Datenbus anzusprechen, die Originalfunktionen bieten nur Einzelbits an oder nur Setzen bzw. Rücksetzen mehrere Pins. Der Debugger läuft inzwischen auch, aber erst, nachdem ich einige Pins von PIOB nicht mehr initialisiere, offensichtlich wird wohl ein Pin (oder mehrere) für den Debugger benutzt, Betrifft irgendeinen Pin von PB0-PB15. Die sind bei mir unbenutzt, wurden aber vorher als Inputs definiert, was den Debugger blockierte, sobald die entsprechenden Register beschrieben wurden. Welcher Pin oder welche Pins das genau sind, werde ich noch später erforschen. Gruß
Das Problem ist das sie den Code nicht vernünftig beschreiben. So wie es ausschaut ist dieser schon für den einfachen SPI Mode geeignet. Nur fehlt jegliche Dokumention wie dieser zu benutzen ist. Das was man in dem ASF Framwork findet ist wenig hilfreich. Da ist Frust leider vorprogrammiert ;)
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.