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

Zitat Zitat von Philippp Beitrag anzeigen
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