SD-Karte mit SPI: Warteroutinen

[Nase (Gast)]

Hallo,

ich versuche gerade, eine SD-Karte über SPI einzubinden. Das 
funktioniert ganz gut, aber ich wundere mich über zwei Warteschleifen. 
Die offizielle Spezifikation der SD Association gibt es ja zum 
Herunterladen[1] in etwas abgespeckter Form. Daneben habe ich diverse 
Projekte durchgesehen, etwa den Beispielcode von ElmChan[2] oder die 
Beschreibung von LuckyResistor[3].

In all diesen Quellen finde ich immer wieder zwei Warteschleifen:
1. Nach dem aktivieren des Chipselect der SD-Karte wird solange 0xFF 
gesendet, bis die Karte ihrerseits mit 0xFF antwortet.
2. Nach dem Senden eines Kommandos wird (maximal 10mal) 0xFF gesendet 
und dabei darauf gewartet, dass die Karte mit einem Byte antwortet, bei 
dem das oberste Bit nicht gesetzt ist.

Ich habe eine Quelle von ElmChan angehangen, dort ist das die Funktion 
wait_ready ab Zeile 226 und in send_cmd ab Zeile 371.

Wo finde ich denn dazu etwas in der SD-Spezifikation?!

Es gibt dort zwar einen Abschnitt zum Antwort-Typ "R1b", in dem etwas 
von einem Busy-Signal geschrieben wird:

7.3.2.2 Format R1b
This response token is identical to the R1 format with the optional addition of the busy signal. The busy signal token can be any number of bytes. A zero value indicates card is busy. A non-zero value indicates
the card is ready for the next command.

Aber das steht ja im Gegensatz zur Warteschleife Nr. 2, denn dort wird 
ja gerade gewartet, bis nicht mehr alle Bits gesetzt sind.
Zur Warteschleife Nr. 1 nach dem Chipselect finde ich garnichts in der 
Spezifikation.

Das ist irgendwie unbefriedigend. Was übersehe ich denn da?

Danke und Grüße,
N


[1] https://www.sdcard.org/downloads/pls/
[2] http://elm-chan.org/fsw/ff/ffsample.zip
[3] https://luckyresistor.me/cat-protector/software/sdcard-2/

[Simon B. (zmon)]

Hallo Nase

Unterschiedliche Kommandos erhalten unterschiedliche Antworten.
ELM Chan hat hier eine Tabelle:

http://elm-chan.org/docs/mmc/mmc_e.html

Nach einem Kommando das eine Antwort im R1-Format zurückgibt, kommt 
zuerst eine unbestimmte Anzahl Einsen zurück (0-8 Bytes für SD), darauf 
folgt die R1-Antwort.

Kommandos die mit einer Antwort im R1b-Format reagieren (z.B. CMD12), 
haben eine längere Verarbeitungsdauer, weshalb es bei diesen ein busy 
Signal gibt (DO=0), das es abzuwarten gilt. Bin da selbst schon drüber 
gestolpert.

Auf CMD12 folgt erst eine normale R1-Antwort, dann wird DO so lange auf 
low gezogen wie die Verarbeitung in der Karte dauert. Danach kommt ein 
0xff zurück, Karte ist bereit für das nächste Kommando.

Wo das allerdings in der Spezifikation steht kann ich dir nicht sagen, 
hoffe aber dass ich dir trotzdem helfen konnte.

Schöne Grüße!

[Jim M. (turboj)]

Nase schrieb:
> 1. Nach dem aktivieren des Chipselect der SD-Karte wird solange 0xFF
> gesendet, bis die Karte ihrerseits mit 0xFF antwortet.

Damit wird sichergestellt dass die Karte nicht "Busy" ist. Das könnte 
sie z.B. nach einer Schreibaktion sein.  Normalerweise wartet man nicht 
auf das Ende sondern deselektiert die Karte einfach nach dem Senden der 
Daten.

Nase schrieb:
> 2. Nach dem Senden eines Kommandos wird (maximal 10mal) 0xFF gesendet
> und dabei darauf gewartet, dass die Karte mit einem Byte antwortet, bei
> dem das oberste Bit nicht gesetzt ist.

Ich haber hier Code das 1000 Bytes auf die R1 Response wartet. Erst 
danach sendet die Karte übrigens das Busy Signal.

Nase schrieb:
> Das ist irgendwie unbefriedigend. Was übersehe ich denn da?

Den Teil der nicht öffentlich ist, der mit dem Timing. Deine 10 Bytes 
könnten übrigens näher an der tatsächlichen Spec sein als meine 1000, 
denn in der MMC Spec (4.1, veraltet) kommen nach dem Kommando und vor 
der Response höchstens 8 Dummy Bytes vor. Und der SPI Mode von SD Karten 
und MMC Karten (<=4.3 Spec) sind praktisch identisch.

[Brue W. (brue)]

> 1. Nach dem aktivieren des Chipselect der SD-Karte wird solange 0xFF
> gesendet, bis die Karte ihrerseits mit 0xFF antwortet.

Die Karte "Antwortet" nicht mit 0xFF.
Der SD Standard sieht Pull-Ups vor, d.h. der Ruhezustand ist der dass 
alle Leitungen High sind. Wenn die Karte selektiert wird und man Clocks 
schickt wird man 0xFF lesen, weil die Karte einfach nichts tut. (Ausser 
die Karte ist noch Busy, wie Jim Meba angemerkt hat).

Die Response auf ein Kommando kommt nach SD Standard 1 bis 8 mal 8 clock 
Zyklen (Bytes) nach dem Ende des CMDs (Timing Ncr).

Response R1b ist eine Response R1 bei der die Karte gleich nach der 
Response auf Busy gehen kann, signalisiert indem die Karte MISO auf LOW 
zieht. Man kann dann die Karte deselektieren. Nach dem erneuten 
selektieren kann die Karte MISO wieder auf LOW ziehen, sollte sie immer 
noch busy sein. Die Karte zieht in diesem Fall nach einem Clock mit CS 
low MISO wieder auf low.

Gruss

[Simon B. (zmon)]

Brue W. schrieb:
> Man kann dann die Karte deselektieren. Nach dem erneuten selektieren
> kann die Karte MISO wieder auf LOW ziehen, sollte sie immer noch busy
> sein.

Danke für den Tip!

[Nase (Gast)]

Ich habs nun auch gefunden:
- in der Spezifikation einer SanDisk-Karte und
- im JEDEC-Standard JESD84-B41 (MMC).

Es ist mal wieder etwas frustrierend, zu sehen, wie ranzig 
Industriestandards sind... Das Dokument der SD-Association ist echt 
scheiße. Und damit meine ihc nicht nur inhaltliche Aspekte (abseits 
vom Lizenzgängel der simplified-Version), sondern auch handwerkliches.
Die SD-Association veröffentlicht tatsächlich ein ranziges Word-Dokument 
als Standard, ohne brauchbares (PDF!) Inhaltsverzeichnis, bei dem 
teilweise Inhalt durch Übermalen mit weißen Rechtecken "entfernt" wurde.

[Stefan F. (Gast)]

In den gängigen SD Libraries steckt einiges an Erfahrungswerten drin, 
die über die Spezifikationen hinaus gehen. Du kannst davon ausgehen, 
dass viele SD Karten sich nicht 100% an die Spec halten, und genau dafür 
wirst du Workarounds im Code finden.