ESP8266 - Artikel zum Wiki

[Torsten C. (torsten_c)]

Hallo zusammen,

* ich baue gerade eine ESP8266-Bibliothek (ARM mit
  DMA-Ringbuffer auf STM32),
* mir war dabei im Artkel ESP8266 ein Fehler aufgefallen und
* ich habe eine kleine Frage.

Dieser Thread soll den Anspruch haben, Fragen, die Im Wiki nicht 
beantwortet werden, stellen zu können. Wenn Antworten da sind, würde ich 
die im Wiki ergänzen.

Zu meiner Frage: Ich eröffne mit AT+CIPSERVER=1,80 einen Server für 
HTTP-Requests. Wenn ein Browser zugreift, kommt "Link". Wenn der nächste 
Zugreift, kommt nochmal "Link".

An +IPD,0,… oder +IPD,1,… usw. kann ich erkennen, von welchem Request 
die empfangenen Daten gerade kommen.

Nun muss ich die Daten ja sammeln, den HTTP-Herader auswerten usw.. 
Dafür benutze ich einen Zustandsautomaten.

Meine Frage: Wenn die Verbindung abgebrochen wird, kommt ja ein 
"Unlink". Aber wie finde ich heraus, welcher Request gerade abgebrochen 
wurde? Ich muss ja die Statemachine für den einen Request weiter laufen 
lassen und die andere für das nächste "Link" zurücksetzen.

[Stefan F. (Gast)]

Bei HTTP spielen Verbindungsaufbau und Ende keine Rolle. Wenn dein 
Server von diesen Ereignissen abhängt, hast du ihn fehlerhaft 
implementiert.

Entscheident sind Requests und Response. Ein Request endet mit einer 
Leerzeile. Die Response endet nach der im Header angekündigten Anzahl 
von Bytes.

Wenn dein Server keine Ahnung hat, wie viele Bytes er senden wird, kann 
er alternativ auch auf die ANgabe im Header verzichten und stattdessen 
das Ende durch Trennen der Verbindung ankündigen. Aber das sollte man 
vermieden, wenn es irgendwie geht. Denn so können die Browser keinen 
anständigen Ladebalken anzeigen und der Browser muss nach jeder 
einzelnen Dateil immer wieder eine neue Verbindung aufmachen, was Zeit 
kostet.

Zusätzlichen arbeiten Server und Browser mit einem Timeout 
(typischerweise 60 Sekunden) damit sie sich nicht aufhängen.

[Torsten C. (torsten_c)]

Stefan Us schrieb:
> Bei HTTP spielen Verbindungsaufbau und Ende keine Rolle. Wenn dein
> Server von diesen Ereignissen abhängt, hast du ihn fehlerhaft
> implementiert.

Ob das Wort "Fehlerhaft" hier angemessen ist? Zumindest ist so ein 
Server dann nicht robust programmiert.

Bei drei oder vier offenen Verbindungen kann ich mir schon vorstellen, 
dass bei einem Abbruch und Neuaufbau einer Verbindung mal ein 
Requst-Header versehentlich für Upload-Daten des Vorgängers gehalten 
wird.

Aber mit dem ESP8266 wird man solche Anwendungen kaum haben und ich will 
hier jetzt keine Grundsatzdiskussion über irgendwelche Sonderfälle, die 
theoretisch möglich wären.

Jedenfalls habe ich wohl nichts übersehen: Es hätte ja sein können, dass 
es eine Möglichkeit gibt, bei einem "Unlink" den Kanal herauszufinden.

Stefan Us schrieb:
> Wenn dein Server keine Ahnung hat, wie viele Bytes er senden wird…

Bei "+IPD,0,… oder +IPD,1,… usw."^^ geht es um empfangene Daten 
(Requests), nicht um gesendete.

HTTP ist ja nicht das einzig denkbare, was man mit Telnet machen kann. 
Dann muss man halt alle Protokolle so implementieren, dass man mit einem 
"Unlink" ohne Kanalnummer auskommt.

[Stefan F. (Gast)]

Ja, offensichtlich fehlt bei der Unlink Meldung die Kanalnummer.

Hast du mal AT+CIPSTATUS? probiert. Vielleicht hilft dessen Ausgabe?

[Torsten C. (torsten_c)]

Stefan Us schrieb:
> Hast du mal AT+CIPSTATUS? probiert. Vielleicht hilft dessen Ausgabe?

Cool, danke. :-)

Keine Verbindung:

AT+CIPSTATUS
STATUS:4

OK

Zwei Verbindungen:

AT+CIPSTATUS
STATUS:3
+CIPSTATUS:0,"TCP","192.168.178.21",56694,1
+CIPSTATUS:1,"TCP","192.168.178.21",56703,1

OK

Also nach jedem "Link" oder "Unlink" einfach mal nachschauen! Danke!

PS: Wobei ich mich frage, ob man im Wiki-Artikel alle Kommandos usw. 
genauer beschreiben sollte. Hier z.B. gibt es eine FW mit deutlich 
umfangreicheren Kommandos:

https://github.com/igrr/atproto

Da macht eine Gesamtübersicht eigentlich nur Sinn, wenn auch immer dabei 
steht, mit welcher Firmware welches Kommando unterstützt wird. Bei mir 
z.B.:

> AT+GMR => 00160901
> AT+GMM => ERROR
> AT+GSN => ERROR
> ATV => ERROR
> ATE0 => no this fun
> ATQ1 => ERROR
> AT+GMEM => ERROR
> AT+IDBG? => ERROR
> AT+IPR? => ERROR

[Stefan F. (Gast)]

Die Leute von Boxtec Shop haben sich große Mühe gegeben, hilfreiche 
Infos zusammenzutragen: 
http://playground.boxtec.ch/doku.php/wireless/esp8266

[Torsten C. (torsten_c)]

Stefan Us schrieb:
> Die Leute von Boxtec Shop haben sich große Mühe gegeben

Sieht gut aus. Danke. Kann man das editieren?

…boxtec.ch/…/esp8266 schreibt:
> Die Ausgabe ist wie folgt aufgeteilt:
> +IPD,<id>,<len>,<data>

Richtig wäre mit Doppelpunkt :
> +IPD,<id>,<len>:<data>

Scheint leider kein Wiki zu sein.