Hallo, das ist jetzt mein erster Beitrag. Ich bin gerade dabei eine SD Ansteuerung mit dem Cortex M3 zu schreiben. Ich habe mich dafür entschieden, den SDIO zu benutzen, weil ich glaube, dass dieser die bessere Perfomance bietet, als der SPI Mode. Nun habe ich hier im Forum und auch in einer Beispielbibliothek gesehen, dass dort immer noch die GPIO Pins konfiguriert werden, obwohl ich dachte, dass das der SDIO Controller automatisch macht und ich mir um die PINs keine Gedanken machen muss. Zumindest steht im Manual nichts über eine extra Pinkonfiguration. Was ist also nun richtig? Hoffe jemand kann mir helfen. Die SDIO Ansteuerung verwirrt mich immer mehr. Zumal auch die Doku dazu sehr mager ist und nicht direkt mit der SDIO Libary arbeitet sondern, mit der speziellen SD_SDIO Libary für das Evalboard. Ich bedanke mich schon mal für eure Aufmerksamkeit. Georgy
Hi, immer, wenn du die Alternate Function eines Pinnes nutzen willst, musst du den Pin entsprechend (AF_PP oder AF_OD, oder AIN) konfigurieren. Gruß Lasse
Ich bedanke mich für diese schnelle Antwort. Allerdings erscheint mir die Frage jetzt ganz schön trivial. Grüße Georgy
Trivial? - Clock aufsetzen, - Takte in der (hoffentlich richtigen Reihenfolge) einschalten - Pins konfigurieren - SDIO konfigurieren (am besten erstmal per Poll, alles andere wird ja noch komplizierter..) - SD-Karte anschmeißen wollen und nicht können .....und dann irgendwann merken, daß man irgendeine Kleinigkeit ja doch noch übersehen hat - bloß man findet sie im Dickicht der Doku nicht. Die ist immerhin über 1000 Seiten lang und jeden einzelnen Mist muß man sich dort mühsam aus mindestens 10 verschiedenen Fundstellen zusammensuchen. Ach ja, und diese Software-Library von ST finde ich genauso wenig hilfreich, denn man erstickt dort geradezu in zusätzlichen zumeist überflüssigen Definitionen, einem Dickicht von aufgebauschtem Zeug und einem Programmierstil, vor dem es mich graust. Naja, schreib mal, wenn du deine erste SD-Karte gelesen hast. LiGrü wolf
Lasse S. schrieb: > immer, wenn du die Alternate Function eines Pinnes nutzen willst, musst > > du den Pin entsprechend (AF_PP oder AF_OD, oder AIN) konfigurieren. Ist nicht ganz korrekt: AIN = Analog Input. Peripherie Outputs werden immer auf AF_PP/AF_OD gesetzt. Inputs bleiben meist auf IN_FLOATING. Manchmal auch IPD/IPU. In Kapital 8.1.11 gibt es eine Tabelle, wie die Ports für die jeweilige Peripherie konfiguriert werden müssen.
In der StdPeriphLib von STM gibt es eine Beispielanwendung für SDIO (Project/Examples/SDIO). Dieses nutzt Funktionen aus Utilties/Common/stm32_eval_*_sd.c/.h Konfiguriert man das Beispiel z.B. für das STM3210E Eval.-Board (include-Pfad setzen, stm3210e_eval.c in Projektliste/Makefile aufnehmen), wird SDIO als Schnittstelle verwendet. GPIO Konfiguration - ist nicht viel, soweit gesehen nur "tri-staten" - findet sich in stm3210e_eval.c. Etwas besser ist das aber auch schon in der readme.txt-Datei im Beispielverzeichnis beschreiben. Im Zweifel erst mal das Beispiel aus der SDIO StdPeriphLib nur soweit anpassen, dass es auf der vorhandenen Hardware korrekt durchläuft. Sobald das funktioniert, kann man eine Dateisystem-Library verwenden (z.B. DOSFS, FatFs...), die auf die Write/Read(Multi)-Block(s) Funktionen in stm32_eval_sdio_sd zurückgreift.
So, da bin ich wieder mit einer neuen Frage dazu. Weiß jmd. ob die die StdPeriphLib von ST getestet haben? Zum einen frage ich mich, warum die das Beispiel auf die eval-Libary beziehen und nich auf die Standardlibary, was ja sinnvoller ist. Immerhin wird ja jeder im Stande sein die Pins vom SDIO korrekt zu belegen um den SDIO zu benutzen. Außerdem glaube ich dass das Beispiel so nicht funktionieren kann. Da ich die SD Karte vorher einfach über SPI ansprechen wollte, habe ich mich mit den Grundsätzen einer SD Karte beschäftigt und weiß, dass die eine gewisse Zeit braucht um zu Antworten und um sich zu intialisieren. Aber im Beispiel ist überhaupt keine Wartezeit vorgesehen. Also irgendwie ist die fast gar nicht zu gebrauchen. In der Doku steht auch nur unwichtiges Zeug drin und im User Guide wurde auch kein Wort über den SDIO verschwendet. Das ganze wird also mehr eine Try and Error Aktion. Ich werde davon berichten, aber wahrscheinlich in einem Extra Thread. Gruß Georgy
Hehe... Die StdPeriphLib ist eher zu Schulungszwecken geschrieben worden. D.h. der Code ist breit ausgewalzt und sehr ausführlich, aber wenig effizient. Ich hatte bei der Portierung auf Nut/OS auch gedacht, einfach die Dateien so zu nehmen, wie sie sind und mich mit ST sogar auf einen Lizenzheader geeinigt, damit Nut/OS weiterhin BSD bleiben kann. Im Nachhinein ist von den Libs wenig übrig geblieben da der Code viel zu komplex und ineffizient war. Nachdem ich zuerst ( zum Lernen) die StdPeriphLibs verwendet habe und sie dann Stück für Stück optimiert habe, habe ich zuletzt die Treiber mehr oder weniger von Null auf geschrieben. Das wäre der Weg, den ich Dir auch empfehlen würde. Such Dir ein Bespiel aus dem mitgelieferten Material oder den AppNotes von STM und versuche es ans Laufen zu bekommen. Dann optimiere es. Bei den STM3210x-EVALs ist jeweils eine SD-Card dabei und wird vom Beispielcode auch angesprochen. Es funktioniert also. Ich habe noch SPI und Ethernet vor mir in der Portierung, SD-Card ist danach dran. Aber vielleicht hast Du Lust mit zu machen und Deinen SD-Treiber zur Verfügung zu stellen. Gruß, Ulrich
Ich werde mein bestes geben, aber dank der Libary wird meine SD Karte als MMC erkannt und dann ein Fehler geworfen. Eben weil keine Wartezeit eingebaut ist. Muss also viel viel ändern. Wie du es gesagt hast, werde ich es wahrscheinlich alles selber schreiben müssen. Wenn es dann fertig ist, stelle ich das gerne bereit. Gruß Georgy
Hi! Nein, ich würde, wenn ich mich mit dem Cortex nicht schon sehr gut auskenne, erst mal das Beispiel fixen. Beachte, dass es bereits eine neue StdPeriphLib gibt, sie ist nicht unbedingt bei jedem STM3210x-EVAL zu finden. Ich habe hier ein STM3210C-EVAl Kit, dessen downloadbare Lib war noch eine alte 3er Version. Zur gleichen Zeit stand für das STM3210E-EVAl bereits eine neue 4er Version zur Verfügung. Ich habe mich dann für beide Kits bei der 4er bedient. Ach so, zu Deiner ersten Frage: Du musst zuerst die RCC Clocks freischalten für die entsprechende Peripherie, und die GPIO Bank an der die Peripherie genutzt werden soll. Dabei nicht vergessen, die Alternate-Clock für den GPIO zu aktivieren. Dann kannst Du die Pinne in die entsprechende Richtung setzen. Zuletzt programmierst Du die Pinkonfiguration der Peripherie im AFIO Register, falls es mehrere Alternativen gibt. Wenn Du diese Reihenfolge nicht ein hältst, dann wird das nix. Gruß, Ulrich
Ich hab mich glaube nicht richtig ausgedrückt. Ich werde selbstverständlich die Libary als Vorlage nehmen. Aber ich werde nicht einfach Copy und Paste machen. Erstens brauche ich nicht alles daraus und zweitens funktioniert ja auch nicht alles. Das was ich daraus nehme, werde ich dann auch ändern müssen. Vielen Dank trotzdem für deine weiteren Erklärungen. Gruß Georgy
Georg Leuschel schrieb: > So, da bin ich wieder mit einer neuen Frage dazu. > Weiß jmd. ob die die StdPeriphLib von ST getestet haben? Wäre traurig, wenn nicht. > Zum einen frage ich mich, warum die das Beispiel auf die eval-Libary > beziehen und nich auf die Standardlibary, was ja sinnvoller ist. > Immerhin wird ja jeder im Stande sein die Pins vom SDIO korrekt zu > belegen um den SDIO zu benutzen. Hmm, wenn Eval.-Board und Beispielsoftware dazu aus dem selben Stall kommen, erwarte ich schon, dass die Beispielsoftware ohne Weiters mit dem Board funktioniert. Die StdPeriphLibrary selbst bezieht sich auf Funktionen des Controllers, die 'Utilities' auf Code zur Ansteuerung externer Komponenten. Die Gemeinsamkeiten sind ja wieder in 'common' zusammengefasst und nur das Eval-Board-Spezifische befindet sich in den entsprechenden Unterordnern/Dateien. Finde das so ganz brauchbar, da man in den Board-spezifischen Dateien erkennen kann, was man für andere/eigene Boards beachten und anpassen muss. (Ist in den AT91 Software-Packages ähnlich.) > Außerdem glaube ich dass das Beispiel so nicht funktionieren kann. > Da ich die SD Karte vorher einfach über SPI ansprechen wollte, habe ich > mich mit den Grundsätzen einer SD Karte beschäftigt und weiß, dass die > eine gewisse Zeit braucht um zu Antworten und um sich zu intialisieren. > Aber im Beispiel ist überhaupt keine Wartezeit vorgesehen. Ich habe die SDIO-Beispiel mangels Hardware nicht ausprobiert. Aber auf vorhandene Hardware angepasste Versionen der SD (SPI)-Beispiele haben hier funktioniert. Habe aber damit nur wenig gespielt, da selbst anderen Low-Level-Treiber für SD-Karten über SPI im Einsatz. Es gibt im SDIO-Code durchaus so etwas wie "Wartezeiten", leider aber nur über Schleifenzähler implementiert (z.B. count in SD_GetResponse, timout in WriteBlock) ohne Rücksicht auf Frequenzeinstellungen. (So etwas findet man aber z.B. in Beispielen von NXP, Keil/ARM u.a. auch). Man will die Anwender beim Code-Recycling/Copy-Paste-Programmieren wohl nicht mit Abhänigigkeiten von Systick oder anderen Timern belasten. >... Georg Leuschel schrieb: > Ich werde mein bestes geben, aber dank der Libary wird meine SD Karte > als MMC erkannt und dann ein Fehler geworfen. Eben weil keine Wartezeit > eingebaut ist. Schleifenzähler für retry-Loops und delay-loops testweise etwas erhöht und oder Frequenzen verringert? Mit anderen Karten ausprobiert? Hardware ist ein STM-Eval.-Board oder hat zumindest eine mit einem Eval-Board identische Anbindung zur Speicherkarte? >...
Nein, es ist ein vollkommen selbst entworfenes Board mit einer SDIO Anbindung. Deswegen will ich nicht die Eval-Board-Libary nehmen. Ich werde das einfach mal ausprobieren. Gruß Georgy
So da bin ich wieder. Nach 3 Nachtschichten kann nun folgendes berichten: Es funzt immer noch nicht. In der ersten Nacht habe ich noch meine eigene Software genommen. Hat nicht funktioniert. Ich habe festgestellt, dass er die Statusbits nach dem Kommandosenden nicht setzt. ==> Er sendet keine Kommandos? Am 2. Abend habe ich den Schaltplan überprüft, aber die Bitzuweisung ist korrekt und die Spannungs- bzw. Frequenzmessungen ergaben zumindest dort korrekte Funktionalität. Heute habe nun die Brechstange ausgepackt: Mir das Package SD_FAT (Anhang) runtergeladen, eingebunden, Einstelltungen vorgenommen und ... immer noch nichts. Er ändert nie seinen Zustand. Durch das Kommando 55 sagt die Karte, das dies ein illegales Kommando ist. Nun bin ich völlig überfragt und habe auch so langsam keine Lust mehr. Es ist frustrierend. Ich bin im Internet auf die Begriffe SPI und SD Mode gestoßen. Meine SPI Ansteurung hatte auf einem anderen Board auch mit der selben Karte funktioniert. Nur kommt SPI hier nicht in Frage, da alle SPIs bereits in Verwendung sind. Allerdings findet man im Internet nichts zu dem SD Mode geschweigedenn zum SDIO. Was ich immer noch nicht verstehe ist, warum in der SD_FAT Bibliothek keine Wartezeiten für die Initialisierung vorgenommen werden. Hat da einer eine Erklärung für mich? Oder hat generell jmd. einen Rat, Hinweis oder Schulterklopfer? Viele Grüße Georgy
Hi, komisch, vor allem, weil das SD-Kartenbeispiel aus der FWLib eigentlich funktioniert. Zeig doch mal deinen Schaltplan. Hast du schonmal ausprobiert, allen anderen Code aus deinem Projekt zu entfernen? Vielleicht machen sich da ja zwei Sachen gegenseitig kaputt? Gruß Lasse
Guten Morgen, ja das mit dem Schaltplan ist so ne Sache. Genau genommen ist es nicht meiner und ich glaube nicht dass ich ihn reinstellen darf. Aber du kannst mir glauben, dass derjenige der sich das Ding ausgedacht hat, ein wahrer Elektronikgott ist. Also am Schaltplan liegt es denke ich mal nicht. Allerdings werde ich mal die Sache mit dem Stand-Alone ausprobieren und alle anderen Anwendungen ausschalten. Aber erst nach dem WE. Gruß Georgy
Georg Leuschel schrieb: > Nein, es ist ein vollkommen selbst entworfenes Board mit einer SDIO > Anbindung. Deswegen will ich nicht die Eval-Board-Libary nehmen. > Ich werde das einfach mal ausprobieren. > Du kannst das EVAL-Board Beispiel durchaus nehmen, denn es wird sich in den Hauptsachen nicht von Deinem Code unterscheiden. Anders als bei anderen CPUs konfiguriert man nicht einen Pin auf eine Peripherie, sondern man sagt der Peripherie, welchen Satz Pinne sie verwenden soll, also die Alternate-Config. Egal, wie Deine Hardware also aussieht, Du musst ggf. nur in der Config des SD-Interfaces den richtigen Satz Pinne auswählen. Wenn Du zusätzlich noch GPIOs verwendest, die Card-Insertion und Write-Protection abfragen, so musst Du Dir dazu zuerst keine Gedanken machen, denn das wird auf den EVAL-Boards nicht unterstützt. Du kannst es dann später hinzufügen. Beachte ggf. auch Deine SYSCLK/PLL/AHB Einstellungen. Die SD-Card Peripherie nutzt die SDIOCLK und die wird direkt vom AHB Prescaler abgeleitet. Gruß, Ulrich
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.