Zitat:
Zitat von Moppi
bei den ersten beiden Bildern (mit und ohne Arduino verbunden) ist die Ausgabe leer,
bei dem dritten Bild bekomme ich in etwa so was hier"
: -1
: -1
Druckbare Version
Zitat:
Zitat von Moppi
bei den ersten beiden Bildern (mit und ohne Arduino verbunden) ist die Ausgabe leer,
bei dem dritten Bild bekomme ich in etwa so was hier"
: -1
: -1
Die Ausgabe ist nicht leer. Kann sie auch nicht sein.Zitat:
Zitat von fcn200
Zu der "-1" habe ich ja schon was geschrieben. Macht keinen Sinn, einen Puffer auszulesen in dem nichts drin steht (also außerhalb der IF-Bedingung).
------------------------------------------------------------------
Nachtrag:
Es gibt ein Beispiel, von SoftwareSerial für den Arduino.
Das befindet sich bei mir in einem Verzeichnis "... \avr\libraries\SoftwareSerial\examples\SoftwareSer ialExample". Darin gibt es eine Datei "SoftwareSerialExample.ino".
Dort kann man auch mal reinschauen und sich damit beschäftigen.
Das nodeMCU hat 2 Pins, die für nichts anderes vorgesehen sind, als für Ein-/Ausgaben. Das sind GPIO4 (D2) und GPIO5 (D1). Daran habe ich mich bei den ersten Gehversuchen (die ich hier im andern Thread dokumentiert habe) gehalten, um keine Überraschungen zu erleben. Wenn die Kommunikation über GPIO4 nicht funktioniert, kann man sie also auf jeden Fall noch über GPIO5 ausprobieren. Statt den Arduino dann mit "D2" des nodeMCU zu verbinden, kann man den dann also mit "D1" verbinden und muss das in der Software dann anpassen. Müsste man für das nodeMCU dann z.B. schreiben: SoftwareSerial mySerial(5, 4); // RX, TX
Der Arduino UNO hat mehr freie Ein-/Ausgänge, mit denen man das auch noch versuchen könnte.
Es gibt noch eine andere Möglichkeit, die ich damals auch beschrieben habe und die ebenfalls funktionierte. Nämlich Daten vom Arduino über die normale serielle Hardwareschnittstelle an das nodeMCU zu übertragen.
Beschrieben ist das unter "Funktioniert die Kommunikation nach den vorherigen Voraussetzungen auch per RX + TX - Pins". Den Link dazu habe ich ich als erste Antwort in diesem Thread hier schon gegeben. Man könnte das Beispiel auch umkehren und Daten über die serielle Hardwareschnittstelle des nodeMCU zum Arduino schicken und dort dann per SoftwareSerial empfangen; so würde man die "SoftwareSerial.h" auf dem nodeMCU zunächst umgehen.
Nur weil ich die ESPs bereits seit rund 2 Jahren verwende und einige Fallstricke kenne, und weil ich vermeiden will, dass hier Infos fasch verstanden u/o weitergegeben werden:
das mit den "vorgesehenen Pins" beim ESP ist evtl. missverständlich, wenn man sich auf die Arduino-IDE bezieht -
fest vorgesehen sind IMO nur D0 für Wake/Reset, D3 für die (verzichtbare) eingebaute LED, die Hardware-SPI-Pins D5-D7 und die Hardware UART Pins D9+D10 für Rx und Tx.
Code:digital GPIO default
D0 16 WAKE
D1 5 I2C SCL
D2 4 I2C SDA
D3 0 FLASH/LED
D4 2 TX1
D5 14 SPI SCK
D6 12 SPI MISO
D7 13 SPI MOSI
D8 15 MTD0 PWM
D9 3 UART RX0
D10 1 UART TX0
(D12) 10 SPIWP intern
wenn man kein SPI braucht (z.B. für TFT-Displays oder eine SD-Card), sind auch D5-D8 frei als IOs konfigurierbar;
D8 darf beim Booten nicht auf GND gezogen sein.
D1 und D2 werden in der Arduino IDE standardmäßig als I2C Pins verwendet, aber sie können auch mit dem Befehl
Wire.begin(d,c) // d,c: Pin-Nummern für SDA und SCL
auf andere Pins umkonfiguriert werden.
WENN man also SoftSerial am ESP verwendet und auch andere eingebaute Standard-Funktionalitäten verwendet, sollte man möglichst NICHT verwenden
D0, D1,D2, D5,D6,D7, D9,D10
sondern
D3,D4 (unter Verzicht auf die eingebaute LED an D3) und ggf. auch D8 (z.B. als Output),
und wenn man kein SPI braucht, gehen auch: D5,D6,D7.
D1,D2,D4 (und mit Einschränkungen auch D3,D8 ) sind aber für den praktischen "Arduino-Gebrauch" allesamt für nichts "fest vorgesehen".
Wenn man also D1/D2 nicht für I2C braucht und sich spätere Inkompatibitäten mit Standard-Examples für I2c nicht unbedingt sicherheitshalber ersparen will, kann man ntl auch D1/D2 für SoftSerial verwenden:
Es wird funktionieren, wenn man es richtig verkabelt und richtig programmiert, nur ist es IMO nicht besonders geschickt, es so zu tun: ich persönlich würde D3+D4 dafür verwenden.
Wenn es aber beim OP nicht funktioniert und man Software-Code-Fehler ausschließen kann, liegt es nicht an SoftSerial(D1,D2) sondern an defekter Hardware oder falscher Verkabelung.
Vielleicht ist auch ein Kabel oder eine Steckboard-Klemme defekt (passiert auch schon mal).
Vielleicht ist auch wirklich der ESP inzwischen defekt an einem oder mehreren GPIOs wegen vorhergegangener Schaltungsfehler, oder vlt war er auch von vornherein defekt: da hilft dann nur ein Vergleich nach Neukauf.
Der UNO hingegen ist sehr Fehler-tolerant, dass der kaputt sein sollte ist zwar nicht unmöglich, aber deutlich unwahrscheinlicher.
Ist eben beim nodeMCU nicht so einfach. Da muss jeder selber seine Prioritäten setzen. Alle Pins sind für irgendwas gedacht. Muss man gucken, auf was man am ehesten verzichten könnte. Vielleicht sollte man dazu einen neuen Thread aufmachen, welche Pins wann wofür Verwendung finden können und wann nicht. Für mich stellte sich die Frage anders, wenn ich drüber nachdenke, wie ich zwei Geräte miteinander zur Kommunikation verbinde. Brauche ich SoftwareSerial, wenn ich I2C nutze? Brauche ich I2C, wenn ich SoftwareSerial nutze? Ich würde mich für eins von beiden entscheiden. MISO, MOSI etc. würde ich mir für div. andere Zwecke frei halten. Da kommt u.U. noch ein anderes Gerät ans nodeMCU dran.
Aber da gibts eben verschiedene Vorlieben und Auffassungen. Hat aber mit dem eigentlichen Problem hier , finde ich, nichts zu tun und führt jetzt auf Abwege, die im Moment nicht zielführend sind.