Arge Probleme bei SD Card Anwendungen....

[oderlachs]

Hallo Leute !
Bis lang habe ich nur Allgemeines darüber zu Berichten was mißlingt, aber vielleicht hat wer mit SD-Card Beispielen Erfahrungen oder ähnliche Probleme.

Mal kann die SD Card nicht erkannt werden, Wird sie dann doch erkannt wird sie dann in einem anderen Beispiel (SD-Beispiele) nicht erkannt wenn es geht die File zu listen,
also so ein Durcheinander habe ich noch nicht erlebt.
Ebenso hartnäckig wie auch kurios verhält es sich mit den Erstellen und Schreiben von Files und deren Daten.

Ich werde jetzt nochmals eine neue Arduino IDE-Umgebung installieren und probieren...

Komisch ist auch das ein gleicher IDE Vers. und gleichen SD-Card Beispielen es unter Linux geht aber dann unter Windows eben nicht...

Na ja vielleicht hat ja wer einen Tip oder Rat für mich

Gruss und Dank

Gerhard

[BMS]

Hallo,
habe mich in letzter Zeit auch mit SD-Karten und deren Ansteuerung beschäftigt.
Also ohne Arduino-Umgebung und dafür selber geschriebener Code (aber noch in Arbeit).

Dass es nicht klappt, kann viele Ursachen haben.

Einerseits die Hardware, also z.B.
- vernünftige Spannungsversorgung der Karte
- falls Pegelwandler 5V<->3,3V nötig sind: keine Spannungsteiler, lieber geeignete ICs nehmen
- Leitungslängen und maximale Taktfrequenzen beachten, bei langen Leitungen lieber niedrigere Frequenzen. Manche Karten erwarten sehr steile Flanken.
- nicht alle Karten verhalten sich gleich !!! Evtl. andere Marke probieren. Auch SD/SDHC beachten. Nicht alle Bibliotheken unterstützen die großen Karten
- Pullupwiderstand 10k an DO-Leitung (MISO) und /CS-Leitung.

Andererseits die Software:
- Dateisystem der Karte muss passen, die Bibliotheken verwenden meist FAT16 oder FAT32. Kleine Karten <32MB haben FAT12.
- Initialisierung: Unmittelbar nach Anlegen der Versorgungsspannung. Clock maximal 400kHz. Würde empfehlen, nach jedem Flash-Vorgang auf den Arduino diesen danach kurz aus- und wieder einzuschalten. In meinen Testfällen wollen die Karten nach angelegter Spannung höchstens eine Initialisierung. Danach geht es nicht mehr. Erst wieder nach aus- und einschalten.
- Die Karte kann nach Unterbrechungen in der Kommunikation in einen Stromsparmodus gehen.
- Evtl. Karte neu formatieren

Das sind erst mal ein paar Anhaltspunkte, denen mal nachgehen könnte.

Grüße,
Bernhard

[oderlachs]

Hallo Bernhard !

Habe vielen Dank, ich muss schauen was ich bei den DataloggerShield(Adafruit, alte Ausgabe) vorfinde. Ohne Arduino IDE habe ich noch nicht probiert, weil ich selber auch keine Module so mehr herstellen kann, ich meine Leiterplatten ...Die Entwicklung würde mir zwar nicht schwerfallen, nur eben die praktische Umsetzung. Darum der Ausweich mit Arduino, obwohl ich ach lieber mit C,Cpp und dem STK500 arbeite, bei meinen Projekten und Experimenten...
Wir werden sehen
Gruss und Danke
Gerhard

[robot_moses]

Moin Gerhard,
habe gerade eine ähnliche Erfahrung machen dürfen (;-).
Ich wollte mal kurz die SPI nutzen, um eine SD-Card (nicht Conrad E.) einzusetzen.
Erster Fehler: ich hatte die IDE 2.13 und nicht die 2.40 installiert - Folge: die Beispiele
wurden gar nicht erst übersetzt. Mit der IDE 2.40 geht die Übersetzung, aber über ein
"INIT_OK" komme ich nicht hinaus.
Zweitens steht in dem Manual der CCPro M128-Platine, das wesentliche Signalpins PB0,
PB1, PB2, PB3 für das IC4 (LCD und LED) genutzt werden. Darum habe ich gleich wieder
aufgehört.
Gruss Johann

[oderlachs]

Hallo Johann,
leider kenne ich mich bei Conrad CCPro nun gar nicht aus....

Gerhard

[HaWe]

Es gibt viele gefake-te SDs auf dem Markt, das muss man als erstes ausschließen.

ich hatte auch heftige Probleme mit verschiedenen älteren SD Card Readern, und zwar bei allen meinen 32GB SDs und dachte es läge an den SDs.


Jetzt habe ich 2 neue Reader, 1x zum Einbau und einmal als USB Stick, und jetzt funktioniert plötzlich alles bestens:
Sowohl beim "Full Format" als auch bei FAT/Linux-Partitionen löschen als auch bei Image schreiben lesen!

Bei Arduino gibt es dagegen ebenfalls heftige Probleme, wenn z.B. SPI TFTs am selben Bus hängen.

Um einen SD-Fehler auszuschließen:
Kannst du deine SDs unter Windows "full frormatieren" (nicht Quick" ) ?

[robot_moses]

Moin zusammen,
habe teilweise die Erfahrungen von "BMS" und "HaWe" bezüglich Pegelanpassung und Libs auch machen müssen.
Ich nutze nun eine ATmega328P (Arduino) als SD "Verwalter" und nutze die neue SD-Master-Lib.
Probiere nun eine "Copy-Weg" Atmega328P via I2C auf das extere 64k-EEprom auf die CCPro M128 Unit.
Mal sehen wie das läuft
Grüße Johann

[wkrug]

Mit den SD Karten hab ich auch schon meine Probleme gehabt.
Letztlich war bei mir der Puffer für die Blöcke zu klein.
Ich hatte ständig daten von der seriellen Schnittstelle empfangen und die dann auf die SD Karte geschrieben.
Allerdings braucht der Schreibvorgang in die SD Karte so lang, das einige Date der seriellen Schnittstelle nicht mehr gepuffert wurden und somit weg waren.

Ich hab dann auf nen ATMEGA 644 hochgerüstet, weil der mehr RAM hatte.
Seit dem läuft es Einwandfrei.

[HaWe]

jap, SPI braucht 500 bytes Puffer.
wenn man dann nen kleinen AVR hat, ists schnell Ende-Gelände mit dem RAM.
Und I2C braucht nochmal 100 bytes Puffer, und auch UART verwendet einen Puffer wenn ich mich recht erinnere.
Ich las mal iwo, dass wer SPI nutzt wenigstens nen Mega mit 8kB RAM verwenden soll.

[BMS]

Hallo,
also ich mache das so, dass ein Sektor der SD (512 Bytes) im RAM gepuffert wird.
Dazu kommen noch ein paar Variablen für das FAT16 Dateisystem.
So kann das dann auch ab 1kB RAM funktionieren.
Es gibt auch noch das petitFS von Elm Chan, das läuft sogar auf einem attiny.

Grüße,
Bernhard

[wkrug]

Hallo,
also ich mache das so, dass ein Sektor der SD (512 Bytes) im RAM gepuffert wird.
Dazu kommen noch ein paar Variablen für das FAT16 Dateisystem.
Das ist schon richtig.
Kommen aber viele Daten und der Controller ist gerade beim schreiben eines Sektors, verschwinden Daten, weil die Puffergröße nicht ausreicht.
Schick mal Daten mit 115200 via USART an den Chip und Du wirst sehen, das dann ohne ausreichenden Puffer viele Daten im Nirvana verschwinden.
Es ist also dann sinnvoll 2 Sektor Puffer mit 512k zu haben um Datenverlust zu vermeiden.

[BMS]

Das hängt natürlich von der Anwendung ab.
Ich hatte bislang nur Lesezugriffe benötigt.
Für Schreibzugriffe kann ich wkrugs Methode nachvollziehen.
Eine Überlegung ist sicher auch, dass man Daten zur Karte in Häppchen a 512 Bytes formen sollte, um ganze Sektoren zu schreiben.
Wenn die zu schreibenden Daten länger sind, könnte man die ersten 512 Bytes an die Karte senden und den Rest der z.B. über UART ankommenden Bytes zunächst in den zweiten Puffer ablegen?
Sicher wird es da mehrere Strategien geben.
Grüße,
Bernhard

[HaWe]

ich halte persönlich nichts von dieser Datenfitzelei. Ich würde sagen: Standard-Libs für SD (SD.h oder SdFat.h), SPI, I2C und UART plus einen vernünftigen µC mit ausreichend Speicher (Mega mit 8kB).
Oder gleich einen Zero, Teensy, Due oder Yun.