NodeMCU V3 als Server stürzt nach ein paar Minuten ab.

[Klebwax]

hmmh, ich habe 5 ESP8266 clients am ESP8266 Server verbunden, und auf dem Server wird auch noch eine website aufgebaut, neben anderen services, und da hängt nichts.

Das sind keine stehenden TCP Connections. Ein WEB-Server ist ein Socket im Zustand Listen. Wenn sich ein Client (Browser) verbindet, wird eine Verbindung aufgebaut, die Seite geliefert und die Verbindung sofort wieder geschlossen. Das dauert auf einem ESP einige hundert Millisekunden, manchmal auch weniger. Der Timeout beim Verbindungsaufbau ist im Bereich Sekunden. Selbst wenn deine 5 Clients gleichzeitig versuchen, eine Verbindung aufzubauen, können sie ohne Probleme nacheinander abgewickelt werden, ohne daß ein Timeout im Client ausgelöst und damit auffällig wird. Mit allen anderen Services ist es ähnlich. Voraussetzung ist aber, daß die Verbindung am Ende der Übertragung zügig beendet wird. Deine Konfiguration kann also mit einem Socket und daher einer TCP-Verbindung gleichzeit realisiert werden.

Man muss aber aufpassen, dass while Schleifen nicht länger als ca. 5 sec ohne Unterbrechung laufen, sonst wird das interne RTOS Multipthreading blockiert und dann führt der ESP RTOS Scheduler einen Reboot aus.

Ich hab da eher 50ms in Erinnerung. Das Verhalten ist schon richtig beschrieben, aber eine lange Schleife blockiert einfach das RTOS (es ist ein kooperatives Tasking System) und der HW-Watchdog löst den Reboot aus.

MfG Klebwax

[Philippp]

Also zu der Debatte um delay() gibt es sicherlich einige Meinungen, und viel zu lernen. Ich habe einige Hobby Programmierer in meinem Bekanntenkreis, und ja, einer sagte mir auch das delay() der Grund für den Absturz meines Programmes sei. Zu diesem Zeitpunkt hatte ich nur ein delay() im Programm, und das im setup() Teil, welcher ja nur ein mal durchlaufen wird...

 
  while (WiFi.status() != WL_CONNECTED)   // Schleife läuft so lange, bis eine Verbindung zum W-LAN aufgebaut ist.
    {
      Serial.print(".");
      digitalWrite(led_WIFI_rot, HIGH);   //Zeigt an das keine Netzwerkverbindung besteht
      delay(500);
      }

Nachdem ich dieses delay() raus genommen habe, hat das Programm nicht mehr funktioniert. Rein logisch hätte der Verbindungsaufbau und das drucken des Punktes ja auch ohne klappen müssen. Hat es aber nicht. Delays sind also anscheinend ab und an notwendig.
Ich hatte es bislang so gehandhabt, dass ich ein delay() rein genommen habe wenn ich Angst hatte das die Hardware nicht hinterher kommt. Der ESP ist unterm Strich auch ein Stück Hardware. Mir fehlt es noch an Erfahrung zu sagen wie schnell die einzelnen Bestandteile des Chips sind. Pauschal zu sagen das sich Chips nicht totrechnen können finde ich gewagt. In meiner einfachen Welt braucht jede Rechenoperation Energie. Dieser Energieverbrauch schlägt sich unter anderem in Wärme nieder. Und da wären wir dann beim Überhitzungsproblem. Auch denke ich wie angedeutet, das nicht alle Teile des ESP gleich schnell sind, was zu Problemen führen kann.
Wie erwähnt bin ich Anfänger, und hoffe das ich hier noch viel lerne. Ich hoffe das es niemanden stört das ich es mir trotzdem leiste Aussagen kritisch zu hinterfragen.

Gruß,
Philippp

[Klebwax]

Erstmal vorneweg, Software ist eine Ingenieurwissenschaft und nicht Magic oder Vodoo.

Also zu der Debatte um delay() gibt es sicherlich einige Meinungen ..

In einer Wissenschaft gibt es ganz selten "einige Meinungen", insbesondere bei Themen, die schon seit Jahrzehnten abgehakt sind. Wenn ein erfahrener Programmierer in einem Programm unmotivierte delays sieht, weiß er sofort, wie er den Verfasser diese Codes einzuschätzen hat. Und ein wenig spezifischer zu delays. Das kann einfach ein Stück Code sein, der die CPU eine gewisse Zeit mit Sinnlosem beschäftigt, damit halt die Zeit verstreicht. Es kann aber auch ein Call in ein Laufzeitsystem, ein OS oder RTOS sein, das neben der Verzögerung dem Scheduler die Chance gibt, einen Taskwechsel vorzunehmen. Diese könnte man natürlich mit den entsprechenden Calls direkt auslösen, dann wäre es für Anfänger leichter verständlich.

Pauschal zu sagen das sich Chips nicht totrechnen können finde ich gewagt. In meiner einfachen Welt braucht jede Rechenoperation Energie.

Richtig, sie braucht Energie. Und so ein Chip ist dafür gebaut ständig zu rechnen, immer, ohne Pause. Er rechnet sich nicht tot, kann er nicht. Das klassische embeded Programm besteht aus einer while(true) Schleife. Das ist auch bei Arduino nicht anders. Nach einem Call auf setup() kommt ein Call auf loop(), dann macht das Arduino Framework seine Hausaufgaben und called wieder loop(). Und das immer wieder.

Neuere Chips haben die Möglichkeit, den ganzen Chip oder Teile stillzulegen um Energie zu sparen, z.B. für den Batteriebetrieb. Das ändert aber nichts an der Tatsache, daß sie, wenn die Batterie nur groß genug ist, auch durchlaufen können. Es gibt aber auch Systeme, die mit 100% (thermischer) Überlast laufen können, solange sie es nicht dauernd tun und daher nicht überhitzen. Das wirst du im embeded Bereich aber kaum finden. Der ESP und alle gängigen System sind sicher nicht so aufgebaut.

Ein ESP ist aus der Sicht eines Programmierers beileibe nicht ein Stück Hardware, sondern hat zusätzlich eine Art Betriebssystem an Bord, daß WLAN und TCP/IP abhandelt. Das ist schon mal ne Menge Code. On Top kommt noch die Arduino Laufzeitumgebung. Für einen Programmierer ist es wichtiger die Software zu verstehen und richtig zu behandeln als die Hardware. Um die haben sich die Entwickler des Systems schon gekümmert.

Mir fehlt es noch an Erfahrung zu sagen wie schnell die einzelnen Bestandteile des Chips sind

Das ist auch unerheblich. Wie schnell z.B. ein UART ein Byte sendet muß man nicht wissen, der UART hat dafür Statusbits, die das anzeigen und die man gefälligst auswerten sollte. Das gleiche gilt auch für Systemfunktionen. Sie brauchen halt solange, wie es dauert. Sollte die Ausführung nebenläufig erfolgen, in einem Interrupthandler oder einer eigenen Task, gibt es pflichtgemäß Möglichkeiten festzustellen, wann der Vorgang abgeschlossen ist. Ein delay im embeded Bereich macht nur dann Sinn, etwas im Bereich Mikrosekunden zu verzögern, weil etwas an einem IO nicht schnell genug ist. Und wenn zuviele auch lange delays im Code auftauchen, siehe oben.

Und zu deinem Beispiel: Wie ich schon schrieb, darf das kooperative RTOS im ESP nicht zu lange angehalten werden. Die Funktion WiFi.status() löst offensichtlich keinen Taskwechsel aus und das Programm stürzt ab. Die Funktion delay(500) tut das scheinbar und das RTOS läuft weiter. Ich vermute das der Wert im delay unerheblich ist und jeder andere Systemcall, der einen Taskwechsel erzeugt ebenfalls funktioniert. Ich hab keine Ahnung, wie gut die Doku zur Arduino-Umgebung aus dem ESP ist, dort sollte sich aber alles finden. Zur Not kann man auch den Source Code lesen, für manche Programmierer ist das Doku genug. Die schreiben nicht gerne Texte.

MfG Klebwax

[HaWe]

Ich vemute auch, dass überall ein delay(1) grundsätzlich ausreichen müsste, weil dies dem Scheduler ermöglicht, auch noch die WiFi-Funktionen ständig(!) parallel abzuarbeiten (Multithreading auf 1 Kern!). Und die laufen tatsächlich ständig im Hintergrund nebenher, egal was in der selber geschriebenen "Hauptprogramm-loop()" passiert.
Bei der Einwahl anfangs kann es u.U. sinnvoll sein, etwas länger als nur 1ms zu warten, weil die entspr. WiFi-Routinen zusammen mit der Hardware einfach eine gewisse Zeit benötigen, das kannst du aber ganz einfach selber austesten, indem du statt delay(500) einen kleineren Wert einsetzt (ohne es komplett zu löschen) - allerdings macht dann das Schreiben von Punkten jede einzelne ms wenig Sinn, denn da kommt der Serial Monitor gar nicht hinterher, und was nützt es einem, wenn die Einwahlschleife hunderttausende Punkte per Serial Monitor auf den PC-Screen schreibt, bis endlich Wifi connected ist.
Was deine delay(10) bei der Client-Kommunikation besser bewirken als ein delay(1), kann ich aber nicht beurteilen, denn hier verstehe ich zu wenig von deiner Programm-Architektur (ich selber verwende ja wie gesagt eine andere Lib mit einer anderen Technik).