SD-Karte via LVDS mit anderen SPI Devices zusammen anbinden

[Andre S. (stollenwerk)]

Hallo zusammen,

ich habe einen existierenden ATmega auf 5 Volt mit mehreren SPI – 
Devices dran. Unter anderem eine Real-Time-Clock und eine SD-Karte. Die 
SD-Karte muss etwas entfernt (~ 20 cm) von der eigentlichen Platine 
positioniert sein, damit man da noch zum Austausch einfach dran kommt. 
Das hatte ich bisher (Schande über mein Haupt) mit Flachbandkabel 
realisiert. Das führte (vermutlich) immer wieder mal dazu, dass das 
Dateisystem auf der Chipkarte kaputt gegangen ist. Jetzt war meine Idee 
die Kommunikation von Hauptplatine zu SD-Karte auf LVDS umzustellen. 
Dabei war dann direkt die zweite Idee auf der Hauptplatine einen 
Umsetzer von 5V Logiksignal auf LVDS und bei der SD-Karte von LVDS auf 
3,3 Volt Logikpegel einzusetzen, um den Pegelshifter zu sparen. Da ich 
bisher aber nicht mit LVDS gearbeitet habe würde ich mich freuen, wenn 
Ihr kurz eure Meinung dazu geben könntet, bzw. habe ich auch noch ein 
paar offene Fragen:

-  Kann ich LVDS als Schnittstelle nutzen, also auf der Hauptplatine per 
TI DS90C401 aus den 5 Volt SPI ein LVDS Signal erzeugen und auf der 
SD-Karten Platine per TI SN75LVDS9637 ein 3,3 Volt SPI Signal erzeugen? 
Gefühlt hört sich das zu einfach an. Ich habe Angst hier etwas zu 
übersehen. In den Datenblättern sind hier immer explizite Beispiele 
gegeben, jedoch nie für den Fall 5 V <-> 3,3 Volt.
-  Muss ich noch eine Schaltung vorsehen, damit ich keine Probleme mit 
der SD-Karte bekomme, wenn kein SPI Signal anliegt ggf. während der 
Initialisierung kein definiertes Signal auf dem LVDS-Kabel? Ich hatte in 
einem Datenblatt eine Schaltung zum Thema Fail-Safe gesehen. Ich hatte 
eigentlich gedacht, dass das nicht nötig ist, bin aber nicht sicher…
-  Wie gehe ich am Geschicktesten mit dem MISO-Kanal um? Hier können ja 
Daten von der SD-Karte oder der RTC kommen. Nehme ich hier einen Chip 
mit Enable Pin, den ich dann an den Chip Select für die SD-Karte klemme? 
Gibt es hier noch etwas anderes zu beachten? Ich habe hier als 
Receiver-Chip nur einen mit Enable-Pin gefunden (DS90C032B). Der 
eigentlich übertrieben ist, da 4 Kanäle.
-  Die Chips geben an bei LVTTL ein Logic High von 2,4 Volt auszugeben. 
Passt das noch für SD-Karten, oder ist das sowieso zu wenig?
Viele Grüße und besten Dank,

Andre

[Dr. Sommer (Gast)]

Das SD-Protokoll (auch bei SPI) benutzt doch eine CRC zur Sicherung der 
Übertragung. Wenn du die Fehler korrekt erkennst und ggf. korrigierst, 
sparst du dir den Hardware-Aufwand. Eine solche Fehler-Erkennung sollte 
man onehin implementieren - manche Karten machen auch bei guten 
Bedingungen Übertragungsfehler...

[Andre S. (stollenwerk)]

Danke für den Hinweis. Ich hatte dazu grade mal auf Elm-Chan weiter 
gelesen und leider gefunden:

"The CRC feature is optional in SPI mode. CRC field in the command frame 
is not checked by the card."
--> http://elm-chan.org/docs/mmc/mmc_e.html

Ich fürchte also, dass ich hiermit leider nicht sicher werden kann...

[Dr. Sommer (Gast)]

Andre S. schrieb:
> "The CRC feature is optional in SPI mode.

Also in der SD Spezifikation (sehr hilfreiches Dokument übrigens) steht 
was anderes (S. 156):

Every SD Card command transferred on the bus is protected by CRC bits. 
In SPI mode, the SD Memory Card offers a CRC ON mode which enables 
systems built with reliable data links to exclude the hardware or 
firmware required for implementing the CRC generation and verification 
functions.
In the CRC OFF mode, the CRC bits of the command are defined as 'don't 
care' for the transmitter and ignored by the receiver.
The SPI interface is initialized in the CRC OFF mode in default. 
However, the RESET command (CMD0) that is used to switch the card to SPI 
mode, is received by the card while in SD mode and, therefore, shall 
have a valid CRC field. [...]
After the card is put into SPI mode, CRC check for all commands 
including CMD0 will be done according to CMD59 setting.
The host can turn the CRC option on and off using the CRC_ON_OFF command 
(CMD59). Host should enable CRC verification before issuing ACMD41.

Du musst also den CRC-Check lediglich nicht abschalten, dann ist der 
auch aktiv.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andre S. schrieb:
> Das führte (vermutlich) immer wieder mal dazu, dass das Dateisystem auf
> der Chipkarte kaputt gegangen ist.
Dein Problem sind vermutlich einfach nur die lausigen Consumer TLC 
Karten. Ich kann dir welche sagen, die ich in weniger als 1 Woche kaputt 
geschrieben bekomme. Generell solltest du eher drauf achten, einen 
namhaften Hersteller einzusetzen: Toshiba, Samsung, Sandisk, Kingston.

Ich kann derzeit XMore Professional pseudoSLC µSD-Karten von Glyn mit 
der Embedded-Firmware sehr empfehlen. Leichter verfügbar und gleich gut 
sind SD-Karten von Samsung. Diese Karten halten ein halbes Jahr 
Dauerbeschreiben mit kleinen Dateien und mehr als 100000 Powerfails aus. 
Die anderen zeigen im Dauertest schon früher Auffälligkeiten.

Die billigen TLC-Consumer-Dinger sind für laufendes Schreiben absolut 
ungeeignet (erste Ausfälle im gleichen Dauertest schon nach ein paar 
Tagen, Komplettausfall nach spätestens 2 Wochen). Ich würde sowas 
bestenfalls in einer Kamera einsetzen. Und die Bilder recht schnell 
irgendwo sichern...

Welche Karten hast du?

[Dr. Sommer (Gast)]

Lothar M. schrieb:
> Generell solltest du eher drauf achten, einen
> namhaften Hersteller einzusetzen: Toshiba, Samsung, Sandisk, Kingston.
Wobei bei meinen Tests nur Samsung-Karten gut waren; Toshiba und SanDisk 
hatten teilweise extrem lange Schreib-Zeiten was für 
echtzeit-Datenlogging nicht so toll ist (wenn hohe Datenraten gefordert 
sind).

[Andre S. (stollenwerk)]

Die Karten sind von Sandisk. Die setzen wir in einem anderen Projekt 
ohne Probleme ein. Der Code ist zum schreiben identisch. Im anderen 
Projekt schreiben wir die Daten mit mehreren hundert MB pro Stunde und 
haben gar keine Probleme. Hier schreibe ich mit ca. 1-2 KB am Tag. Ich 
fürchte, dass das Problem wirklich in der Datenübertragung liegt :-/

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Andre S. schrieb:
> Ich fürchte, dass das Problem wirklich in der Datenübertragung liegt :-/
Wie wäre es mal mit Messen.
Und kein Flachbandkabel verwenden, sondern Einzellitzen in einem 
gemeinsamen Schirm.
Hast du irgendwelche Terminierung? Wenigstens am Takt?
Ist die Versorgung der Karte direkt am Slot gepuffert?