Hallo Besucher, der Thread wurde 8k mal aufgerufen und enthält 18 Antworten

letzter Beitrag von Unseen am

SDIO versus SPI

    Für SD Kartenzugriff könnte man ja SDIO wie auch SPI nehmen. Anscheinend ist SDIO wesentlich schneller, allerdings ist man damit auf SD Karten beschränkt. MMC zB. gehen damit nicht.


    Aber heutzutage gibt doch eh nur noch SD Karten. Spricht was dagegen SDIO zu verwenden (insbesondere da der Controller es unterstützt), oder soll man beim bewährten SPI bleiben. Was mein ihr?

    Wenn es dein Controller unterstützt, kannst du ruhig SDIO nehmen. Nur sehe ich den Sinn darin nicht, bei einem Projekt, indem es um C64 Images geht, mit soetwas zu arbeiten. Mit SD Karten über SPI kann man locker 300-600 kb/s hinbekommen. Mehr sollte (eig.) nicht nötig sein. Oder?


    Ansonsten gibt es keinen wirklichen Grund, der gegen SDIO spräche.

    Also ich würde auch SDIO empfehlen - mal abgesehen von schneller auch deutlich Resourcen schonender.


    Ja, ich weiß - der M4 ist mehr als schnell genug .... aber es gibt so viele andere Dinge die man mit der Zeit anfangen kann ...
    (Was mit so einfällt: QVGA - SPI Display (kostet so ca. 50€) und dann einen Screenshot des Spiels auf der Disk mit anzeigen)
    Wenn man schon passende HW hat sollte ma sie auch benutzen ;-)


    Rechtliche Probleme gibt es da auch nicht.
    Klingt blöd, aber wenn man etwas mit SDIO in den 'Handel' (selbst das trifft whrscheinlich ja nicht zu) bring, muss man Mitglied in der SD Card Association sein (ich glaube die heißt so).
    Wenn es allerdings schon im Micro integriert ist und der Chip Manufacturer Mitglied ist ist das ausreichend (hab' noch irgendwo eine entsprechende Mail rumfliegen - von jemandem der SD Card Association)


    cu,
    Thomas

    Zitat von THaase

    Ja, ich weiß - der M4 ist mehr als schnell genug .... aber es gibt so viele andere Dinge die man mit der Zeit anfangen kann ...


    Na ja, ist es wirklich so ein Unterschied ob die SPI-Einheit die Daten per DMA ins Ram schiebt während die CPU was anderes macht oder ob die SDIO-Einheit die Daten per DMA ins Ram schiebt während die CPU was anderes macht?

    Irgendwie läuft das SDIO bei mir nicht ganz sauber. Verstehe ich nicht, da muss noch etwas ganz grundsätzlich falsch laufen. Mal gehts sauber, dann schmiert die Kommunikation wieder ab, einmal hat es mir sogar die Daten auf einer SD geschrottet. Seltsam ...


    Jedenfalls ist die Alternative ein USB Stick. Den kann man direkt am Discovery betreiben und das funktioniert absolut sicher und einfach.

    Zitat von Diddl

    Anscheinend ein Problem meiner SD Karte. Zwei andere laufen problemlos. Rätselhaft, denn die defekte SD Karte läuft sonst normal. Ab in den Müll ...


    Bist du sicher, dass die Ansteuerung sich in allen Details an die Specs hält? Im SD-Modus gibts ein nettes Zustandsdiagramm, welcher Befehl wann verwendet werden darf; im SPI-Modus kann man jederzeit jeden Befehl schicken.

    Zitat von Diddl

    Ab in den Müll ...


    Würde ich auch auf alle Fälle aufheben, zum Testen. Wenn sie z.B. in einer Digitalkamera funktioniert, ist sie nicht defekt. Digitalkameras benutzen mit 99%iger Sicherheit SDIO, da sollen bei neueren Kameras MBytes in kurzer Zeit geschaufelt werden.


    SDIO hat übrigens auch den Vorteil, dass diese Schnittstelle bei allen Varianten von SD-Karten (micro etc) garantiert unterstützt wird. Das ist bei SPI nicht mehr so, IIRC. Aber da wissen andere sicher mehr.


    Ich tippe auch eher auf ein fehlerhaft implementiertes Protokoll in der Schicht unter FAT. Bestimmte Randfälle behandeln verschiedene SD-Karten wahrscheinlich unterschiedlich.

    Zitat von Unseen

    Bist du sicher, dass die Ansteuerung sich in allen Details an die Specs hält? Im SD-Modus gibts ein nettes Zustandsdiagramm, welcher Befehl wann verwendet werden darf; im SPI-Modus kann man jederzeit jeden Befehl schicken.


    Specs? Ich habe gehofft, dass ich mich damit nicht tiefer beschäftigen muss. Es gibt einiges an Code Ressourcen, aber oft sind die Lizenzbedingungen ungünstig oder unklar.



    Zitat von skoe

    Ich tippe auch eher auf ein fehlerhaft implementiertes Protokoll in der Schicht unter FAT. Bestimmte Randfälle behandeln verschiedene SD-Karten wahrscheinlich unterschiedlich.


    Wird wohl so sein. Der Code scheint von Fehlerbehandlung nicht viel zu halten. Sehr rudimentär und tubios ...

    Zitat von Diddl

    Specs? Ich habe gehofft, dass ich mich damit nicht tiefer beschäftigen muss.


    Muss man auch nicht unbedingt - es gibt genug Karten, die sich in irgendwelchen kleinen Details komisch verhalten. ;)

    Das SDIO Problem scheint gelöst zu sein:



    Inzwischen verwende ich den SDIO Code aus den ST samples. Dieser Code hat zunächst Vor und Nachteile:


    + es geht jede meiner SD und µSD Karten die ich besitze
    - es geht nur im SD_POLLING_MODE und leider nicht im SD_DMA_MODE



    Zum Glück gibts da jetzt einen Workaround mit dem jetzt alles ok zu sein scheint. ^^


    Quelle: klick

    Noch ein Letztes, dann gebe ich endlich Ruhe ... ;)



    Die eine SD Karte die nicht läuft, die läuft wohl tadellos, wenn man auf den DMA_Modus verzichtet. Es gibt sogar einen Kommentar im Sourcecode:


    Code
    1. //Non v2.0 compliant sd's will cause panic here due to the timeout


    Offenbar habe ich eine einzige SD Karte, die nicht "v2.0 compliant" ist.




    Soll ich jetzt auf DMA verzichten damit alle SD Karten gehen? Oder soll ich darauf pfeifen und damit leben, dass manche SD Karten eben nicht gehen? Oder soll man zwei binary Versionen pflegen?


    Oder, - weiss jemand eine andere Lösung?



    Was meint ihr?

    Zitat von Diddl

    Oder, - weiss jemand eine andere Lösung?


    Abfragen ob die Karte 2.0 unterstützt oder nicht und entsprechend dem Ergebnis den DMA-Modus ein- bzw. ausschalten? Könnte man beispielsweise via CMD8 (SEND_IF_COND) machen, das ist in 2.0 neu und muss implementiert sein - und wird sowieso schon irgendwo in der Initialisierung abgesetzt, weil sonst SDHC-Karten den Dienst verweigern würden.

    Es liegt natürlich nicht am DMA an sich, ich habe mich schon gewundert wie die SD Karte das unterscheiden will ...



    Es liegt natürlich an der Transferrate, 48MHz ist einfach zuviel für einige Karten. Leider kann man das nicht am SD Typ klar unterscheiden. Es gibt SDHC Karten die nur mit 24MHz sauber laufen, ich habe auch normale SD Karten die sogar noch mit 48MHz gehen.


    Einige Karten laufen mit 48MHz, aber nicht immer ganz sauber. Also kann man die Erkennung schlecht automatisieren.



    Ich stell die Transferrate jetzt auf 24 und optional, per INI File dreh ich sie rauf auf 48.


    ---------


    Ich muss sagen diese FATFS von ChaN ist genial! Ich verwende die version 0.9 (2011). Es ist sehr fehlertolerant und lässt sich kaum aus Ruhe bringen. Es hat mir nie das Filesystem zerschossen, trotz Schreibaussetzer, offener Operationen und Abbrüche inmitten des Schreibvorgang.

    Zitat von Diddl

    Es liegt natürlich an der Transferrate, 48MHz ist einfach zuviel für einige Karten.


    Ah, klassischer Fall von "hat die Doku nicht gelesen"... Aus "SD Specifications Part 1 Physical Layer Simplified Specification Version 2.00":


    "- Default mode: Variable clock rate 0 - 25 MHz, up to 12.5 MB/sec interface speed (using 4
    parallel data lines)
    - High-Speed mode: Variable clock rate 0 - 50 MHz, up to 25 MB/sec interface speed (using 4
    parallel data lines)"


    "The High-Speed function is a function in the access mode group (see Table 4-9). Supporting High-
    Speed mode is optional."



    Bei MMC ist das Limit übrigens 20MHz und vor der Initialisierung (keine Ahnung wo genau die Grenze war) 400kHz.

    Jetzt höre ich bestimmt wieder: klassischer Fall von "hat die Doku nicht gelesen"


    Aber wenn ich die ganze Doku erst lese, fange ich erst in einem Jahr an zu coden ...



    Diese SDCARD Geschichte treibt mich noch in den Wahnsinn. Jedesmal wenn ich denke, jetzt arbeitet die Geschichte tadellos, dann kommt irgend was Neues daher!


    Nachher ist man immer klüger. Klar findet man die Lösung nach zwei Sekunden googeln. Aber natürlich nur wenn man die Natur des Problems begriffen hat!



    Das DMA des F4 überträgt nur Daten die an geraden Adressen beginnen!! Steht natürlich im Datenblatt. Aber der ganze Samplecode berücksichtigt das nicht. Und man bekommt die lustigsten Fehler. Super!


    Also entweder alle Buffer mit

    Code
    1. __attribute__ ((aligned))

    versehen, oder die DISKIO entsprechend anpassen. Die DISKIO Lösung ist wohl besser, sonst hat man irgendwann in der Zukunft dasselbe Theater, weil man das aligned vergessen hat.

    Zitat von Diddl

    Das DMA des F4 überträgt nur Daten die an geraden Adressen beginnen!! Steht natürlich im Datenblatt. Aber der ganze Samplecode berücksichtigt das nicht. Und man bekommt die lustigsten Fehler. Super!


    Was machst du für komische Dinge, dass deine Puffer nicht mal 16-Bit-aligned sind?
    Edit: Vergiss es, ich war gedanklich bei einer anderen Problemkonstellation - wahrscheinlich hast du char-Arrays und die dürfen nun mal laut AAPCS an jeder beliebigen Byteadresse anfangen.


    Ansonsten: Siehe sauhund. =)