Liebe Community
kämpfe seit Stunden mit einem simplen Aufbau.
Wemos D1 und SD shield. Mit einem Arduino UNO klappt das Ansprechen problemlos. Beim CS habe ich statt dem D10 (beim UNO) den GPIO 0 genommen, da sonst nicht geflasht werden kann.
Weder mit der SD lib noch der SDfat lib klappt es. Auf der Data_out-Leitung der SAD-Karte kommt etwas zurück, das vom ESP offenbar nicht akzeptiert wird.
Im englischen Teil des Forum müssen die Beiträge und Diskussionen in englischer Sprache verfasst werden. Deswegen wurde diese Diskussion in den deutschen Teil des Forums verschoben.
mfg ein Moderator.
es könnte ein 3.3V 5V Problem sein. Vielleicht passen die Pegel nicht.
Sorry, that's my first approach in the forum
Von meinem/meiner Galaxy gesendet
Der ESP bringt eine eigene SD-Lib mit, die auf SdFat basiert. Wenn das SD-Shield mit UNO funktioniert, ist es auf 5V ausgelegt und kommt mit den 3,3V nicht zurecht.
Gruß Tommy
Hallo Tommy
habe die Hardware genauer angesehen. Ein Pullup an CS hat die 3,3V auf 4,4 hochgezogen. Habe das geändert. Die Pegel sind jetzt alle 3,3V, bringt aber nix.
Da kann man aus der Ferne nicht mehr viel ausrichten. Wenn alle Pegel an der Karte 3,3V sind, dann könnte sie evtl. noch falsch formatiert sein.
Wie groß ist die Karte und wo und mit welchen FS wurde sie formatiert?
Probier mal das Formatierungstool der SD Association aus.
Gruß Tommy
Also es ist ein Modul für 5V? Zeige mall link oder mach Foto.
Nicht alle arbeiten mit ESP.
Dieser ist nur für 3,3V (ESP) gedacht
Der Data Loger ist vorgesehen für 5V Arduino gas er Mechanisch passt auf dein Board hat hier wenig zu sagen, welschen Pegel gibt der ala Uno raus?
Es wurde folgendes modifiziert:
Verbindung D10/SS vom ESP zum Shield unterbrochen, da sonst nicht geflasht werden kann. Den Pullup über dem Treiber 74AHC125 statt auf 5V auf 3,3V gelegt. (Die Verbindung zu 5V macht niemals einen Sinn, da der 125 mit 3,3V versorgt wird und dann aber am Eingang Pin9 5V anliegen, Diese werden dann intern über die Schutzstruktur auf die 3,3V geleitet , die damit angehoben wird).
Denn SC mit D8(GPIO0) definiert und Brücke von D8 zum D10 auf dem Shield gelegt. Damit sind alle Pegel an der SD-Karte perfekt mit 3,3V.
Somit ist es nur noch ein Software-Thema.
Hat jemand einen funktionierenden kurzen Sketch?
Hier im Forum wurde öfters diskutiert über den Shield.
Der IC ist der Pegelwandler ist mit 3,3V versorgt, nur wie der intern aufgebaut ist keine Ahnung, muss nicht unbedingt 3,3V durchlassen.
So wie vermutet der ala Uno hat3,3V auf den Pins.
Nur zu Info, wenn du ein Uno Shield kaufst kann die passieren das du neuen ESP brauchst.
Fas Alle hier im Forum sind der Meinung dass das ist der größter Unsinn was auf den Markt geworfen wurde mit dem WeMos D1 ESP8266 UNO Format
Als Hardware-Profi von Infineon weiß ich, wie solche Bausteine intern sind.
Tatsache ist, dass die Pegel mit meiner Modifikation perfekt sind.
Leider bin ich als Arduino-Anfänger softwaretechnisch noch etwas schwach auf der Brust. 
Wenn Du das weist und es trotzdem nicht funktioniert, ist das kein Softwareproblem.
Gruß Tommy
Dan haste ein Osi wo ist das Problem, es ist rein technisches nix Software.
[code]
#include <SPI.h>
#include <SD.h> // In diesem Sketch verwenden wir die library
File Textdatei; // An dieser Stelle wird die Variable "Textdatei" als File (dts. Datei) deklariert.
void setup() {
Serial.begin(9600);
Serial.println("Initialisiere SD-Karte");
if (!SD.begin(5)) { // Wenn die SD-Karte nicht (!SD.begin) gefunden werden kann, ...
Serial.println("Initialisierung fehlgeschlagen!"); // ... soll eine Fehlermeldung ausgegeben werden. ....
return;
}
Serial.println("Initialisierung abgeschlossen"); // ... Ansonsten soll die Meldung "Initialisierung abgeschlossen." ausgegeben werden.
Textdatei = SD.open("test.txt", FILE_WRITE); // An dieser Stelle wird die Textdatei erstellt. Unsere Textdatei soll "test" heißen und im Format ".txt" (Text) erstellt werden.
if (Textdatei)
{ // Wenn die Textdatei ("test.txt") gefunden wurde....
Serial.println("Schreibe in Textdatei..."); // ... soll eine Meldung im seriellen Monitor erscheinen...
Textdatei.println("Funduino GmbH"); // ... und die Textdatei anschließend befüllt werden.
Textdatei.println("1, 2, 3, 4, 5");
Textdatei.println("a, b, c, d, e");
Textdatei.println();
Textdatei.close(); // Anschließend wird die Textdatei wieder geschlossen...
Serial.println("Abgeschlossen."); // ... und eine erneute Meldung im seriellen Monitor ausgegeben.
Serial.println();
}
else
{ // Wenn !keine! Textdatei gefunden werden kann ...
Serial.println("Textdatei konnte nicht ausgelesen werden"); // ... erscheint eine Fehlermeldung im seriellen Monitor.
}
// NUN WIRD DIE TEXTDATEI AUSGELESEN
Textdatei = SD.open("test.txt"); // Die Textdatei auf der SD-Karte wird wieder geoeffnet...
if (Textdatei)
{
Serial.println("test.txt:"); // ... und der Name der Datei wird ausgegeben.
while (Textdatei.available()) // Anschließend wird die Datei so lange ausgelesen (while)...
{
Serial.write(Textdatei.read()); // ... bis keine Daten mehr gefunden werden können.
}
Textdatei.close(); // Im Anschluss wird die Textdatei wieder geschlossen.
}
else // Sollte keine Textdatei (also test.txt) gefunden werden können...
{
Serial.println("Textdatei konnte nicht geoeffnet werden"); // ... erscheint eine Fehlermeldung im seriellen Monitor.
}
}
void loop() // Der Loop bleibt leer.
{
}
[/code]
CS Pin rausfinden und statt 5 eintragen normalerweise 10 bei UNO
Das mit dem CS ist mir schon lange klar. Habe verschiedene ausprobiert. Die SD antwortet ja , aber der ESP ist mit der Antwort nicht zufrieden.
Gelb: CS mit sauberen 3,3V
Grün: MISO, also output der SD.
Wo sollte da das Problem bei der Hardware liegen?
Beim UNO läuft dieser Sketch auch ja problemlos und die Antwort sieht sehr ähnlich aus.
Habe als Board "Generic ESP8266" gewählt, das sollte aber keinen Einfluss auf die Kommunikation zur SD haben.
Lade mal das, und zeige was im Serial Monitor rauskommt.
Die angezeigte GPIO müssen übereinander stimmen mit meinen, und wird wahrscheinlich so sein den die SPI.h nimmt immer die GPIO Pins was sind hinterlegt im dem Core, nur der CS Pin ist frei wählbar.
Danach mall messen ob die GPIO 12, 13, 14 am ESP überstimmen mit dem UNO Pins
#include <SPI.h>
void setup() {
Serial.begin(9600);
Serial.println();
Serial.print("MISO ist GPIO ");
Serial.println(MISO);
Serial.print("MOSI ist GPIO ");
Serial.println(MOSI);
Serial.print("SCK ist GPIO ");
Serial.println(SCK);
}
void loop() {
}Ausgabe :
⸮tx⸮CGH⸮xOŰ⸮
MISO ist GPIO 12
MOSI ist GPIO 13
SCK ist GPIO 14
Aus dem CS Pin kommt ja das richtige Signal (gelbe Kurve). Das funktioniert mit mehreren Pins.
Sonst würde die SD ja nicht reagieren. Wie schon gesagt, ist der ESP nur mit der Antwort nicht zufrieden. Habe das Signal mit einen UNO verglichen, das ist identisch. Leider kann mein Billig-oszi die Daten nicht dekodieren. Also sehe ich nur die Pulse, verstehe den Inhalt aber nicht.
Ich verstehe das so MOSI , SCK, CS ist ok den die Karte antwortet ja also ist am ESP mit MISO was nicht in Ordnung deshalb habe dir das oben gezeigt, es ist reiner Hardware Fehler sonst wurden die tausende Data Logger mit ESP8266 nicht funktionieren, ist das so schwer mall den MISO zw ESP und der Pinlaiste messen, glaube nicht.-
bin raus hat keinen sinn
PS ESP8266 hat zwei mall SPI drauf falls das übersehen hat.