ESP8266/NodeMCU Kommunikationsprobleme

**thewulf00** · 27.03.2016, 15:35

Hallo Community,

ich habe mir vor kurzem meinen ersten NodeMCU-ESP8266 geholt. Allerdings bekomme ich keinerlei Programme zum Laufen.

Auf der Rückseite ist abgedruckt:

1. Install CP2102 driver
2. Use 9600 baud rate
3. Connect Wi-Fi and enjoy

Also habe ich den Treiber runtergeladen/installiert und das Modul via USB verbunden - mit meinem Samsung-Originalkabel vom Handy.
Dann hab ich den ESP8266Flasher runtergeladen, um eine Firmware draufzuladen. Ich versuchte die mitgelieferte firmware und später auch die Masterversion, sowie die Dev-Version von http://nodemcu-build.com/.

Der Flasher schien richtig zu funktionieren:
1. Die blaue LED blinkt, während die Firmware übertragen wird.
2. Änderungen an der Baudrate sieht man an einer geänderten Blinkfrequenz.
3. Nachdem die Firmware geflasht wurde, reagiert das Modul eine Weile nicht - vermutlich rebootet es.
Dennoch kann ich nicht wissen, ob er wirklich geflasht hat oder nicht.

Schritt zwei war dann, eine init.lua zu übertragen.
Als erstes benutzte ich den ESPlorer in drei Versionen:
1. Selbstkompiliert vom GitHub-Repository,
2. Die vorkompilierte stable Version,
3. Die vorkompilierte dev Version.
Keine dieser Versuche/Versionen war in der Lage, eine Datei zu übertragen, oder irgendetwas anderes zu tun. Ständig nur Fehlermeldungen

Prinzipiell hat der Verbindungsaufbau erstmal geklappt. Dann folgten solche Meldungen

Not able to detect firmware

(Nach dem Aufbau der Verbindung)

Communication failure

(Beim Versuch, eine Datei zu senden)
Ich habe sogar den dumb mode probiert - half aber nichts.

Nur Fehler über Fehler, also habe ichs mal mit einem anderen Tool probiert: LuaLoader.
Hier folgten ähnliche Probleme: Nach dem Verbindungsaufbau konnte das Tool die Antwort von der MCU nicht verstehen, also meldete es, die Baudrate sei nicht korrekt. Inzwischen habe ich alle Baudraten mal probiert. (110-921600)

Schlussendlich probierte ich sogar putty. Auch hier das gleiche Problem: Nur nicht lesbarer Kram - egal welche Baudrate ich einstellte.
Ich habe sogar auf einem USB 3-Port und später auf einem USB 2-Port getestet.

Nun könnte man annehmen, ich habe über alle Tools und Versuche hinweg den falschen COM Port eingestellt (Ich habe immer COM 13 benutzt).
Folgende Hinweise sprechen aber dagegen:
- Nach einem Reset des Moduls zeigten putty und LuaLoader immer die gleichen (nicht lesbaren) Zeichen an.
- Wenn man das Modul trennt, verschwindet der COM Port aus der Liste.
- Den COM Port gibt es erst seit ich den Treiber installiert und das Modul erstmals angeschlossen habe.

Fragen:
- Ich habe oft gelesen, dass man zum Flashen bestimmte Pins verbinden muss. Ich habe allerdings nichts dergleichen getan - ist das vielleicht das Problem?
- Auf dem Modul ist eine freie (unbestückte) Fläche mit dem Text "flash", dort passt exakt ein Button hin, wie der, der für Reset genutzt wurde. Warum ist das unbestückt?
- Was ist denn summa summarum mein Problem? Es läuft ja absolut garnicht! Ideen?

Noch ein paar Screens von meinem Testaufbau:

Bild hier

Bild hier

Bild hier

Bild hier

**Klebwax** · 27.03.2016, 19:02

Ich verwende auch die ESP mit der nodemcu Firmware, aber nicht das Dev-Board und auch nicht Windows, sondern einen vorhandenen USB Adapter mit FTDI. Ich kann also zu den Windows Programmen nichts sagen.

Fragen:
- Ich habe oft gelesen, dass man zum Flashen bestimmte Pins verbinden muss. Ich habe allerdings nichts dergleichen getan - ist das vielleicht das Problem?
- Auf dem Modul ist eine freie (unbestückte) Fläche mit dem Text "flash", dort passt exakt ein Button hin, wie der, der für Reset genutzt wurde. Warum ist das unbestückt?

Nun, die logischen Level, die bestimmte Pins beim Reset haben, bestimmen in welchen Mode das ESP Modul geht. Zum Flashen muß GPIO0 auf Low sein. Auf dem Schaltplan des Dev-Boards sind 2 Taster zu finden, einer zum Flashen und einer als Reset. Warum du nur einen Taster hast, weiß ich nicht.

Noch etwas zum Verhalten des Moduls: Nach dem Reset startet der im ESP vorhandene Bootloader. Er meldet sich mit einer krummen Baudrate von ca. 74kBaud. Mit einem LA kann man das entziffern. Je nach Spannung am GPIO0 Pin (es spielen da noch mehr Pins mit, das sollte aber auf dem Dev.Board oder dem ESP Modul geregelt sein) erwartet er ein Firmware Image, um es ins Flash zu schreiben (GPIO0 Low), oder er bootet aus dem Flash (GPIO0 High). Danach meldet sich der ESP mit der Baudrate der Firmware, bei nodemcu typisch 9600, und einer Startmeldung. Ich verwende minicom als Terminal. Dann kann man Kommandos in den Lua-Interpreter eingeben.

Ich hab eine ganze Weile Interaktiv herumgespielt bevor ich das erste Programm als File ins Flash geschrieben habe. Vorsicht mit init.lua! Wenn da ein Bug drin ist, der den ESP crashen läßt, startet er den ESP neu, lädt init.lua und crasht aufs neue. Man schaft es nicht, init.lua zu löschen. Da hilft dann nur die Firmware neu aufzuspielen. Dabei wird dann das Filesystem initialisiert.

Viel Erfolg

MfG Klebwax

PS.

Inzwischen habe ich alle Baudraten mal probiert. (110-921600)

Da hilft ein LA wie der saleae. Aufzeichen, autobaud und schon weiß man, was abgeht.

**thewulf00** · 27.03.2016, 21:50

Vielen Dank für Deine Antwort.
Ich hab leider kaum Infos rausziehen können. Ich werde also mal GPIO0 prüfen und ggf. auf Low setzen.
Das Flashingtool arbeitet aber anscheinend korrekt - wie stehen die Chancen, dass er beim Flashen irgendwie GPIO0 von selbst auf low zieht?

Und nochwas: Auf meinem letzten Bild siehst Du, dass ich keine GPIO-Beschriftungen habe - wo ist GPIO0?

Nachtrag: Der Hinweis mit der init.lua ist Gold wert. Wie kann ich verhindern, dass ein Programmierfehler eine Reboot-Endlosschleife verursacht?

**Klebwax** · 28.03.2016, 01:01

Ich hab leider kaum Infos rausziehen können

Das kann ich nicht nachvollziehen. Das Netz ist voll von Informationen zum ESP und den Modulen. Einen Link hab ich oben gepostet, da gibt es den Schaltplan des Dev-Boards. Dort ist auch die Pinbelegung zu finden. Es sieht aber so aus, daß das Flash-Tool via DTR und RTS da etwas macht. Aber hier noch ein paar Links: die Module oder Kolbans Buch.

Der Hinweis mit der init.lua ist Gold wert. Wie kann ich verhindern, dass ein Programmierfehler eine Reboot-Endlosschleife verursacht?

Die einfache Antwort: keine Fehler machen. Eine etwas praktischere: das Programm in einem File mit einem anderen Namen als init.lua speichern. Es dann solange mit dofile von Hand starten und testen, bis man glaubt, daß es fehlerfrei ist, auch wenn es nervt. Erst dann sollte man es init.lua nennen. Selbst wenn man lua kann, ist das Programmieren für nodemcu nicht ganz einfach. Programme laufen dort asynchron, viel wird mit callbacks gemacht. Das ist ähnlich wie node.js für javascript, da kommt auch "node" her.

Ansonsten sind das schon feine Teile. Für 2$ oder weniger und 2 Pins für die serielle bekomme ich alle meine µCs in mein LAN, billiger als ein USB Adapter und auch noch flexibler und drahtlos. Und einfache Aufgaben lassen sich in lua scripten und laufen direkt auf dem ESP. Nachdem die Hardware fertig ist, nehme ich gerade eine Rolladensteuerung in Betrieb, die nur im ESP läuft. Die GPIOs steuern den Motor und bedienen die lokalen Taster und WLAN erlaubt die zentrale Steuerung. Der ESP bzw das Modul kostet dabei weniger als die Kabel eines Hausbusses, geschweige denn das Verlegen dieser Kabel.

MfG Klebwax

**thewulf00** · 28.03.2016, 19:46

Hallo Klebwax,

nochmals danke für Deine Antwort.

Ich danke Dir fürs nochmalige Draufstoßen. Ich habe den Link von Dir übersehen. Mithilfe Deiner Infos und etwas Recherche läuft tatsächlich das erste Programm. Ich habe den ESPlorer genutzt, und er macht autom. ein dofile nach dem Übertragen von Dateien. So kann ich Deinen Hinweis ohne großen Mehraufwand einarbeiten.

Des Rätsels Lösung waren folgende Schritte:
- Wissen, welcher Port zu GPIO0 gemappt ist. Hilfreicher Link: https://iotmodules.co.uk/media/wysiw...MCU_Pinout.png
- Der Hinweis, dass die richtige Programmierbaudrate von allen Internetinfos abweicht: 115200. Hilfreicher Link: http://www.electrodragon.com/w/ESP82...eMCU_Dev_Board

Nochmals Danke an Klebwax für die entscheidenden Infos.

- - - Aktualisiert - - -

Zitat von Klebwax

Ansonsten sind das schon feine Teile. Für 2$ oder weniger und 2 Pins für die serielle bekomme ich alle meine µCs in mein LAN, billiger als ein USB Adapter und auch noch flexibler und drahtlos. Und einfache Aufgaben lassen sich in lua scripten und laufen direkt auf dem ESP. Nachdem die Hardware fertig ist, nehme ich gerade eine Rolladensteuerung in Betrieb, die nur im ESP läuft. Die GPIOs steuern den Motor und bedienen die lokalen Taster und WLAN erlaubt die zentrale Steuerung. Der ESP bzw das Modul kostet dabei weniger als die Kabel eines Hausbusses, geschweige denn das Verlegen dieser Kabel.

Ich stimme Dir zu.
Du schriebst, einfach Aufgaben in LUA. Welche Alternative hast Du auf einem ESP8266 noch?
Und sollte man nicht eher sehr komplexe Aufgaben in einer Hochsprache lösen? (Der Fehlertoleranz und vereinfachung des Codes wegen...)

**Klebwax** · 30.03.2016, 06:04

Zitat von thewulf00

Du schriebst, einfach Aufgaben in LUA. Welche Alternative hast Du auf einem ESP8266 noch?

Eigentlich ist das Teil ein Modem, ein Funkmodem. Das legt schon der AT-Commandset, den die Erfinder des Chips gebaut haben, nahe. Die Anfänge stammen von den Fa. Hayes und sind im Laufe der Zeit für alle möglichen Datenübertragungen erweitert worden, hier für WLAN. Daß ein Modem heutzutage im wesentlichen aus einem Prozessor statt aus diskreter Logic und vielen Filtern besteht, ist klar. Wenn man mit der Funktionalität des mitgelieferten AT-Commandsets auskommt, klemmt man das genauso wie einen seriell-USB Wandler (auch eine Art Modem) an die serielle. Da ich gerne UDP verwende, hat mir die eingebaute Funktionalität aber nicht gereicht. Um ich mir die Entwicklung einer vollständigen eigenen Firmware zu sparen, bau ich mir mein "eigenes" Modem in Lua.

Was meine ich mit "einfache Aufgaben"? Alles was nicht zeitscharf ist, so z.B alle paar 10 Millisekunden Taster abfragen, Alle Ausgaben, die für einen Menschen gedacht sind usw. Und was sind keine "einfachen Aufgaben"? Eigentlich alles, wofür es zum Teil sehr aufwendige Hardwareunterstützung in den µCs gibt, viele IOs, Timer, schnelle SPI, mehrphasen PWMs, ADCs etc. So eine Quadcopter Steuerung wird nicht richtig funtionieren, wenn der WLAN Stack die CPU für eine Weile blockiert. Als Telemetriesender passt der ESP aber sicher.

Und sollte man nicht eher sehr komplexe Aufgaben in einer Hochsprache lösen? (Der Fehlertoleranz und vereinfachung des Codes wegen...)

Sicher, in der dem Problem angemessenen Hochsprache. Bei einer Lohnbuchhaltung ist es unerheblich, wenn das Laufzeitsystem einer Hochsprache ab und an mal den Garbagecollector anwirft, wie bei vielen interpretierten Sprachen und auch bei Lua. Auf den µCs verwende ich C, das ist im Moment der beste Kompromiss zwischen Hochsprache und Zeitschärfe (und Verfügbarkeit).

MfG Klebwax