Hallo Gemeinde, ich bräuchte mal euren Rat bzgl. des ESPs in Verbindung mit einem anderen Host-Controller. Zunächst ein paar Worte zu der Vorgeschichte: Ich arbeite hauptsächlich mit Controllern der STM32-Reihe (aktuell mit den kleineren STM32F030x). Um für ein paar zukünftige Projekte Netzwerkfähigkeit mit rein zu bringen spiele ich nun schon seit einiger Zeit auch mit dem ESP8266 herum. Diesen verwende ich bis dato nur mit der AT-Firmware und habe dafür auch einen ganz brauchbaren AT-Parser gefunden. Basierend auf diesem baue ich wiederum derzeit eine Art Socket-Layer (mit üblichen Methoden wie socketSend(), socketReceive() etc.), um mir damit beliebige Anwendungsprotokolle (HTTP, MQTT etc.) draufzubasteln. Leider kann aber auch dieser AT-Parser die Eigenheiten der AT-Firmware nicht ganz ausmerzen, sodass das Basteln meiner Anwendungsprotokolle mehr schlecht als recht vorangeht. An allen Ecken und Kanten bleibt immer mal wieder was hängen. Nun weiß ich, dass man den ESP auch in der Arduino-Umgebung programmieren kann und dort auch bereits Protokolle wie HTTP, MQTT, DNS und weitere bereits gegeben hat. Was mich allerdings bislang an diesem Weg immer gestört hat, sind unter anderen die folgenden Punkte: * Mangelnde Debug-Fähigkeit des ESP8266 (mir ist zumindest keine über serielle Ausgaben bekannt) * Mangelnde Features der Arduino-Umgebung * Der ESP müsste immer zusätzlich programmiert werden über eine separate Toolchain und Schaltung, wenn sich an der Firmware meines Projekts etwas ändert Ich möchte gerne den STM als Host-Controller nutzen, da ich mich in dieser Controller-Reihe sehr gut zurecht finde und auch eine für meine Ansprüche gute Umgebung vorfinde (Tools, Dokumentation, Community) und auf diesen besonders schnell entwickeln kann. Ich möchte daher den ESP idealerweise wie eine zusätzliche Peripherie einfach als universellen Sklaven nutzen, welcher meine Anwendungsdaten einfach weiter über die Luft schickt. Ich weiß, dass der ESP selbst ein vollwertiger Controller mit nicht zu verachtenden Resourcen und Geschwindigkeit ist, allerdings sträube ich mich noch sehr dagegen, den einen Teil meines Projekts auf dem ESP (in Arduino oder mit dem SDK) zu entwickeln und den anderen Teil für den STM dann wieder mit einer vollkommen anderen Umgebung und Tools. Außerdem möchte ich mich nicht entscheiden müssen zwischen "wenn netzwerkfähig, dann ESP als alleinigen Controller unter Arduino programmiern" und "für alles andere deine treuen STMs" :) Nun aber zu meiner Frage bzw. meinem Dilemma: Seht ihr eine Möglichkeit, recht einfach den ESP mittels Arduino so universell zu programmieren (also z.B. den Webserver draufzusetzen), dass ich diesen dann beliebig in meine Projekte einbinden und dann die Daten schicken kann? Was aus meiner Sicht für die Arduino-Lösung spricht, ist die Erprobtheit des Webservers dafür und dass ich damit diverse Komforts nutzen kann, wie z.B. auch Dateien per HTTP-Upload zu empfangen etc. Dagegen spricht allerdings, dass ich eben nicht beliebige Seiten ausliefern kann, da ich diese entweder vorher fest im ESP kodieren müsste oder diese aber von einer SD-Karte abfragen müsste, auf die wiederum der STM zugreift. Lange Rede kurzer Sinn: was ich im Idealfall suche, ist eine Möglichkeit, den ESP so aufzusetzen, dass dieser zuverlässig z.B. HTTP oder MQTT spricht (ob nun über Arduino oder was auch immer), ich aber weiterhin die Flexibilität habe, von meinem Host die Daten zu versenden und vorher auch bei Bedarf eine entsprechende Manipulation etc. dieser vorzunehmen. Ich möchte den ESP somit wenn möglich nur einmal (initial programmieren) und diesen danach nicht mehr anrühren müssen und nur noch seriell mit ihm kommunizieren. Sieht hier eine eine adäquate Lösung oder hat vielleicht Hinweise für einen Weg, an den ich noch nicht gedacht habe? Oder seid ihr der Meinung, dass ich eher nach der eierlegenden Wollmilchsau suche und entweder mit der AT-Firmware rumkrebsen muss oder eben auf Arduino switchen? Ich weiß im Übrigen natürlich, dass es auch noch ganz anders geht, da ich auch schon eine netzwerkfähige Anwendung mit einem STM32F407 + ATWILC1000 gebaut habe. Damit konnte ich auch vernünftige Sachen inkl. IPv6 und massig Ressourcen umsetzen, aber da schiebt schon der Preis beider Controller (~20€ zusammen) einen Riegel vor und ist somit nicht für diverse kleine Netzwerkschaltungen geeignet. Daher ist meine persönliche Vorgabe eben: kleiner STM32 + ESP8266. Für sachdienliche Hinweise bin ich sehr dankbar :) Gruß
:
Bearbeitet durch User
...uiuiui, der ist aber lang geworden XD
Ich halte das immer so: Wenn man es mit einem Controller erledigen kann nimmt man nicht zwei.
Hallo A, das sollte kein Problem sein das universell hinzubekommen, du musst Dir halt ein eigenes Protokoll für die serielle Schnittstelle ausdenken (was nicht die Nachteile der AT-Firmware hat). Für HTTP könntest du z.B den Requeststring an deinen STM senden und der liefert dann die Daten für die Antwort. Statische Seiten kannst du auch im SPIFFS des ESP ablegen die du dort problemlos auch per HTTP-Upload ändern kannst-- dann brauchst du den ESP nicht neu zu programmieren. Sascha
>* Mangelnde Features der Arduino-Umgebung
Was genau meinst Du damit?
Die AT Firmware arbeitet zumindest in der Version 1.5.4 sehr zuverlässig - auch mit mehreren gleichzeitigen Verbindungen. Wenn bei Dir etwas stockt, hast du falsch programmiert oder ungeeignete Libraries verwendet. Eventuell magst du von meinem Projekt (http://stefanfrings.de/wlan_io/index.html) abgucken, da wird ein ESP-Modul mit AT-Firmware angesteuert, sogar mehrere Verbindungen gleichzeitig samt der Möglichkeit, die Kommunikation zum Debugging mitzulesen. Da kannst du sehen, wie man die Antworten der AT Befehle mit wenigen Zeilen Code effizient auseinander dröselt. Natürlich kannst du dir eine andere Firmware für den ESP programmieren, die ein anderes Kommunikationsprotokoll verwendet. Aber bis die dann so stabil läuft, wie die AT Firmware, werden sicher noch einige Monate vergehen. Vor allem, wenn sie wirklich universell sein soll. Vor allem müsstest du dir überlegen, wie du Befehle und Daten trennst und wie du mit gleichzeitigen Verbindungen umgehen willst. Spontan fällt mir gar keine Lösung ein, die wesentlich besser und zugleich einfacher sein würde, als die AT-Firmware. Einzig cool fände ich, wenn alle Zahlen eine feste breite hätten. Viel einfacher wird es, wenn du für den jeweiligen Anwendungsfall eine spezifische Firmware schreibst. Mit Arduino ist das auch relativ einfach. Du könntest den Webserver und die Webseiten samt Javascript, CSS Bilder, etc alles direkt im Flash des ESP Moduls halten. Dieser kommuniziert dann mit deinem STM32, um die eigentlichen Nutzdaten abzurufen. Oder anders herum: Der STM sendet Daten an den ESP, welcher sie bis zum nächsten Abruf im RAM zwischenspeichert. Zum Debugging: Wie stellst du dir debugging (über text Meldungen hinaus) vor? Willst du Haltepunkte setzen und dann in Variablen hinein gucken? Das wird nicht funktionieren, weil dabei die Netzwerkanbindung ausfallen würde. Beim ESP8266 ist es ja ganz wichtig, dass die Firmware für den WLAN Part ständig ausgeführt wird. Dort sind maximal 20ms Unterbrechung zugelassen.
Ich empfehle dir auch den esp als alleinigen anwendungsprozessor. Ansonsten kann der esp auch als spi slave booten und es gibt eine spi-slave firmware zur verwendung als sdio wifi adapter. Kommt aus der android / linux ecke.
Vielleicht ist ja ESPeasy was für dich. https://www.letscontrolit.com/wiki/index.php/ESPEasy_Command_Reference oder sowas http://www.zoobab.com/esp8266-serial2wifi-bridge da gibt es bestimmt noch einige gute Projekte. ESPeasy kann ich empfehlen wenn es für deinen Zweck passt.
holger schrieb: > Ich halte das immer so: Wenn man es mit einem Controller > erledigen kann nimmt man nicht zwei. Grundsätzlich wäre das auch meine Sichtweise :) Ich möchte allerdings nicht zu viel auf dem ESP programmieren, da mir nicht wohl dabei wäre, auf einem System zu arbeiten, dessen Doku ich nur auf Chinesisch kriege und mir den Rest über diverse Foren zusammenklauben muss :) Ich habe da nunmal gerne noch die Kontrolle und würde ich nur den ESP nehmen, müsste ich wahrscheinlich zu häufig sagen "ach, das geht so nicht, dann muss ich da wahrscheinlich drauf verzichten". Und das will ich nicht :) chris schrieb: >> * Mangelnde Features der Arduino-Umgebung > > Was genau meinst Du damit? Im Grund meine ich damit, dass Arduino m.M.n. nichts weiter ist, als ein Texteditor mit integriertem seriellen Terminal (und auch das mit kaum Funktionen). Natürlich lässt sich über alles, was über einen Texteditor hinausgeht, streiten - ich kenne auch die Leute von der Fraktion Texteditor+Make only. Ich schaue auch gerne hinter die Kulissen und mache einiges zu Fuß, aber wenn ich schnell produktiv sein will, dann darf es doch schon etwas mehr sein, als Arduino es mir bereitstellt :) @Stefan Us: Ich hatte mir deine Projekte bereits durch einen anderen Thread mal angesehen und ich sage ja nicht, dass die AT-Firmware nicht die beste Lösung aktuell sei. Ich habe zur Zeit die Version 1.4 der AT FW drauf und die läuft an sich ja auch stabil soweit. Auch der Parser, den ich nutze, kommt damit gut zurecht. Allerdings: dadurch, dass die AT mir nur die reinen Nutzdaten schickt und ich nie weiß, ob noch Daten kommen werden, fällt es mir schwer, das tasächliche Stream-Ende zu erkennen, trotz der Hilfe des Parsers. Da fehlt mir vielleicht auch noch etwas mehr Verständnis des ESPs. Ich weiß, dass der ESP bis zu 5 Verbindungen simultan offen haben kann, aber was sagt das über die Reihenfolge des Datenempfangs aus, wenn das alles eingehende Verbindungen sind? Schicke ich bspw. auf einer Verbindung 200 kB und auf einer zweiten etwas verzögert nochmal 5 kB an den ESP, werden dann diese 5 kB irgendwo zwischen den anderen 200 kB auftauchen oder handelt der ESP die Daten Verbindung für Verbindung ab? Und weißt du, wie groß der interne Empfangspuffer des ESP ist und wie viel Zeit ich maximal hätte, um die bereits erhaltenen Daten zu verarbeiten (auf SD schreiben o.ä.)? Danke für eure zahlreichen Tipps und Anregungen! Gruß
:
Bearbeitet durch User
Stefan U. schrieb: > Die AT Firmware arbeitet zumindest in der Version 1.5.4 sehr zuverlässig > - auch mit mehreren gleichzeitigen Verbindungen. Wenn bei Dir etwas > stockt, hast du falsch programmiert oder ungeeignete Libraries > verwendet. Moin, wo hast Du die 1.5.4 her? Aktuell stehen wir doch bei 1.5.1, oder?!
> Moin, wo hast Du die 1.5.4 her? Aktuell stehen wir doch bei 1.5.1, Die habe bei von der Wesbeite von Espressif heruntergleaden (ich habe das ganze SDK runtergeladen, aber nur die vorcompilierte Firmare extrahiert). Aktuell ist Version 2.1.0. > dadurch, dass die AT mir nur die reinen Nutzdaten schickt und ich nie weiß, > ob noch Daten kommen werden, fällt es mir schwer, das tasächliche Stream-Ende > zu erkennen, trotz der Hilfe des Parsers Das Ende eines HTTP Requests erkennt man bei HTTP 1.0 mit Hilfe des Content-Length Header oder daran, dass die Verbindung geschlossen wurde. Bei HTTP 1.1 gibt es noch eine andere Übertragungsart mit dem namen "Chunked-Transfer", die haben eine Ende-Markierung. Bei anderen Protokollen hängt es vom Protokoll selbst ab. TCP Verbindungen sind von "Natur" aus Stream orientiert. Anfang eines Streams ist der Verbindungsaufbau,, und Ende des Streams aus die Trennung der Verbindung. Alles andere dazwischen liegt nicht in der Verantwortung des TCP, sondern das musst du selbst programmieren. So oder so wird weder der AT-Parser noch ein eigens geschriebener Ersatz für die AT Schnittstelle dabei helfen. Das HTTP Protokoll (oder welches auch immer du verwendest) liegt eine Ebene höher im Protokoll-Stack. Anders ist es bei UDP. Das empfängst du für jedes einzelne Paket genau eine AT Meldung. Das wird von der AT Firmware ebenfalls unterstützt.
@Stefan Us: Danke für die Erklärung! Ich weiß, wie das HTTP abläuft und wie die einzelnen Übertragungsmöglichkeiten ausschauen, allerdings habe ich bei meinen letzten Posts wohl schon einen totalen Knoten im Hirn gehabt XD Ich hatte schon vollkommen ausgeblendet, dass es ja - wie du richtig sagst - einzig Aufgabe des Anwendungsprotokolls ist, mitzuteilen, wie viele Nutzdaten denn zu erwarten sind und das es hierfür auch in den darunterliegenden Schichten ja auch keinerlei Feld in den Headern o.ä. gibt. Das war total mein Denkfehler. Mal an dieser Stelle dann eine Frage am Beispiel HTTP: Ich empfange nun fröhlich mit den AT-Kommandos mein HTTP-Paket, welches nun bspw. 1 kB (exkl. Header) groß sein "soll" (lt. Header). In meinem Server-Code lese ich nun aus dem Stream in 100 Byte-Päckchen, finde irgendwann die Content-Length-Angabe (= 1000 B) und fange ab dem Ende des Headers mit jedem folgenden Byte an, die zu erwartende Restlänge runterzuzählen. Nun bin ich natürlich ein Schelm und schicke meinem ESP bewusst statt 1000 B nur 900 B in meinem HTTP-Request. Wäre es da nun nicht gut, wenn mir meine Methode socketReceive() nun beim Versuch, die letzten 100 B aus dem Stream zu lesen ein END_OF_STREAM (z.B.) signalisieren würde, damit der HTTP-Server sofort weiß "Aha, da werden also wohl die fehlenden 100 B nicht mehr kommen, kann aufhören" und einen Fehler schmeißt? Wie machen das denn die "erwachsenen" Server (Apache, nginx & Co.)? Erkennen die das Stream-Ende oder ist man laut Protokoll dazu verpflichtet, bei noch fehlenden Daten den Timeout abzuwarten und erst danach einen Fehler zu melden? Entschuldigt bitte diese konkrete Frage, aber das brennt mir aktuell in diesem ganzen Zusammenhang auf der Seele und ich möchte nur sichergehen, dass ich da nicht versuche etwas zu implementieren, was ein Server so eigentlich gar nicht abhandelt. Gruß
> END_OF_STREAM Das hast du ja nur, wenn die Verbindung getrennt wurde. Bei HTTP 1.1 kannst du mehrere Requests direkt hintereinander empfangen. Der zweite Request kann sogar schon rein kommen, bevor du den ersten beantwortest hast. > Wie machen das denn die "erwachsenen" Server Wenn da mehr Daten kommen, als erwartet, musst du davon ausgehen, daß der Überschuss zum nächsten HTTP request gehört. Falls dessen erste zeile dann "komisch" aussieht, würdest du die Verbindung droppen. Wenn weniger Daten kommen, als erwartet, würdest du in einen Timeout laufen. Auch dann würdest du die Verbindung droppen. > Die AT Firmware kann alles, was du dazu brauchst.
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.