nodeMCU ESP-12E und Arduino NANO

[Moppi]

Hallo zusammen!

Ich versuche mit einem nodeMCU und einem ATmega eine serielle Verbindung herzustellen.
Bisher klappte das mit einem Single-ATmega328P-PU (Grundbeschaltung), problemlos. Außer, dass ich zum Programm aufspielen die serielle Verbindung zwischen den Geräten trennen musste.

Nun habe ich einen NANO. Bei dem funktioniert das auch, also Signale kommen an und er sendet die auch zurück. Ob ich SoftwareSerial verwende oder UART ist egal.

erstes Problem:
Ich nutze am nodeMCU die Pins für GPIO13 und GPIO15, in Verbindung mit SoftwareSerial. So wie ich raus fand, macht GPIO15 Schwierigkeiten.
Wenn der GPIO15 (als TX) mit dem RX0-Pin am NANO verbunden ist, dann startet das nodeMCU nicht durch (bleibt hängen) und das Aufspielen von Software schlägt auch fehl.
Nur wenn ich SoftwareSerial (und also andere Pins) am NANO verwende, dann funktioniert alles. Ist das nodeMCU einmal gestartet (auch die Schnittstelle per SoftwareSerial initialisiert)
und ich verkabele dann die beiden Geräte, dann funktioniert die Kommunikation zwischen beiden Geräten, sowohl mit SoftwareSerial, am Arduino NANO, als auch per UART RX/TX, am Arduino NANO.

zweites Problem:
Wenn ich SoftwareSerial verwende, bekomme ich grundsätzlich keine störungsfreie Kommunikation zwischen NANO und nodeMCU (Baudrate egal). Das kenne ich so auch nicht. Nach etwa 8 Zeichen schleicht sich der erste Fehler ein.
Und noch etwas: Störquellen sind da nicht, die ich als solches sehen würde, vorhandene Motoren laufen nicht, weil sie nicht angesteuert werden. Ich probiere einfach nur die serielle Kommunikation.

Jetzt hoffe ich, dass jemand hier schlau daraus wird und mehr Erfahrung hat, als ich und mir dazu etwas sagen kann!


zur Vollständigkeit, Code für nodeMCU

#include <SoftwareSerial.h>


SoftwareSerial mySerial(13, 15); // RX, TX


void setup() {
    //Wenn ESP mit Error 29 neu startet
    //ESP.eraseConfig();
    //ESP.reset();


  pinMode(13,INPUT);
  pinMode(15,OUTPUT);
  delay(5000);


  // Open serial communications and wait for port to open:
  Serial.begin(115200);
  while (!Serial) {}


  mySerial.begin(4800);
  while (!mySerial) {}
  
}


int a;


void loop() { // run over and over
  if(mySerial.available()){
    while (mySerial.available()){
      Serial.write(mySerial.read());
    }
    delay(100);
  }
  else{
      a++;
      mySerial.print(a);
      mySerial.print("!");
      mySerial.print(a);
      mySerial.print("!");
       mySerial.print(a);
      mySerial.print("!");
       mySerial.print(a);
      mySerial.print("!");
      mySerial.println("Hello, world: ");
  }
  yield();
}

zur Vollständigkeit, Code für Arduino

#include <SoftwareSerial.h>


SoftwareSerial mySerial(3, 2); // RX, TX
  int a;


void setup() {
  delay(5000);
  mySerial.begin(4800);
  while (!mySerial) {}
}


void loop() { // run over and over
  while (mySerial.available()) {
    mySerial.write(mySerial.read());
  }
}

Der Code ist jetzt nur für SoftwareSerial, allerdings nicht ohne Störung in der Übertragung möglich.




Freundliche Grüße
Moppi

[Rabenauge]

Sowas ähnliches hatte ich im XPlorer1 gemacht- auch ein Nano und ein NodeMCU.
Allerdings hatte ich I2C zur Kommunikation benutzt....von daher: wenig hilfreich hier.

Pegelwander hast du verbaut?
Der NodeMCU ist _nicht_ 5V-tolarant!

[Moppi]

Pegelwandlung habe ich durchgeführt.


MfG

[Klebwax]

Ich nutze am nodeMCU die Pins für GPIO13 und GPIO15, in Verbindung mit SoftwareSerial. So wie ich raus fand, macht GPIO15 Schwierigkeiten.

Zu GPIO15 fällt mir ein, daß der Pin beim Booten low sein muß.

MfG Klebwax

[Moppi]

Zu GPIO15 fällt mir ein, daß der Pin beim Booten low sein muß.

MfG Klebwax

Wenn ich die Kabel abziehe, dann hängt der in der Luft, dann bootet das nodeMCU.

Steht irgendwo, dass der auf LOW gezogen werden soll?

MfG

[Klebwax]

Steht irgendwo, dass der auf LOW gezogen werden soll?

Der Zustand der GPIO15, GPIO0 und GPIO2 , wenn Reset oder CH_PD high wird, bestimmt den Boot Mode des ESP. Hier eine Tabelle dazu


In der linken Spalte stehen die Zuständer der Pins 15, 0 und zwei. Die beiden grünen Werte werden typisch verwendet, einmal zum Flashen, einmal zum Betrieb.

MfG Klebwax

[Moppi]

Irgendeinen Zusammenhang wird es da wohl geben. Denn wenn ich den RESET-Knopf auf der Platine drücke, bleibt der ESP hängen, aber nicht, wenn ich die Stromversorgung trenne und er dann neu startet.
Wenn ich SoftwareSerial verwende, kann ich auf GPIO12 und GPIO13 umschwenken, GPIO15 dann nicht benutzen. Wird, mangels der nutzbaren Pins, dann immer weniger, was ich am nodeMCU betreiben kann.
Wenigstens bekomme ich noch eine SD-Karte dran und der Rest muss dann an den NANO angeschlossen werden.

MfG

[Rabenauge]

Hm, mir ist da noch was eingefallen: ich hatte Timingprobleme (irgendwelche Interrupts hatten mir in die Suppe gespuckt, und damit die Kommunikation ab und zu gestört).
Das hab ich gelöst, indem ich eine zusätzliche Busy-Leitung zwischen beiden Controllern gelegt hatte.
Wer was vom anderen wollte, hat die auf HIGH gezogen, und somit konnte ich das Problem dann umschiffen.

Das hilft dir evtl. auch weiter.

[Klebwax]

Irgendeinen Zusammenhang wird es da wohl geben.

Nicht irgendeinen, sondern wie in der Tabelle, die ich gepostet hab. Elektronik funktioniert deterministisch.

Denn wenn ich den RESET-Knopf auf der Platine drücke, bleibt der ESP hängen, aber nicht, wenn ich die Stromversorgung trenne und er dann neu startet.
Wenn ich SoftwareSerial verwende, kann ich auf GPIO12 und GPIO13 umschwenken, GPIO15 dann nicht benutzen. Wird, mangels der nutzbaren Pins, dann immer weniger, was ich am nodeMCU betreiben kann.
Wenigstens bekomme ich noch eine SD-Karte dran und der Rest muss dann an den NANO angeschlossen werden.

Was spricht eigentlich dagegen, sich mal GPIO15 (oder auch die anderen Pins) auf dem Scope während Reset oder Power-On anzusehen? Und was spricht dagegen einen Pulldown an GPIO15 zu legen, damit er beim Booten low ist, wie man das mit solchen Config-Eingängen normalerweise macht?

MfG Klebwax

[Moppi]

Das Problem ist, dass ich nichts mache, außer ser. Kommuniaktion. Da ist kein Sensor angeschlossen, keine IR-Diode oder sonst was. Außer er L293D, der nicht angesteuert wird.
Wie ich das Problem lösen kann, das ist mir geläufig, werde ich auch tun müssen. Aber Störungen in der Kommunikation verlangsamen die Reaktionszeit auf der Empfängerseite.
Wenn ich günstige Einstellungen finde, habe ich nicht so viele Fehler.

MfG

- - - Aktualisiert - - -

GPIO12 und GPIO13 machen weniger Probleme. Die Störungen in der Übertragung bleiben.
Stimmt aber, ich könnte noch eine dritte Verbindung stecken. So dumm ist das gar nicht.