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.
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.
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.
:
Bearbeitet durch User
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:
1 | AT version: 1.4.0.0(May 5 2017 16:10:59) |
2 | 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ß
:
Bearbeitet durch User
Wasn eigentlich mit dieser WLAN-Lücke vor einiger Zeit, ist das in aktuellen Firmwareversionen gefixt, wenn ja aber welcher?
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ß
> 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).
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.