ESP8266 - AT Firmware für Dauerbetrieb?

[Sebastian H. (sebastian1234)]

Hi,

ich bastel grad an einem Dimmer mit ESP8266...

Der Dimmer ist schon fertig, AVR etc, aber ich musste kurzfristig von 
RS485 auf Wifi umschwenken.

Ich habe die neuste AT firmware aus dem espressif forum, und die ist in 
jedem fall schonmal deutlich besser als das was da original auf dem chip 
war, aber nirgends findet man was positives darüber (stabilität, etc)

Nun meine Frage: Habt ihr erfahrung mit dem Einsatz der Firmware? Der 
AVR kann alle GPIOS des ESP ansteuern, also könnte der AVR als Watchdog 
dienen.

[Einer K. (Gast)]

Ich kann die AT Software nicht leiden.
Ist eliminiert. Vollständig. Das erste, was jedem ESP geschieht, der bei 
mir in den Einsatz kommt.

Bei mir werden (wenn, dann) AVRs über I2C mit den ESP verbunden.
Der ESP ist dann der Hauptrechner, alleine schon, weil er ein mehrfaches 
an Speicher und Rechenpower hat.
Und natürlich OTA Update kann.

Der AVR darf dann intelligente Porterweiterung spielen.


Programmiert werden beide mit der Arduino IDE. Aber das ist 
Geschmackssache, gibt ja noch andere Entwicklungsumgebungen.

[A.. P. (arnonym)]

Also ich nutze bislang  nur die AT Firmware auf meinen ESPs (habe 
mehrere davon in den Ausführungen -01, 07 und -12). Habe auch alle mit 
der - soweit ich weiß - aktuellsten Version geflasht. Das Build-Datum 
meiner FW ist zumindest irgendwo auf Herbst letzten Jahres datiert. Ich 
nutze übrigens die fertigen Binaries, habe keine Lust das selbst zu 
kompilieren. Vor diesem Hintergrund darf man also das Wort "aktuellste" 
relativ betrachten :)

Zurück zum Thema:
Bei mir laufen die ESPs alle stabil und es gibt auch keine Abbrüche o.ä. 
zu beliebiger Zeit. Häufigste Ursache für Abbrüche sind aber sowieso 
eher eine unzureichende Stromversorgung oder andere Komponenten, die die 
Stromversorgung zusammenbrechen lassen. Wenn man z.B. versucht, einen 
ESP über einen USB-Seriell-Wandler mitzuversorgen, geht das in den 
meisten Fällen in die Hise, da der dort verbaute FTDI-Chip einfach nicht 
genug Tinte auf dem Füller hat, um den teils recht stromhungrigen ESP 
mit durchzubringen.

Problem bei der AT-Firmware ist eigentlich nur, dass man für komplexere 
Aufgaben oder ein robustes System die Behandlung der State Machine der 
AT-Firmware selbst übernehmen muss. Ich selbst habe mich z.B. der 
Aufgabe angenommen, mit Hilfe einer zusätzlichen Parser-Bibliothek für 
die AT-Kommandos ein Socket-Layer zu programmieren auf dem ich widerrum 
Anwendungsprotokolle, wie HTTP und MQTT umsetzen kann. Es ist einfach 
eine geschmackliche Entscheidung von mir gewesen, dass ich lieber auf 
meinen beliebten STM32 als Host-Controller bleibe und entwickle und der 
ESP für mich einfach ein austauschbarer Sklave bleibt. So muss ich mich 
auch nicht mit dem Arduio-Gedöns auseinandersetzen.

Die Umsetzung meines Socket-Layers funktioniert soweit auch ganz gut, 
ich arbeite zur Zeit eher noch am zeitlichen Feintuning, denn man darf 
eins nicht vergessen: der ESP kann zwar mit der AT-Firmware bis zu 5 
Verbindungen gleichzeitig verwalten (sprich offen haben), Daten 
empfangen/senden kann er aber natürlich trotzdem nur für eine Verbindung 
zu einem beliebigen Zeitpunkt t. Er verarbeitet ja schließlich auch die 
AT-Kommandos nur eins nach dem anderen. Hinzu kommt dann natürlich noch 
die Baudrate, mit der man mit dem ESP kommuniziert. All diese zeitlichen 
Einschränkungen sorgen natürlich dafür, dass man mit der AT-FW nicht das 
Maximum an Übertragungsrate rausholt. Ok, für den Punkt der 
Gleichzeitigkeit trifft das natürlich nicht zu. Auch wenn man den ESP 
direkt programmiert, kann das zugrunde liegende OS (sofern genutzt) nur 
einen Befehl gleichzeitig ausführen, aber wenn man den ESP mit der AT-FW 
betreibt, muss man natürlich die Geschwindigkeit des Host-Controllers 
und der Baudrate in Betracht ziehen. Wenn dort dann auch noch ein OS 
eingesetzt wird, dann dessen Tickrate, Taskwechsel etc. und wenn man - 
so wie ich - noch eine zusätzliche Parser-Bibliothek einsetzt, dann 
natürlich auch dessen Verarbeitungszeit.

Wenn also eine Anforderung ist, dass die Anwendung mit maximaler 
Übertragungsrate läuft, dann kommt man wohl um das direkte Programmieren 
des ESPs nicht herum. Sollte das kein Kriterium sein und es reichen auch 
ein paar Dutzden kB/s in der Übertragung, kann man auch mit der 
AT-Firmware arbeiten.

Das sind so meine Erkenntnisse.

[A.. P. (arnonym)]

Nachtrag:

War jetzt mal wieder an meinem Rechner und habe nachgesehen, welche die 
konkrete AT-Version ist, die auf meinen ESPs läuft. Folgende Ausgabe 
erhalte ich in meinem Terminal:

AT version:  1.4.0.0(May  5 2017 16:10:59)                                    
SDK version: 2.1.0(116b762)

Die Aussage

A.. P. schrieb:
> Das Build-Datum
> meiner FW ist zumindest irgendwo auf Herbst letzten Jahres datiert

stimmte somit nicht ganz :)

Gruß

[Der Schwenn (Gast)]

Wasn eigentlich mit dieser WLAN-Lücke vor einiger Zeit, ist das in 
aktuellen Firmwareversionen gefixt, wenn ja aber welcher?

[A.. P. (arnonym)]

Der Schwenn schrieb:
> Wasn eigentlich mit dieser WLAN-Lücke vor einiger Zeit, ist das in
> aktuellen Firmwareversionen gefixt, wenn ja aber welcher?

Hab dazu mal vor ein paar Monaten (also als das Problem brandheiß war) 
was gelesen, dass Espressif da wohl nachgebessert hat. Also zumindest 
tauchte der Name "Espressif" bei Heise in einer langen Liste von 
Herstellern von Netzwerkgeräten auf, die schon aktiv geworden sind. Aber 
ich weiß jetzt nicht näher, was das für diesen speziellen Fall heißt und 
für welche Produkte von Espressif das nun gilt. Müsste ich selber erst 
wieder nach suchen.

Gruß

[Stefan F. (Gast)]

> Habt ihr Erfahrung mit dem Einsatz der (AT) Firmware?

Frühe Versionen bis Version 0.40.0.0 aus dem SDK 1.3.0 waren sehr 
instabil und nervten damit, dass die Bitraten und das Format der Befehle 
häufig geändert wurden.

Ab Version 0.50.0.0 aus dem SDK 1.4.0 läuft die Firmware 
langzeit-stabil. Ich hatte sie zwei Wochen im Dauertest mit einer 
Relaisplatine, wo ich vom PC aus jede Sekunde ein Relais umschaltete.

Die nächste mir bekannte Version ist 1.1.0.0 aus dem SDK 1.5.4, die 
läuft auch stabil. Neuere Versionen habe ich noch nicht versucht, da ich 
dazu keinen Grund hatte.

Der ESP8266 stellt hohe Ansprüche an die Stromversorgung. Ich nutze als 
Spannungsregler immer einen LF33CV, beschaltet nach Datenblatt. 
Zusätzlich noch ein 100µF Elko direkt am Modul (ist beim NodeMCU Board 
bereits vorhanden).