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.
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 ;)
