PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : nodeMCU ESP-12E und Arduino NANO



Moppi
31.01.2020, 12:33
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
31.01.2020, 18:54
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
31.01.2020, 19:51
Pegelwandlung habe ich durchgeführt.


MfG

Klebwax
31.01.2020, 20:27
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
31.01.2020, 20:35
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
31.01.2020, 21:46
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
34789

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
01.02.2020, 12:28
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
01.02.2020, 12:53
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
01.02.2020, 13:17
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
01.02.2020, 13:27
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.

Rabenauge
01.02.2020, 13:36
Die NodeMCU treiben einiges im Hintergrund.
Und: es ist nicht alles dokumentiert, bei manchem (und niemand weiss, wieviel) hüllt sich Expressif in eisernes Schweigen.

Die haben das Ding nur teilweise offengelegt- von daher gibt es immer mal wieder Überraschungen.

Moppi
01.02.2020, 13:38
Hier mal, was so im Monitor ankommt.



2337!2337!2337?2337!Hello, world:
2338!2338!2338!?338!Hello, word
2339!2339!233??2339!Hello, wo?ld:

Klebwax
01.02.2020, 18:29
Die NodeMCU treiben einiges im Hintergrund.

Da läuft das ganze W-Lan im Hintergrund. Ich halte eine SW-Uart generell für schlecht und auf einem ESP8266 für unbrauchbar. Ich benutze nur die HW-Uart und habe damit auch bei 115kB keine Probleme.

MfG Klebwax

Moppi
01.02.2020, 19:38
Ich habe es jetzt rausgefunden, woher die Fehler kommen. Nicht vom nodeMCU. Die kommen vom ATmega328P, also von "SoftwareSerial.h" auf einem 328P. Mit UART gibt es da keine Übertragungsfehler. Bloß müssen dann bei jedem Programmaufspielen die Kabel an RX/TX abgezogen werden und dann wieder drauf gesteckt. Deswegen hatte ich auch SoftwareSerial auf dem 328P. Gut, weiß ich jetzt, kann die Kommunikation mit Fehlererkennung umsetzen und dann später, wenn alles fertig ist, auf UART umstellen.


MfG

Moppi
02.02.2020, 15:51
Wie soll man das hinterher wieder in der Software lösen? Habe DIP-Schalter bestellt.