MMC Ansteuerung - Frage bezüglich Code

[Reinhard (Gast)]

Hallo an alle:

Also wie schon so viele vor mir, versuche ich nun, meine MMC Karte dazu
zu bringen, mit meinem mega32 zu kommunizieren.

Ich habe mir die Lösung von Ulrich Radig angesehen und möchte diese
verwenden, da sie mir im Vergleich zu anderen Lösungen noch die
einfachere zu sein scheint.

Ich habe mir auch schon Specs heruntergeladen (eine von Toshiba und
eine von Hitachi) und mir diese angesehen, trotz alledem gibt es da
eines, was ich überhaupt nicht kapiere und zwar:


Ich verstehe nicht, wie man herausfindet, wie ein bestimmter Command
Byte-mäßig auszusehen hat.

Ich habe gelesen, dass jeder Kommand grundsätzlich 6 Bytes lang ist und
habe mit die Command – Tabelle von Hitachi angesehen, wo die Commands
„beschrieben“ sind.

Daraus kann ich z.B.: entnehmen, dass der CMD24 einen Block auf die
Karte schreibt. Bei Argument steht da:

[31:0] Data Adress

So, ich nehme mal an , dass bedeutet, dass das 32 Bits (4 Bytes sind
mit der Adresse des Blocks, den ich schreiben möchte.


Aber wie komme ich darauf, wie die 6 Bytes des Befehls nun aussehen
müssen?

Ulrich Radig macht das in seiner Ansteuerung so:


unsigned char CMD[] = {0x58,0x00,0x00,0x00,0x00,0xFF};

  /*Die Adressierung der MMC/SD-Karte wird in Bytes angegeben,
    addr wird von Blocks zu Bytes umgerechnet danach werden
    diese in das Commando eingefügt*/

  addr = addr << 9; //addr = addr * 512

  CMD[1] = ((addr & 0xFF000000) >>24 );
  CMD[2] = ((addr & 0x00FF0000) >>16 );
  CMD[3] = ((addr & 0x0000FF00) >>8 );

Dass die Adresse mit 512 multipliziert wird, um die Anzahl der Blöcke
in Anzahl der Bytes zu verwandeln, versteh ich ja noch.

Was ich aber nicht mehr durchschaue ist:
Woher bekommt man den Wert des ersten und des letzten Bytes (0x58 bzw.
0xFF)  ?

Und was genau passiert da beim Einfügen der Bytes in das Command.
Also wie diese ganzen Shifting Operationen arbeiten, weiß ich schon,
aber nicht die Idee des Programmes dahinter..

Bitte seid so freundlich und helft mir ein wenig weiter. Ich steh da im
Moment vor einer Mauer..

[Reinhard (Gast)]

Will mir denn keiner helfen?! Es ist ziemlich dringend ;-(

[Daniel N. (bipak)]

Wenn ich mich richtig erinner, war das 1. Byte 0x40 + commandzahl.
Kommando 1, wäre dann also 0x41.

Das letzte Byte ist die Checksumme und beim SPI Betrieb immer 0xFF.
Ausser bei der initialisierung ist sie 0x95.

Mit dem Bitshifting der CMD's, wird die 32Bit Adresse in 4x8Bit
aufgeteilt.

Gruß,
Daniel

[D. W. (dave)]

Zu dem 0x58 weiß ich noch:
Zieh davon mal 0x18 (24) ab... dann kommste auf 0x40 :)
CMD0 hat entsprechend 0x40,
CMD1 hat 0x41...usw.
Das 0x40 war glaub irgendnen Bit, musste halt mal nachlesen.
Wichtig ist nur, dass die Commands immer nen Offset von 0x40 haben.

Was das letzte ist, weiß ich nicht (mehr).. ist schon lange her.

Das mit dem Shifting ist nur dazu da, dass die Karte weiß, ab welchem
*Byte*-Offset sie lesen/schreiben soll.
Dateisystem hantieren immer nur mit 512Byte-Blöcken, kleiner denken sie
nicht. Die Karte kann aber 1Byte, deswegen wird z.B. der Block Nr. 12 zu
Byte Nr. 6144. = 0x1800 und dies muss jetzt mit BigEndian geschrieben
werden. 0x00; 0x00; 0x18; 0x00 und dafür sind die Shifts
verantwortlich.

Sorry wegen Rechtschreibung und Syntax :) ihr dürft die Fehler
behalten.

Ich hoffe außerdem, dass das ungefähr hinhaut.

[Ulrich Radig (Gast)]

Hallo,

0x58 ist das Kommando 24 (CMD24 Write Block)

b01011000
 0          Start Bit immer 0
  1         Transmission Bit immer 1
   xxxxxx   Commando

b01011000 = 0x58 (Hex)

dann kommen die 4 Bytes für den Block sowie 1 Byte CRC.

Das CRC wird von der Karte nicht ausgewertet. Da dieses nicht aktiviert
wurde. Daher wird dieses nicht errechnet.

Gruss
Ulrich Radig

[Reinhard (Gast)]

Ahhh, super!

Das wirft Licht auf die ganze Sache!

Obwohl ich die Hitachi specification wirklich auf alles mögliche
durchsucht habe, ist mir das wohl entgangen, dass der Comamnd CMD0 mit
0x40 angesprochen wird.

Ok, also baut sich der 6 Byte Befehl auf aus:

1 Byte Kommando --> 4 Byte Adresse des Speicherblocks --> 1 Byte CRC

wobei das erste Byte "Kommando" also weiter unterteilt ist in:

Startbit(0) -->Transmissionbit(1)--> 6 Bit Kommando

Ich danke euch allen!! ;-)

[Reinhard (Gast)]

Ach, noch eines:

"Mit dem Bitshifting der CMD's, wird die 32Bit Adresse in 4x8Bit
aufgeteilt."

Das hab ich nun scheinbar noch nicht ganz durchschaut.

Wie funktioniet diese Aufteilung mit dem Code

CMD[1] = ((addr & 0xFF000000) >>24 );
CMD[2] = ((addr & 0x00FF0000) >>16 );
CMD[3] = ((addr & 0x0000FF00) >>8 );

?

Könnte mir das jemand etwas genaue erklären wie das vor sich geht?!

Wär super!
Danke!

[Reinhard (Gast)]

P.S::

Mir ist klar, dass "FF000000" bier Bytes sind und dass mit der UND
Verknüpfung die drei hinteren Bytes gelöscht werden.

Dann hab ich also das erste byte der Adresse.  Gut.
Und warum, nun das ganze um 24 Stellen shiften?

Danke!

[D. W. (dave)]

long test = 0x12345678;
char test2;

test2 = test;

Und was steht nun in test2? 0x78.

Warum man jetzt shiftet, kannste selbst überlegen.

[Reinhard (Gast)]

Hmm, naja, im "test2" wird wohl nur ein Bytes Platz haben.

Ich bin mir jetzt aber nicht sicher, ob nun 0x12 oder 0x78
drinnensteht.

Aber ich denke, auf das läuft es hinaus oder? Das MSB muss zuerst an
die MMC gesendet werden, also werden die Shifting Vorgänge wohl dafür
sorgen, dass dem auch so ist?!

Bin ich auf dem richtigen Weg oder ist das Mist? ;-)