Hallo.
Ich darf freudig verkünden: ich habs nach unzähligen Stunden geschaft
:-)
Ich habe hier einen ATMega128 @ 8MHz, der freudig 4-bit-parallele Daten
aus der SD-Karte ließt bzw in die Karte schreibt.
Der Modus ist vor allem interessant, weil er bei sinnvoller Nutzung
recht hohe Datendurchsätze zulässt. Im gegensatz zur SPI-Ansteuerung
dürften auch die Kompatibilitätsprobleme kleiner werden.
Meine Grundlagen:
- Google Suche nach "acmd6 crc" liefert das wichtigste:
- Zum eines war da das Datenblatt der SD-Karten:
http://www.sdcard.org/about/memory_card/pls/
- Zum anderen ein Oszi-Projekt, das freundlicher Weise den SD-Karten
Modus mit 1Bit Busbreite verwendete (für was auch immer):
http://www.altera.com/literature/dc/2006/c3b.pdf
Der Code wurde dann von mir umgearbeitet, sodass er gleichzeitig 4bits
in die SD-Karte schaufelt.
Performance: Grottenschlecht. Leider.
Schreiben: 52.5kb/s
Lesen: 136.5kb/s
Der Code ist recht allgemein gehalten. Man kann die
Kommunikatoinsleitungen quasi beliebig an den AVR anschließen. Man
müsste zum Schluss nur die Konfiguration für die Pins und die Ports
ändern.
Auch mein Testaufbau hier ist schlecht designt. Die 4 Datenleitungen
liegen nicht nebeneinander an einem Port, sondern getrennt.
Dies verursacht unnötigen Overhead beim rekonstruieren des gesendeten
Bytes - jedes bit muss einzeln eingelesen werden. Sinnvolller wäre es
die Leitgungen so zu legen, dass gleich die Nibbles an der richtigen
Stelle ankommen. Sö könte man ein Byte u.U. innerhalb von <10 Takten
einlesen.
Problem beim Schreiben ist die aufwendige CRC-Berechnung. Diese kann
jedoch nicht wie im SPI-Modus einfach abgeschaltet werden. Leider.
Auch der Resourcen-Verbrauch ist relativ hoch. Die CRC Tabelle sowie die
SD-Kommando-Vorlagen liegen im SRAm (z.Z.) Dies könnte man aber ohne
Weiteres in den Flash legen. Da kommt der Code auch mit weniger als
600Byte SRAM aus ;-)
Sorgen machen mir rechtliche Geschichten. Der SD-Modus ist ja eigentlich
Lizenzpflichtig. Jedoch habe ich nur öffentliche Quellen verwedet.
kA. Wenn es Andreas zu heikel ist, soll der den Anhang löschen, auch ok
;-)
Man kann mich dann ja immernoch per email kontaktieren.
Der Code ist eigentlich relativ leicht verständlich. Interessant fände
ich jetzt Optimierungsvorschläge von euch! Ich werd mich zwar selber
nochmal ran machen (später) aber vllt fällt einem anderen ja mehr mist
auf, als mir.
Hmmh das wars eigentlich erstmal von mir.
Ich hoffe auf super Vorschläge oder interessante Fragen von euch usw..
MFG
"Any implementation of the Simplified Specification may require a license from the SD Card Association, SD Group, SD-3C LLC or other third parties." Spätestens wenn man den Code auf Sourcefore & Co stellen will, sehe ich schon ein rechtliches Problem. Um die Spec herunterzuladen musstest Du ja den Bedingungen zustimmen. Ich selbst habe das Thema SD mittlerweise für meine eigenen Projekte mittlerweise ausgeschlossen. Gruß Jörg
@Jörg: Benutzt Du Alternativen? MMC ist genauso geschützt, CF braucht für viele Anwendungen zu viele Pins, über Memorystick müssen wir nicht weiter reden. Jens
Da ich keine riesigen Datenmengen brauche, benutze ich die Dataflash-bausteine von Atmel. Ansteuerung über SPI ist kein Problem, die Eingänge sind 5V-tolerant. Direkter Zugriff auf jede Zelle geht und es sind zwei RAM-Buffer drin. Zum Datenaustauch mit dem PC habe ich mir einen seriellen Reader gebaut, USB wäre auch eine Variante. Gruß Jörg
>"Any implementation of the Simplified Specification may require a >license from the SD Card Association, SD Group, SD-3C LLC or other third >parties." Ich weiß. Aber was soll man tun? Mein Code basiert nicht auf den Specs, sondern auf der Oszi-Vorlage -> diese wiederrum ist frei per Google zu finden. Wenn man ein wenig Wortglauberei veranstaltet, sag ich ganz einfach, dass es sowieso unmöglich ist "Vereinfachte Spezifikationen" zu implementieren. Spezifikation ist Spezifikation und kein Algorthmus. Ich finde gerade dieser Code macht SD-Karten wieder interessanter. Kein KickHack mnit SPI mehr und die Initialisierung sollte eigentlich auch soweit genormt sein. >Spätestens wenn man den Code auf Sourcefore & Co stellen will, sehe ich >schon ein rechtliches Problem. Habe ich nicht vor, keine Angst. Ich hoffe der Anhang wird auch hier von Google erfasst. MFG
Was mich etwas verwundert, ist dass das Oszi-Projekt den SD-Teil als Programmcode realisiert, obwohl man z.B. die CRC ganz leicht mittels einem FPGA-Funktionsblock machen könnte. Wenn schon ein FPGA da ist.. Privat sehe ich da eigentlich keine rechtlichen Probleme. Die Spezifikation ist ja nicht geheim ("gehackt") und die Lizenzen verstehen sich nicht für Bastelprojekte. Problematisch wirds bei kommerziellen Produkten. Joachim
mann, worüber macht ihr euch gedanken? da steht, es "könnte" eine lizens benötigt werden. der einzige sinn dieses kommentars bei den specs ist, dass niemand, der sagt "ich beruf mich auf die spezifikationen", die lizensfrage umgeht. außerdem gilt: wo kein kläger, da kein richter. und wenn es jemand kommerziell nutzt, so teuer wird die lizens nicht sein. außerdem kann niemand die verbreitung eines von dir ohne verwendung "unfreien" materials geschriebenen programmes verbieten. manche leute sind echt paragraphenparanoid. und außerdem gilt (für mich): freie formate für freie menschen :) sorry für die nichtbenutzung der großschreibetaste ;-)
noah wrote: > und außerdem gilt (für mich): freie formate für freie menschen :) > So denke ich auch: SD -> unfreies Format -> nix für mich Gruß Jörg
man kann die Hardware ja mit einer SPI-Softwareversion verkaufen, die SD-Softwareversion müsste man dann halt verschenken (kein Kommerz) oder im Netz verstreuen heutzutage bekommt man das nicht mehr so schnell aus dem Netz wenns mal im Umlauf ist oder tun die so was so schnell unterbinden lassen? Ich einem Toshiba Datenblatt http://embdev.net/attachment/39390/TOSHIBA_SD_Card_Specification.pdf für eine 256 MB SD-Card ist die Vorgehensweise zum wechseln in den SD-Modus beschrieben allerdings fehlen da Infos zur Datenübertragung und zu der von dir genannten CRC. Sehe ich es richtig das du nur 15 CRC-Summen hast? Wahrscheinlich gibts für 0000 wirds keinen CRC-Summe. Könntest du die Vorgehensweise / Ablauf nach dem Umschalten etwas umschreiben bin in C nicht so bewandert.
oh man wie hab ich so nen alten Beitrag erwischt. Aber vielleicht gibts ja doch noch einige Infos dazu
Also ich sage mal so: viel Helfen kann ich dir da sicher nicht mehr.C ist ja schon eine Hochsprache.. was dort steht wird auch gemacht.. stell dir das mal in ASM vor ;-) So eine richtige Vorgehensweise kann ich nicht beschreiben. Der CRC wird pro Bit berechnet. Man hat also 4 CRCs. Wie die CRCs berechnet werden siehst du auch.. das ist haupstächlich die obere LookUp-Tabelle und unten wird das ver-XOR-t und damit die Tabelle indiziert und das ergebnis dann wieder ver-XOR-t. Frag mich nicht wie man darauf kommt.. das habe ich auch nur abgeschrieben. MFG
Hi, gibt es hierzu schon einen neuen Stand? Was denkt Ihr, läßt sich auf diese Weise eine bessere Performance als mit SPI erreichen? Gruß Tom
Wie hoch soll denn die Performance sein? Ein AVR stößt auch mit 4Bit-Übertragung schnell an seine Grenzen, da er ja noch puffern, rechnen und verpacken muß. Mehr als etwa 500kBit/s wirst Du nicht erwarten können.
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.