Kann man einen AVR als SD-Kard betreiben (dh. die Firmware auf dem AVR soll die notwendige Emulation uebernehmen). Das scheint mir invers zu sein zur ueblichen Konfiguration von AVR und Speichererweiterung mit SD-Karte. Am Ende soll der AVR im SD-slot verschwinden. Der Zugriff aus der Anwendung koennte dann ueber Files realisiert werden ... oder auch jede elegantere Loesung.
Kommt auf den Host an. Wenn der mit einem SPI-Clock oder 4-Bit-Mode im MHz-Bereich arbeitet, kommt der AVR nicht hinterher.
>Kann man einen AVR als SD-Kard betreiben (dh. die Firmware auf dem AVR >soll die notwendige Emulation uebernehmen). Mit den AT90USB könntest du ein Mass Storage Device über versuchen. Normaler ATMEGA als SD Ersatz ist keine gute Idee;)
Mit 16MHz (XTAL oder RC-oszi) sollte 8MHz SCLK gehen. Die CPU kann sich alle Ressourcen greifen (wie V-USB) ... und das reicht nicht?
USB ist keine Loesung fuer mich, da es im SD-Slot verschwinden soll (ausserdem ist der AVR eine ATmega128RFA1 - leider kein USB dran) Low-speed V-USB ist leider fuer fuer mass-storage nicht zugelassen ... aber genau so stelle ich mir den Betriebsmode als SD-Karte vor.
sdcard_emu schrieb: > Mit 16MHz (XTAL oder RC-oszi) sollte 8MHz SCLK gehen. Jap, dann haste genau 16 Takte, das eingegangene Byte zu verarbeiten und dein Register mit der Antwort upzudaten. Was soll das eigentlich werden?
Moin, passt der PC den Takt nicht an die SD-Karte an, damit auch ältere, billige, schwachbrüstige Karten eine Chance haben? Beste Grüße, Marek
Wenn man Wiki trauen kann, dann haste da ein Problem:
Wiki: sd-card
In der SD-2.00-Spezifikation sind folgende Geschwindigkeitsklassen
("speed classes") als minimale Schreibgeschwindigkeiten[19][20]
definiert:
Class 2: 16 Mbit/s (2 MB/s)
Class 4: 32 Mbit/s (4 MB/s)
Class 6: 48 Mbit/s (6 MB/s)
Class 10: 80 Mbit/s (10 MB/s) (erst nachträglich in Version 3.0
definiert)
.2 Takte SPI-reg -> cpu-reg .2 Takte cpu-reg -> SRAM schreiben 11 Takte fuer die ISR zum reagieren .1 Takt Reserve ......... klingt machbar, wenn auch wenig Reserve ---- Ziel ist speed-class Class 0 (dh. langsames "legacy") im SPI-mode ---- Es scheint, dass am Anfang im Card Identification Mode mit 400kHz clock angefangen wird und alles weitere mit der SD-Karte ausgehandelt wird.
Die "Simplified Physical Layer Spec" kann man sich bei sdcard.org kostenlos saugen: https://www.sdcard.org/downloads/pls/simplified_specs/ Und da stehen dann u.a. drin, dass der Host über die Geschwindigkeit entscheidet, und ob es SPI oder das SD Protokoll sein soll. In jedem Fall schaltet er nach der Initialisierung auf 25 MHz hoch (20 MHz bei MMC) - so schnell kann dein AVR bestimmt nicht mehr auf Pin-Änderungen reagieren. Ich lese beim ATmega128RFA1 was von 16 MHz maximalem Takt. So wie ich das lese, wäre selbst ein 50MHz µC überfordert, wenn er das SD-Protokoll in Software abbilden soll. In was für ein Gerät wolltest Du Deinen AVR einstecken? Einige wenige arbeiten mit so langsamen SPI Takt, dass das sogar tun könnte.
@Jim ... Ich kann diese feste Umschaltung auf 25MHz so nicht (auf die Schnelle ) herauslesen ... waere schoen, wenn Du die Seitennummer fuer mich haettest. (ich lese gerade "Part 1 Physical Layer Simplified Specification Ver3.01" / May 18, 2010). Ziel-Gereaet = Tablet ... im Moment muess es aber nur in meinen Schlepptop
sdcard_emu schrieb: > Am Ende soll der AVR im SD-slot verschwinden. Wie soll das den mechanisch aussehen? Wird das nicht zu dick?
Zum Anfang soll es nur Standard SD-card mit 2.1mm Bauhoehe sein ... mit 0.5mm FR4 + 0.9mm IC erwarte ich keine grossen Probleme.
>Es scheint, dass am Anfang im Card Identification Mode mit 400kHz clock >angefangen wird und alles weitere mit der SD-Karte ausgehandelt wird. Bei einem PC oder Kartenleser aber nicht im SPI Mode sondern über 1 Wire SDIO. Damit wird die Karte initialisiert und wenn möglich auf 4 Wire oder mehr umgeschaltet. Der SPI Mode wird von PCs oder Kartenlesern gar nicht benutzt.
Einzige Chance für den Atmega wäre, im CSD-Register den Parameter TRAN_SPEED auf einen möglichst kleinen Wert zu setzen, z.B. 100 oder 400kHz. Da das gegen die SD-Karten-Norm verstößt, kann ich nicht sagen, ob der PC-Kartenleser sich darum schert. Möglicherweise legt er trotzdem mit 25MHz los. SPI muss die Kartenemulation nicht können, weil der PC das SD-Protokoll verwendet. Wide Bus (4-bit Datenleitung) muss die Karte wohl unterstützen, das wird der PC mit Sicherheit auch nutzen. Ohne zusätzliche Hardware (CPLD,FPGA) wird es wohl kaum gehen. Gruss Mike
Marek N. schrieb: > passt der PC den Takt nicht an die SD-Karte an, damit auch ältere, > billige, schwachbrüstige Karten eine Chance haben? Auch "schwachbrüstige" Karten können den vollen SPI-Takt ab und damit viel mehr, als du mit Software in einem AVR je erreichen können wirst. Sie brauchen wahrscheinlich länger, bis sie eine Schreiboperation zurückmelden. Bei SPI entscheidet allein der Master über die Geschwindigkeit; der Slave hat keine Chance, da irgendwie etwas "auszubremsen". Ein SPI-Slave ist letztlich erstmal ein Schieberegister, und sowas lässt sich schwer in Software nachbilden (so es denn einigermaßen schnell sein soll).
Zusätzlich werden SD-Karten im PC üblicherweise nicht im SPI-Mode angesprochen. Das ist eine Krücke für uns Embedded-Leute, da einfach (weniger Leitungen, Hardwaremodule in fast allen Prozessoren und nur optionale CRC) und der 4-bit mode der Lizensierung unterliegt. SPI ist auch kein "Backup-Mode" sondern, rein optional. Ich würde also sagen, dass du dir um SPI keine Gedanken machen brauchst.
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.