Guten Mittag, ich hab ein Problem mit dem ESP8266 ... It seems I Can't wrap my head around it :) Was ich bisher herausgefunden habe: Die Standard-FW spricht AT-Commands. Es gibt zB auch Projekte, die eine transparente WLAN <-> UART Bridge zur Verfügung stellen. Es gibt Projekte wie esphttpd, die in den ESP8266 einen kleinen Webserver implementieren. Per UART frägt und bekommt man Daten von einem anderen µC. Was ich mich nun frage ... Die AT-Kommandos wären eigentlich nett, weil man den ESP8266 out-of-the-box ohne Programmierung verwenden könnte. Man scheint über die AT-Kommandos sich an ein WLAN anmelden zu können usw ... Man kann wohl auch einen externen Port per AT-Kommando aufmachen, auf dem der ESP8266 einen LISTEN macht. Hier hören die Informationen auf ... Was passiert nun, wenn ich einen HTTP-Connect auf den geöffneten Port mache? Kommen die HTTP-GET Befehle direkt dann per UART bei meinem µC an und ich müsste dort dann HTTP implementieren (wofür eigentlich nicht viel nötig ist)? Angenommen, es kommt ein GET für ein Image, werden die Daten base64-kodiert in ein AT-Kommando gewrappt? Irgendwie ist mir das nicht ganz klar ... Ziel wäre auf jeden Fall, die Firmware des ESP8266 nicht anzufassen und HTTP in meinem µC zu implementieren. Vielleicht sollte ich noch nach alten Modem-Protokollen suchen ... Damals konnte man analog ins Internet und die Modems sprachen auch nur AT-Kommandos und konnten Bilder usw ...^^ Kennt da jemand eine gute Resource zufällig? Viele Grüße, Mampf
Hallo, also wenn du gerade erst damit anfängst würde ich lieber gleich dazu übergehen das HTTP mit einer eigenen Firmware auf dem ESP direkt zu machen. Die Verbindungssteuerung und Datenübertragung über die Serielle Schnittstelle per AT CMDs ist schon "ziemlich vergurkt". Eh du dort jetzt Arbeit rein steckst hast du HTTP auf dem ESP mit der Arduino-IDE und den Beispielen schon längst am laufen. Und die veränderlichen Daten die du warscheinlich in die Website einbauen willst kannst du dem ESP immer noch über die Serielle rübersenden. Sascha
Sascha W. schrieb: > Hallo, > > also wenn du gerade erst damit anfängst würde ich lieber gleich dazu > übergehen das HTTP mit einer eigenen Firmware auf dem ESP direkt zu > machen. > Die Verbindungssteuerung und Datenübertragung über die Serielle > Schnittstelle per AT CMDs ist schon "ziemlich vergurkt". Eh du dort > jetzt Arbeit rein steckst hast du HTTP auf dem ESP mit der Arduino-IDE > und den Beispielen schon längst am laufen. Und die veränderlichen Daten > die du warscheinlich in die Website einbauen willst kannst du dem ESP > immer noch über die Serielle rübersenden. Danke für deine Einschätzung! Hmm, vlt ist das einer der seltenen Fälle, wo ich wirklich auf Arduino zurückgreifen sollte ... Was mir noch eingefallen ist ... Mein ARM-Board spricht auch CDC über USB, d.h. ich müsste den UART-Kommando-Dekoder nur einmal implementieren und mein Protokoll wäre dann gleich, egal ob der ESP8266 Daten möchte oder mein PC über den virtuellen COM-Port. Okay, ich glaube ich mach es so ... Dann ist der ESP8266 quasi mein Frontend^^ *edit*: Ah und evtl könnte ich dann die Entwicklung der Webseite auf dem PC machen und danach mit kleineren Anpassungen das ganze in einen ESP portieren ... Mittlerweile hatte ich auch noch ein Video gefunden, in dem das erklärt wurde, was mir irgendwie nicht klar war: https://alselectro.wordpress.com/2015/05/13/wifi-module-esp8266-2-tcp-client-server-mode/ Aber dafür einen stabilen Parser zu bauen, halte ich tatsächlich nicht wirklich für sinnvoll :) Dann schau ich mir mal die Arduino-Samples mit ESP8266 an :) Vielen Dank!
:
Bearbeitet durch User
Mampf F. schrieb: > Was ich mich nun frage ... Die AT-Kommandos wären eigentlich nett, weil > man den ESP8266 out-of-the-box ohne Programmierung verwenden könnte. In dem Fall ist bereits eine Firmware auf dem ESP vorhanden. Dieser wird allerdings auch nachgesagt eine "Homecall" Funktion nach chinesien zu haben. Es würde mehr sinn machen das du die Software direkt auf dem ESP programmierst. Das geht mittlerweile easy mit der Arduino-IDE.
Häääh schrieb: > In dem Fall ist bereits eine Firmware auf dem ESP vorhanden. Dieser wird > allerdings auch nachgesagt eine "Homecall" Funktion nach chinesien zu > haben. Oh okay ... das ist definitiv ein K.O.-Kriterium für die Stock-Firmware! Wer weiß, ob das Dingens dann irgendwann mal sich an DDOS-Attacken beteiligt ... Häääh schrieb: > Es würde mehr sinn machen das du die Software direkt auf dem ESP > programmierst. Das geht mittlerweile easy mit der Arduino-IDE. Ok, vielen Dank! Überzeugt :)
> Hier hören die Informationen auf Dann schau mal hier: http://stefanfrings.de/esp8266/index.html Das sollte Dich weiter bringen, sowohl was die AT-Firmware angeht, als auch die direkte Programmierung. Meiner Meinung nach haben beide Methode ihre Daseinsberechtigung. Ich habe auf der Seite alle wesentlichen haken und Ösen beschrieben, so dass Du selbst für deinen Anwendungsfall entscheiden kannst. > Die Verbindungssteuerung und Datenübertragung über die Serielle > Schnittstelle per AT CMDs ist schon "ziemlich vergurkt". Das sehe ich aber ganz anders. Seit dem SDK 1.5.4 funktioniert sie einwandfrei. Einige Leute raten auch von der AT Firmware ab, weil sie sich ständig ändern würde. Auch das kann ich nicht bestätigen. Ich bin seit Version 0.20 nur auf eine andere Baudrate und ein anderes Zeilen-Ende Format gestoßen. Ansonsten funktionieren alle damaligen Befehle immer noch. Es sind nur neue Befehle und neue optionale Parameter hinzugefügt worden, die man benutzen kann, aber nicht benutzen muss. > Aber dafür einen stabilen Parser zu bauen, halte ich tatsächlich nicht > wirklich für sinnvoll Das ist doch Pillepalle. Schau Dir mal in dem Projekt http://stefanfrings.de/wlan_io/index.html die Datei driver/wlan-module.h (und .c) an. Das Projekt war ursprünglich mal für UART gedacht, dort habe ich die ESP8266 Schnittstelle mit wenigen Handgriffen als Balkon dran gebaut. Ist ganz easy und wirklich sehr zuverlässig. Ich hatte das Ding 2 Monate im Dauertest, mit 2 Requests pro Sekunde. > Dieser wird allerdings auch nachgesagt eine "Homecall" Funktion > nach chinesien zu haben. Das hat hier einmal EINER behauptet, konnte es jedoch nicht nachweisen. Und weil da VIELE Interesse dran hatten, hatten viele andere es ebenfalls untersucht und letztendlich bestätigt, dass die Firmware keinen Bockmist baut. Der angebliche Beweis wurde als Fake entlarvt. > Es würde mehr sinn machen das du die Software direkt auf dem > ESP programmierst. Das würde an dem "Homecall" (wenn er denn wahr wäre) gar nichts ändern, denn der Teil des Codes, dessen Quelltext NICHT offengelegt wurde, ist 1:1 ebenso in der Arduino Umgebung drin. Und es wurde bereits festgestellt, dass der "Homecall" (wenn es ihn denn gäbe) eben in diesem Teil stecken muss.
Stefan U. schrieb: > Das ist doch Pillepalle. Schau Dir mal in dem Projekt > http://stefanfrings.de/wlan_io/index.html die Datei driver/wlan-module.h > (und .c) an. Das Projekt war ursprünglich mal für UART gedacht, dort > habe ich die ESP8266 Schnittstelle mit wenigen Handgriffen als Balkon > dran gebaut. Ist ganz easy und wirklich sehr zuverlässig. Ich hatte das > Ding 2 Monate im Dauertest, mit 2 Requests pro Sekunde. Ähm ja ... Aber nicht das, was ich eigentlich wollte. Der ESP8266 sollte auf GET-Anfragen reagieren, die zum (nachgeschalteten) µC durchreichen und dort die AT-Kommandos dekodieren und die richtigen Daten zurück liefern. Aber auf der anderen deiner Seiten steht es schon im Prinzip, wie es funktioniert ... Naja, so überkompliziert sieht das jetzt doch nicht aus.
Hab jetzt genau *das* gefunden, was ich gesucht hatte ... Eine Library mit einem ESP8266 AT-Command Decoder ... Lauffähig auf den STM32. Minimale Anpassungen, dann klappts auch mit HAL. https://majerle.eu/documentation/esp8266/html/index.html Funktioniert prima :) Im prinzip initialisiert die Lib den ESP8266 per UART und aktiviert einen TCP-Socket. Connected sich ein WLAN-Client daran, reicht der die GET-Anfrage zur Library durch, welche diese Anfrage parst und dann die Webseite ausliefert. Die Library ist recht umfangreich und kann sehr viel :) (und mit 3000 Commits wohl auch kein 5-min-Bastelprojekt)
1 | - Stable release |
2 | - Supports official AT commands software from Espressif Systems (currently, version AT 2.0 is supported) |
3 | - Supports different platforms (written in ANSI C) |
4 | - Supports RAM limited embedded systems |
5 | - Event based or blocking mode (depends on user requirements), RTOS first implementation |
6 | - Supports multiple connections at the same time (TCP, UPD, SSL) |
7 | - Supports client and/or server mode |
8 | - Supports station and softAP mode |
9 | - Supports ping to other server |
10 | |
11 | - Free to use |
thumbsup
:
Bearbeitet durch User
Mampf F. schrieb: > Im prinzip initialisiert die Lib den ESP8266 per UART und aktiviert > einen TCP-Socket. Connected sich ein WLAN-Client daran, reicht der die > GET-Anfrage zur Library durch, welche diese Anfrage parst und dann die > Webseite ausliefert. Das ist leider nur bis zu dem Teil "… reicht der die GET-Anfrage zur Library durch…" korrekt ;) Den Rest muss der Entwickler schon selber machen. Ich spiele seit einiger Zeit auch mit dieser Library rum und finde sie extrem hilfreich, weil sie einem die Arbeit mit den AT-Kommandos wirklich erleichtert. Allerdings muss man sich die Protokolle der Anwendungsschicht wie HTTP selber dazu schreiben. Ich bin gerade selber dabei, mir einen kleinen HTTP-Server für diese Library zu schreiben, weil ich keine Lust habe, für jede neue Seite denselben Code für das Parsen des Headers etc. zu schreiben. Ich möchte lieber bequem aus einem HTTP-Stream lesen und in einen schreiben, wie man es aus anderen Sprachen kennt. Mich würde interessieren, ob es hier noch andere gibt, die diese Bibliothek einsetzen und bereits in ähnlicher Weise Anwendungsprotokolle damit implemetiert haben (vielleicht ja auch Telnet oder FTP), damit man sich darüber etwas austauschen kann und nicht dieselbe Arbeit dutzendfach macht. Gruß
:
Bearbeitet durch User
A.. P. schrieb: > Mich würde interessieren, ob es hier noch andere gibt, die diese > Bibliothek einsetzen Hmm ich hatte damals im Juni das Projekt inklusive dieser Lib und HAL eingestampft und hab es quasi nochmal neu gebaut ohne HAL und ohne diese Lib. Die einfachste Lösung war tatsächlich, den ESP8266 im "Arduino-Modus" zu verwenden und damit die Libraries wie Simple Webserver (oder so ähnlich) ... Lief lange Zeit durch ohne Abstürze :) Mit dem AT-Kommando-Zeugs hab ich schlussendlich nichts gemacht und hab den ESP8 einfach per UART an meinen STM32 angebunden.
A.. P. schrieb: > Ich bin gerade selber dabei, mir einen kleinen HTTP-Server für diese > Library zu schreiben, weil ich keine Lust habe, für jede neue Seite > denselben Code für das Parsen des Headers etc. zu schreiben. Ich möchte > lieber bequem aus einem HTTP-Stream lesen und in einen schreiben, wie > man es aus anderen Sprachen kennt. > > Mich würde interessieren, ob es hier noch andere gibt, die diese > Bibliothek einsetzen und bereits in ähnlicher Weise Anwendungsprotokolle > damit implemetiert haben (vielleicht ja auch Telnet oder FTP), damit man > sich darüber etwas austauschen kann und nicht dieselbe Arbeit > dutzendfach macht. Gerade dann ist es doch sinnvoll, das auf dem ESP zu implementieren. Der hat doch die Ressourcen dafür, wozu also den eigentlichen Controller damit belasten? Ich setz z.B. gerne https://github.com/cesanta/mongoose dafür ein. Hat den HTTP-Server schon eingebaut und ist schnell am Start. Oder wie Du geschrieben hast: "und nicht dieselbe Arbeit dutzendfach macht"
Mit einer solchen Antwort habe ich eigentlich gerechnet :) Es gibt viele Gründe für mich, es auf dem Host-Controller umzusetzen und den ESP als Sklaven zu nutzen. 1) Ich muss mich nicht mit einer "IDE" (hat diesen Namen eig. nicht verdient, eher ein einfacher Texteditor) wie Arduino rumschlagen, wenn ich den ESP halbwegs einfach programmieren will. 2) Ich kann die mächtigere Peripherie meines Host-Controllers nutzen und diesen tatsächlich auch als Host nutzen. 3) Ich muss nicht zwei Controller in meiner Schaltung programmieren, sondern habe die Business-Logik allein auf meinem Host-Controller. 4) Ich muss mir nicht wieder irgendein Protokoll überlegen, wie ich Daten zwischen Host und ESP austausche, wenn ich z.B. dynamische Webseiten ausliefere. 5) Ich kann meinen Host-Controller vernünftig debuggen. 6) Ich kann einen Host-Controller nutzen, der vernünftig dokumentiert ist und die man lesen kann, ohne zig Foren oder Chinesisch studiert zu haben. Wenn ich den ESP mit der Arduino "IDE" programmiere, kann ich entweder die Websseiten, die ausgeliefert werden, fest einprogrammieren, dann habe ich aber das Problem, dass ich immer den ESP zusätzlich zu meinem Host-Controller mitprogrammieren muss, wenn sich daran was ändert. Oder ich lasse den Webserver beliebige Daten ausliefern, dann muss ich diese z.B. von einer SD-Karte einlesen. Wenn aber nun mein Host-Controller auch auf dieselbe SD-Karte zugreifen muss, habe ich wieder Schwierigkeiten. Lasse ich die Daten vom Host liefern, muss ich mir wiederum ein Protokoll ausdenken, mit dem ich möglichst beliebige Daten an den ESP liefern kann. Wenn ich den ESP stattdessen mit der AT-Firmware laufen lasse, kann ich diesen wie einen belibigen Peripherie-Baustein austauschen, wenn mal was mit ihm ist, und meine Anwendung läuft problemlos weiter. Außerdem habe ich so auch nicht immer zwei Toolchains und zwei verschiedene Programmierumgebungen geöffnet, wenn ich faktisch nur eine Anwendung entwickle.
Mampf F. schrieb: > Irgendwie ist mir das nicht ganz klar ... Mit dem ESP tauschst du die reinen Anwendungsdaten aus. Wenn du mal mit dem OSI-Referenzmodell vergleichst, dann findest du dich in der Kommunikation mit dem ESP oberhalb der Schicht 4 (Transport Layer) wieder. Der ESP stellt dir im Grunde die Anwendungsdaten auf Socket-Ebene bereit. Das Einrichten eines TCP/UDP-Sockets übernimmt dabei noch der ESP für dich, das Senden/Empfangen der Daten darüber musst du dann abwickeln. Mampf F. schrieb: > Angenommen, es kommt ein GET für ein Image, werden die Daten > base64-kodiert in ein AT-Kommando gewrappt? Kommt eben auf das Protokoll an. Der ESP schickt dir die reinen Anwendungsdaten über die Verbindung. Ob das nun Binärdaten sind, wie bei FTP, oder aber in Textform, wie das von dir angesprochene HTTP, ist dem ESP egal. Der Programmierer muss sich um die korrekte Aufbereitung der Daten kümmern. In dem von dir erwähnten Beispiel eines GET für eine binäre Datei (Bild) muss keine Kodierung vorgenommen werden, das HTTP Protokoll kann ja Binärdaten auch als solche versenden. Dass das HTTP-Protkoll selbst textbasiert ist, hat andere Gründe, es hat aber nichts damit zu tun, dass auch die Payload in Textform versendet werden muss. Du kannst also dein Bild auch als Binärdatei erhalten (bzw. versenden), das hängt von den HTTP-Headern ab (z.B. Content-Encoding und Content-Type), die mitgegeben werden. Da liegt es dann eben an dir, die Daten korrekt zu interpretieren, wenn es nicht knallen soll :) Gruß Arno
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.