Abgesehen von einer ersten Helo-World Anwendung habe ich noch nichts mit NodeMCU gemacht. Ich habe irgendwo gelesen, dass NodeMCU den gesamten Flash Speicher nutzen kann, um Sripte von dort auszuführen. Ich habe über 3 Megabyte frei, da müsste also eine ganze Menge rein passen. Andererseite habe ich ich Netz viele Problembericht gefunden, wo Leute schreiben, dass sie schon an relativ kleinen Programmen an der Speichergrenze (RAM) scheitern. Diese Beiträge sind allerdings fast alle aus dem Jahr 2015. Ich suche aktuelle Informationen über die Begrenzungen des Speichers und wie viel RAM überhaupt für welche Funktionen benötigt werden. Anscheinend ist es nämlich so, dasss das gesamte Script als Quelttext in die kostbaren wenigen Kilobytes RAM passen muss. Stimmt das? Oder lädt der Interpreter nur einzelne Zeilen in sein RAM? Ich hoffe, dass das alles irgendwo schonmal jemand aufgeschrieben hat, aber ich habe nichts gefunden. Kennt jemand einen hilfreichen Link zu diesem Thema? Die Seite von NodeMCU selbst scheint nicht hilfreich zu sein, wenn man anch denen geht, kann NodeMCU Eier legen, Kaffee kochen, Kinder kriegen und alle Probleme der Welt lösen. Mir scheint es fast so, dass die sämtliche Haken und Ösen zu verbergen versuchen.
Stefan U. schrieb: > Abgesehen von einer ersten Helo-World Anwendung habe ich noch nichts mit > NodeMCU gemacht. Dann reicht dein Speicher doch für die Dinge die du machst. ;-) Was spricht dagegen, einfach mal den Speicher mit ein paar anspruchsvolleren Anwendungen auszuloten?
Das Flash ist serielles Dataflash. Passt viel rein, ist aber naturgemäss wenig geeignet, daraus direkt Programme auszuführen. Zumindest nicht in Form definierter Funktionen. O-Ton: "If you are trying to implement a user-interface or HTTP webserver in your ESP8266 then you are really abusing its intended purpose. When it comes to scoping your ESP8266 applications, the adage Keep It Simple Stupid truly applies." https://nodemcu.readthedocs.io/en/master/en/lua-developer-faq/ Deutlich mehr Schmackes hat der Nachfolger ESP32. Da muss man aber mit dem C-SDK Vorlieb nehmen, denn mit einem NodeMCU dafür ist es nicht so weit. Der Hersteller des Chips hat denen kurz von knapp den Boden unter den Füssen weggezogen.
Man sollte auch im Auge behalten, dass der ESP8266 kaum echte I/O drin hat. Die Lua-Libs für Hardwaresteuerung sind praktisch durchweg Software. Das kann Nebeneffekte haben, wie etwa Störungen in der PWM. Wer dran denkt, einen µC per I2C anzuschliessen: Ich las, dass clock stretching nicht vorgesehen sei. Freunde vom RasPi kennen dieses Spiel schon. :-(
A. K. schrieb: > Der Hersteller des Chips hat denen kurz von knapp > den Boden unter den Füssen weggezogen. Was war los? Wann war das?
Moin, der RAM auf einem ESP8266-Chip ist begrenzt, es gibt keinen Swap-Bereich oder ähnliches, dass sollte klar sein. Abhängig von den reincompilierten Modulen hat man ca. 40-45kByte zur Verfügung, mit denen man aber schon eine Menge anfangen kann... Stefan U. schrieb: > ...wenn man > anch denen geht, kann NodeMCU Eier legen, Kaffee kochen, Kinder kriegen > und alle Probleme der Welt lösen. natürlich geht es, wenn man sich ein wenig mit Lua beschäftigt! Trick dabei ist z.B. nicht ein monolithisches Programm zu schreiben, sondern alles in Module auslagert, welche man nur dann lädt, wenn sie benötigt werden und dann auch gleich wieder aus dem Speicher entfernt, wenn sie nicht mehr gebraucht werden. Ich habe das mal in einer halbwegs komplexen Anwendung gemacht, in der diverse Informationen auf einem OLED angezeigt werden. Die einzelnen Screens sind via Taster durchschaltbar. Die Logik der einzelnen Screens ist in Modulen ausgelagert, soll ein bestimmter Screen angezeigt werden, wird der vorherige aus dem Speicher entfernt und der anzuzeigende geladen... https://github.com/boerge42/nodemcu_scripts/tree/master/weather_clock_my_server (mit Sicherheit noch nicht perfekt, aber das beschriebene Prinzip sollte erkennbar sein) Und noch ein "Lua-Ding": Lua-Scripte werden vor der Ausführung im Interpreter in Bytecode vorübersetzt und erst dann ausgeführt (ähnlich Java etc.). Diesen Bytecode kann man auch selbst schon vorher generieren und dann nur noch diesen ausführen, dass spart enorm viel wertvollen RAM. Gleiches gilt natürlich auch für die Module (RTFM --> Suchreihenfolge beim Laden von Lua-Module). Ach so, weiterhin ist auch hilfreich mal über folgende Dinge im Zusammenhang nachzudenken: * NodeMCU arbeitet asynchron und ereignisgesteuert * Reichweiten von lokalen und globalen Variablen und Funktionen Ich verweise dabei auf den "Speicherselbstreinigungsmechanismus" von Lua. Eine coole Sache, aber man muss dem Interpreter halt die Chance geben, Speicherobjekte ohne Referenz zu erkennen, um den belegten Speicher wieder freizugeben zu können! Also, beschäftige dich doch mal mit Lua im allgemeinen und NodeMCU im speziellen und du wirst viele Dinge finden, die auch komplexere Lua-Programme auf einem ESP8266 ermöglichen. Das so ein Chip keine Rakete steuern kann, sollte klar sein...:-)... > Mir scheint es fast so, dass die > sämtliche Haken und Ösen zu verbergen versuchen. wie kommst du zu dieser Ansicht? Lese doch einfach mal das NodeMCU-Manual durch (welches meiner Meinung recht ausführlich ist) und besorge dir auch ein gutes Lua-Buch. Grüße Uwe
Richard B. schrieb: > Was war los? > Wann war das? In aller Kürze, so wie ich das beim Überfliegen mitnahm: Der SDK vom ESP8266 fusst auf einem RTOS, das zunächst auch im SDK der Betaversion des ESP32 Verwendung fand. Für die Release hingegen haben sie den SDK dann auf eine andere Basis gestellt.
NodeMCU als Board ist schick, hab ich mehrere hier, aber von der Firmware und den darauf eingesetzten LUA Scripten bin ich nicht sonderlich angetan, da kam schnell die Meldung von wegen zu wenig Speicher und es war mir auch zu viel Fricklerei mit den Skripten usw... Was aber gut geht ist die Arduino IDE: Hier bekomm ich I²C, Sensortreiber, HTTPS (nicht nur HTTP!) problemlos auf den ESP8266 und anschließend waren noch mehr als 50% frei. Und Deep-Sleep funktioniert sogar auch noch kinderleicht. WiFiManger muss ich mir dann noch anschauen, das wurde letztens auf Hackaday vorgestellt, damit bekommt man eine fertige Lösung für nicht hart kodierte Zugangsdaten... https://github.com/tzapu/WiFiManager
Danke für eure Antworten, sie sind auf jeden Fall hilfreich. Eigentlich bin ich kein Freund von Arduino, allerdings scheint das den schnellsten Einstieg zu bieten und dank C++ nicht unter Speichermangel zu leiden. Ich denke, meine Tüte ESP Module wird nun der Anreiz sein, mich doch mal ernsthaft mit der Arduino IDE zu beschäftigen. Vermutlich kann ich irgendwie auch eine ausgewachsene IDE zum editieren benutzen, und dann die Arduino IDE nur noch zum Compilieren und Flashen verwenden. Mal sehen. Auf ein paar Rückfragen möchte ich noch eingehen: > Was spricht dagegen, einfach mal den Speicher mit ein paar > anspruchsvolleren Anwendungen auszuloten? Um eine anspruchsvolle Anwendung zu schreiben, müsste ich erstmal eine Menge lernen. Das möchte ich aber nicht dreimal für drei unterschiedliche Spracjen/SDK's machen. Momentan bin ich noch in der Phase, eine Programmierumgebung auszuwählen. > Man sollte auch im Auge behalten, dass der ESP8266 kaum echte I/O > drin hat Ist mir bewusst. Ich kann mir vorstellen, Schieberegister dran zu hängen. oder bei zeitkritischen bzw. komplexen Anwendungen einen zweiten Mikrocontroller (das habe ich ja schon gemacht). Jetzt geht es mir allerdings darum, auszuloten, was man mit den ESP Modulen Standalone machen kann.
Stefan U. schrieb: > Vermutlich kann ich irgendwie auch eine ausgewachsene IDE zum editieren > benutzen, und dann die Arduino IDE nur noch zum Compilieren und Flashen > verwenden. http://platformio.org/ Installiert u.A. auch das ESP-Arduino ohne die Arduino-IDE (also nur den compiler, helper-tools und libs), lässt sich in andere IDEs integrieren, oder bringt den "atom" editor mit.
Ich kann Uwe B. eigentlich nur komplett zustimmen, der hat im Grunde
alles Wissenswerte erwähnt, ein wirklich hervorragendes Posting. Aber
getreu dem µc-Motto: "Es wurde bereits alles gesagt, nur noch nicht von
jedem" ;-) , hier nochmal meine Antwort:
- Man hat zwar üblicherweise mehrere Megabyte an Flash-Speicher für
seine Programme übrig; aber der grosse Flaschenhals ist eindeutig nicht
die Menge des für den Programm-Code zur Verfügung stehenden
Flash-Speichers, sondern halt der auf ca. 40-45kb begrenzte zur
Verfügung stehende RAM
- NodeMCU/LUA hat definitiv einen deutlich höheren RAM-Bedarf als die
Alternative C/ArduinoIDE; das ist meiner Meinung nach auch DER grosse
Nachteil schlechthin von LUA/NodeMCU gegenüber C/ArduinoIDE.
Letztlich ist das ein unausweichliche Begleiterscheinung des Umstandes,
dass LUA interpretiert oder als zumindest als Byte-Code ausgeführt wird.
Wenn man also ein wirklich RAM-hungriges Programm schreiben möchte, ist
Arduino/C vermutlich die bessere Wahl, weil bei LUA eher die Gefahr
besteht, dass man den zur Verfügung stehenden RAM aufbraucht.
- Der Umstand, dass LUA interpretiert wird, hat andererseits aber auch
Vorteile (die ausschliessliche Arduino-IDE-Nutzer vermutlich klein reden
werden, weil sie selbst sie ja gar nicht nutzen (können), und daher
vermutlich für unbedeutend halten). So hat man bspw. eine "Shell" zur
Verfügung, über die man im laufenden Betrieb auf den ESP zugreifen kann,
wenn man das will. Oder man kann Softwaremodule und ihre Abhängigkeiten
sehr leicht nachinstallieren, und zwar mitten im laufenden Betrieb, ohne
dass man gleich eine komplett neue Firmware kompilieren und aufspielen
muss. Man könnte also z.B. etwas ganz ähnliches implementieren wie npm,
den Paket-Manager (und vermutlich eines der Erfolgsgeheimnisse) von
Node.js, falls Du den kennst. Und nicht vergessen: Wenn die Verwendung
von LUA zum Problem wird, hat man bei NodeMCU letztlich immer auch noch
die Möglichkeit, ein Modul statt in LUA in nativem C zu schreiben und so
die potentiellen Nachteile der Verwendung von LUA zu vermeiden.
- Ich persönlich bin bislang noch nie an die RAM-Grenzen gestossen, ich
hatte immer noch so ca. 20kb übrig. Da RAM für meine Belange noch nie
zum kritischen Problem wurde, ich andererseits aber die oben genannten
Vorteile wirklich zu schätzen gelernt habe, bin ich bislang immer bei
LUA/NodeMCU geblieben, und werde C/ArduinoIDE wohl erst und nur dann
einsetzen, wenn RAM-Bedarf mal für mich zum echten Problem wird.
- Es gibt diverse Möglichkeiten, den RAM-Bedarf zu reduzieren, und die
man idealerweise kennen und nutzen sollte:
* Keine grossen, monolithischen LUA-Scripte schreiben, sondern den Code
lieber in eine Vielzahl kleiner Module aufteilen, und diese dann per
require("<Module-Name>") einbinden/nutzen. Es mag ziemlich extrem
erscheinen, aber ich z.B. habe mir angewöhnt, quasi jede einzelne
Funktion in ein eigenes, wiederverwendbares Modul zu packen.
* Wirklich sehr sinnvoll um RAM zu sparen, aber in der Doku kaum darauf
hingewiesen: Die .lua-Dateien zusätzlich in vorkompilierten Bytecode,
also .lc-Dateien, kompilieren lassen. Wenn man im LUA-Code z.B. mit der
Anweisung require("connect_to_wlan") das Modul "connect_to_wlan" laden
möchte, dann schaut LUA immer zuerst, ob es eine (vorkompilierte
Bytecode-) Datei connect_to_wlan.lc gibt, bevor es stattdessen die
Source-Code-Datei connect_to_wlan.lua lädt.
* Vorerst nicht mehr benötigte Module aus dem RAM schmeissen, indem man
die Referenz darauf in package.loaded löscht. Statt mich da um jedes
einzelne Modul zu kümmern, benutze ich persönlich allerdings
üblicherweise eine Funktion (bzw. ein Modul namens
"empty_package_loaded.lua"), die package.loaded einfach komplett leert,
und die ich dann zu passendem Zeitpunkt aufrufe:1 | return function() |
2 | for key, value in pairs(package.loaded) do |
3 | if key ~= '_G' and key ~= 'package' then |
4 | package.loaded[key] = nil |
5 | end |
6 | end |
7 | end |
Als Faustregel mache ich es so, dass ich meinen Code ähnlich wie bei der Arduino IDE zumindest gedanklich in eine setup() und eine loop()-Phase aufteile, und zumindest einmalig nach der setup()-Phase dann per
1 | require('empty_package_loaded')()
|
die package.loaded leere. * Fast immer local Variablen benutzen, globale nur wo es wirklich nötig/sinnvoll ist
Hi, also ich habe mit LUA angefangen und bin dann auf die Arduino IDE umgestiegen. Wenn man etwas kompliziertere Webseiten damit aufbaut, ist NodeMCU einfach zu langsam. Vergleichbare Programme mit der Arduino IDE erstellt, laufen wesentlich schneller. Ich bin mit NodeMCU auch schon des öfteren an die Speichergrenze gekommen (Heapüberlauf), wobei ich die Module allerdings, wie oben angegeben, nicht entladen habe. Ich habe mir auch schon die Espressif SDK angeschaut, aber ich muß gestehen, das ist mir zuviel Arbeit. Bei Arduino gibt es so schön viele gebrauchsfertige Bibliotheken :-) Bin sonst kein Freund von Arduino (die IDE ist grauenhaft) aber für die ESP prima. Ich hoffe jetzt nur noch, daß für die ESP32 mal einen vergleichbare Unterstüzung kommt. Du scheinst ja wohl langsam auf den Geschmack zu kommen, die ESPs mal direkt zu programmieren. Es lohnt sich. ;-) Gruß Andreas
Stefan U. schrieb: > Eigentlich bin ich kein Freund von Arduino, Mit den Arduinos selbst hat das doch nicht sonderlich viel zu tun. Mir verblieb der Eindruck, dass man sich davon nur die Entwicklungsoberfläche ausgeliehen hat. Ich hatte allerdings den Eindruck gewonnen, dass es nicht annähernd so viel Steuermodule gibt wie bei NodeMCU. Was die Speicherkapazität angeht: Die alte 0.9x NodeMCU hatte als Binary alles mit an Bord, was die Software hergab. In neueren Versionen kann man sich jedoch in der Cloud (oder selber) ein angepasstes Binary stricken lassen, in dem nur das drin ist, was man benötigt. Dementsprechend bleibt mehr Platz. NodeMCU/Lua ist gut, wenn es um einfache Dinge geht. Sensoren, Aktoren, einfacher Bedienkomponenten wie Taster/Display. Hab es grad erst für PWM-Ansteuerung von ein paar Netzteilen von grossen LED-Panels verwendet. Direkte Entwicklung ohne viel Overhead, keine grosse IDE nötig. Für grössere Weboberflächen oder als Zentrale für Hausautomation ist das schlicht nicht gebaut.
Stefan U. schrieb: > Momentan bin ich noch in der > Phase, eine Programmierumgebung auszuwählen. Für nodemcu tut es ein Texteditor Deiner Wahl.
Joachim S. schrieb: > * Keine grossen, monolithischen LUA-Scripte schreiben, Am Stück laufender Lua-Code darf ohnehin nicht länger als 10ms laufen dauern, Delays, Debugging-Code und verschachtelte Funktionen eingerechnet. Sonst gibts schlecht reproduzierbare Nebeneffekte. Man muss also den Ablauf über Events strukturieren, nicht über Sequenz, und nicht zu viel davon am Stück in einem geschlossenen Event.
Pete K. schrieb: > Für nodemcu tut es ein Texteditor Deiner Wahl. Wenn man sowieso Java an Bord hat, dann ist der recht frugale ESplorer nicht wirklich ein Monster. Und wenn man sich da im eigenen Quellcode verheddert, dann hat mal für die Verhältnisse des ESP eigentlich schon zuviel davon. ;-)
A. K. schrieb: > Pete K. schrieb: >> Für nodemcu tut es ein Texteditor Deiner Wahl. > > Wenn man sowieso Java an Bord hat, dann ist der recht frugale ESplorer > nicht wirklich ein Monster. Und wenn man sich da im Quellcode > verheddert, dann hat mal für die Verhältnisse des ESP eigentlich schon > zuviel davon. ;-) Du glaubst gar nicht, was man in einem ESP so alles hineinbekommt. Aber eben nicht mit NodeMCU. Für kleine Projekte ist NodemCU dagegen prima, da stimme ich Dir zu. Sich mit NodeMCU verheddern, ist aber schon ein Kunststück. Da sich alles schön auf Module verteilen läßt, finde ich das eigentlich sehr übersichtlich. Mit dem ESPlorer läßt sich schön arbeiten. Gruß Andreas
Andreas B. schrieb: > Sich mit NodeMCU verheddern, ist aber schon ein Kunststück. Wenn du mit zig dynamisch geladenden und weggeworfenen Modulen arbeitest, die sich auf aberzig Quellcodes verteilen, dann dürfte die Übersichtlichkeit der Oberfäche des ESPlorer etwas leiden. So wars gemeint.
A. K. schrieb: > Joachim S. schrieb: >> * Keine grossen, monolithischen LUA-Scripte schreiben, > > Am Stück laufender Lua-Code darf ohnehin nicht länger als 10ms laufen > dauern, Delays, Debugging-Code und verschachtelte Funktionen > eingerechnet. Sonst gibts schlecht reproduzierbare Nebeneffekte. Man > muss also den Ablauf über Events strukturieren, nicht über Sequenz, und > nicht zu viel davon am Stück in einem geschlossenen Event. ...das meinten Joachim und ich nicht in unseren Postings! Wir meinten vielmehr nicht alle Scriptzeilen des Programmes in einem einzigen Lua-Script, sondern schön aufgeteilt in Modul(-Dateien), welche dynamisch, wenn diese Funktionen genötigt werden, vom "Rahmen-Script" nachgeladen werden... A. K. schrieb: > Am Stück laufender Lua-Code darf ohnehin nicht länger als 10ms laufen > dauern, Delays, Debugging-Code und verschachtelte Funktionen > eingerechnet. Sonst gibts schlecht reproduzierbare Nebeneffekte. Beispiel? Bei den "Nebeneffekten" vermute ich mehr Probleme mit den ereignisgesteuerten, asynchronen Programmteilen und da auch im Zusammenhang mit dem Geltungsbereich von Variablen, Funktionen. Uwe
> Ich hatte allerdings den Eindruck gewonnen, dass es > nicht annähernd so viel Steuermodule gibt wie bei NodeMCU. Das ist mir völlig egal. Die Module/Libraries schreibe ich mir notfalls selbst, darin bin ich geübt. Ein grafik Display ist dann vielleicht doch aufwändig zu programmieren, aber ich habe gar nicht vor, dise Displays zu verwenden. Ich bin da eher auf dem Webserver+Tablet Trip. Deswegen ist es mir auch wichtig, dass ich anständige Webserver verwenden oder schreiben kann.
Uwe B. schrieb: > Beispiel? Bei den "Nebeneffekten" vermute ich mehr Probleme mit den > ereignisgesteuerten, asynchronen Programmteilen und da auch im > Zusammenhang mit dem Geltungsbereich von Variablen, Funktionen. Probleme mit der WLAN-Kommunikation beispielsweise. Du bist mit deinem Lua nicht allein auf dem Prozessor. Da läuft ein kooperatives RTOS und wenn das verhungert, dann verhungern WLAN-Tasks. Den Extremfall hatte ich gleich im ersten Anlauf ausprobiert. Verbindung mit dem WLAN. Schleife: tmr.delay(1s), Status abfragen, warten, ... Ergebnis: meistens keine Verbindung. Statt dessen über tmr.alarm(1s) gemacht kam die Verbindung zuverlässig und schnell.
Dass man Eventgetrieebn Programmieren muss empfinde ich als lästig. Es macht den programmcode schwer lesbar und man muss ständig um die Ecke denken. Allerdings kenne ich das schon von µIP ebenso. Der Apfel fällt bekanntlich nicht weit vom Stamm. Android programmiert man auch Eventgetrieben, damit muss man sich wohl einfach abfinden. Wir sind halt nicht mehr in den 80er Jahren mit MS-DOS.
A. K. schrieb: > Den Extremfall hatte ich gleich im ersten Anlauf ausprobiert. Verbindung > mit dem WLAN. Schleife: tmr.delay(1s), Status abfragen, warten, ... > Ergebnis: meistens keine Verbindung. Statt dessen über tmr.alarm(1s) > gemacht kam die Verbindung zuverlässig und schnell. den Unterschied zwischen tmr.delay() und tmr.alarm() kennst du? Stefan U. schrieb: > Dass man Eventgetrieebn Programmieren muss empfinde ich als lästig. Es > macht den programmcode schwer lesbar und man muss ständig um die Ecke > denken. das Gehirn soll ja auch nicht einrosten ;-)... Uwe
Uwe B. schrieb: > den Unterschied zwischen tmr.delay() und tmr.alarm() kennst du? Genau um den geht es doch. tmr.delay ist unkooperativer ablaufgesteuerter Code, tmr.alarm hingegen eventorientiert.
A. K. schrieb: > Genau um den geht es doch. tmr.delay ist unkooperativer sequenzieller > Code, tmr.alarm hingegen eventorientiert. aha, richtig erkannt, aber die Konsequenz wahrscheinlich nicht verstanden...! Die CPU steht, wartet was auch immer. Damit kommt auch das "Ereignis WLAN-Connect" nicht durch, welches ja irgendwann asynchron kommt! Wie schon mehrmals erwähnt, Lua auf dem ESP-Chip arbeitet ereignisorientiert und asynchron. Deshalb auch die Callback-Routinen bei vielen Lua-Funktionen... Eine, bei mir bewährte init.lua (die die WLAN-Verbindung herstellen soll und dann das eigentliche Script startet), sieht so aus: https://github.com/boerge42/nodemcu_scripts/blob/master/mqtt2oled/init.lua tmr.alarm() und der immer wieder und solange, bis wifi.sta.status == 5. Alle anderen zusätzlichen Abfragen sind nur Spielereien, denn eine erhaltene IP-Adresse sagt noch nichts darüber aus, dass auch wirklich eine Verbindung zum AP besteht..., dass ist zumindestens meine Erfahrung. Uwe
Beitrag #4967069 wurde von einem Moderator gelöscht.
Apropo Arduino IDEs - habe mal ein paar ausprobiert (mit dem ESP): - Eclipse mit Arduino-Plugin Habe auf Anhieb nicht gefunden, wie man ein bestehendes Projekt öffnet, bzw. importiert. Nur neu Erstellen. Habe nicht weiter probiert. - Sloeber (wieder Eclipse aber mit einem anderen Plugin) Hat schon mal nicht schlecht funktioniert. Ein paar mal hängengeblieben beim Flashen, ansonsten OK - MS Visual Studio 2017 Community Edition (kostenlos) mit Arduino AddOn Hat erstaunlich gut funktioniert. Der Nachteil ist die typische Visual Studio Installationsorgie. Musste sogar andere Programme beenden und den Virenscanner abstellen, es ließ sich sonst nicht installieren MfG, Andreas
Uwe B. schrieb: > aha, richtig erkannt, aber die Konsequenz wahrscheinlich nicht > verstanden...! Die CPU steht, wartet was auch immer. Damit kommt auch > das "Ereignis WLAN-Connect" nicht durch, Herzlichen Dank dafür, mir zu erklären, was ich längst wusste, und oben selbst etwas knapp und mit anderen Worten als du ausgedrückt hatte. ;-)
Stefan U. schrieb: > Ich bin da eher auf dem Webserver+Tablet Trip. Deswegen > ist es mir auch wichtig, dass ich anständige Webserver verwenden oder > schreiben kann. Wenn Du den ESP als HTTP-*Server* verwenden willst, dann würde ich an Deiner Stelle vermutlich wirklich eher zu C/ArduinoIDE als LUA/NodeMCU greifen. Grundsätzlich würde das zwar natürlich auch mit LUA gehen, aber zumindest instinktiv würde ich vermuten, dass das so eine Aufgabe ist, die doch schnell vglw. viel RAM verbrauchen kann. Auch wenn ich persönlich ja finde, dass es häufig gar keine so gute Idee ist, auf einem ESP8266 einen HTTP-Server laufen zu lassen, und es i.d.R. sinnvoller wäre, stattdessen MQTT zu benutzen. Stefan U. schrieb: > Dass man Eventgetrieebn Programmieren muss empfinde ich als lästig. Es > macht den programmcode schwer lesbar und man muss ständig um die Ecke > denken. > [...] > Android programmiert man auch Eventgetrieben, damit muss man sich wohl > einfach abfinden. Wir sind halt nicht mehr in den 80er Jahren mit > MS-DOS. LUA ist in der Beziehung sehr nah an JavaScript. Javascript hat zwar eine deutlich andere Syntax, trotzdem empfinde ich LUA als äusserst Javascript-ähnlich. Und zumindest bei Javascript hat sich mit den vor einiger Zeit eingeführten "Promises" die eventgetriebene Programmierung deutlich verbessert - im Gegensatz zu den oftmals tief verschachtelten und tatsächlich schwer leserlichen alten callbacks, sind Promises ein absoluter Segen, damit macht eventgetriebene Programmierung richtig Spass. Für LUA gibt es glaube ich auch schon erste Implementierungen, für NodeMCU dürfte aber vermutlich trotzdem wenig bringen.
A. K. schrieb: > Den Extremfall hatte ich gleich im ersten Anlauf ausprobiert. Verbindung > mit dem WLAN. Schleife: tmr.delay(1s), Status abfragen, warten, ... > Ergebnis: meistens keine Verbindung. Statt dessen über tmr.alarm(1s) > gemacht kam die Verbindung zuverlässig und schnell. Moin, A. K. schrieb: > Uwe B. schrieb: >> aha, richtig erkannt, aber die Konsequenz wahrscheinlich nicht >> verstanden...! Die CPU steht, wartet was auch immer. Damit kommt auch >> das "Ereignis WLAN-Connect" nicht durch, > > Herzlichen Dank dafür, mir zu erklären, was ich längst wusste, und oben > selbst etwas knapp und mit anderen Worten als du ausgedrückt hatte. ;-) ...ich hatte nach einem Beispiel für deine Bemerkung: > Am Stück laufender Lua-Code darf ohnehin nicht länger als 10ms laufen > dauern, Delays, Debugging-Code und verschachtelte Funktionen > eingerechnet. Sonst gibts schlecht reproduzierbare Nebeneffekte. gefragt, du hattest ganz obiges als darauf folgende Antwort geliefert..., du erinnerst dich? In deinen beiden Sätzen hast du nicht erwähnt, dass du das "Mysterium" gelöst hast oder habe ich etwas überlesen? ...aber egal, bevor man etwas programmiert, sollte man sich halt die entsprechenden Manuals durchlesen und auch versuchen diese zu verstehen, sonst bezahlt man halt diverse Lehrstunden an vergeudeter Zeit! Ich gebe zu, an dem einen oder anderen Punkt passiert es mir auch, stundenlang rumzudoktern, statt vorher einfach mal zu überlegen. Andererseits sind es Lehrstunden, die man dann nicht mehr vergisst. ...wie auch immer, ich will hier NodeMCU-Lua nicht als DAS NonPlusUltra der ESP8266-Programmierung anpreisen! Wie in jedem Anwendungsfall, ist es eine Abwägungsfrage zwischen "Was will man erreichen?" und "Was steht einem (mit welchen Aufwand) zur Verfügung?". Es ist immer schlecht, wenn man bei zweiter Frage nur "ich kann nur xyz42!" antworten kann! Das wäre ungefähr so, wie wenn man sagt, dass man nur die Bedienung eines Hammers beherrscht, aber eigentlich eine Schraube fest ziehen muss... Grüße Uwe
Uwe B. schrieb: > In deinen beiden Sätzen hast du nicht erwähnt, dass du das "Mysterium" > gelöst hast oder habe ich etwas überlesen? Weil ich in den kargen 4 Zeilen nicht eigens von einem gelösten Mysterium schrieb, schliesst du daraus, dass es sich für mich um ein ungelöstes gehandelt haben müsse? Bisschen gewagt. > ...aber egal, Yep. Keep cool. Dieser Streit hat eine sehr bizarre Note. ;-)
A. K. schrieb: > Bisschen gewagt. ...nö, ich besitze keine Glaskugel! A. K. schrieb: > Yep. Keep cool. Dieser Streit hat eine sehr bizarre Note. ;-) ...alles gut, ich sehe (noch) keinen Streit. Uwe
Joachim S. schrieb: > Grundsätzlich würde das zwar natürlich auch mit LUA gehen, aber > zumindest instinktiv würde ich vermuten, dass das so eine Aufgabe ist, > die doch schnell vglw. viel RAM verbrauchen kann. eigentlich nicht, das meisste ist doch konstanter HTML Code. Und den liest man vom Flashfilesystem und pumpt ihn gleich wieder ins Netzwerk. Die Dynamik macht man im Browser mit Javascript. Auch das liest man aus dem Filesystem oder auch von einer anderen URL. Ein Server braucht viel weniger RAM als ein Browser. Joachim S. schrieb: > Auch wenn ich persönlich ja finde, dass es häufig gar keine so gute Idee > ist, auf einem ESP8266 einen HTTP-Server laufen zu lassen, und es i.d.R. > sinnvoller wäre, stattdessen MQTT zu benutzen. Das klingt vernünftig MfG Klaus
Klaus schrieb: > > Joachim S. schrieb: >> Auch wenn ich persönlich ja finde, dass es häufig gar keine so gute Idee >> ist, auf einem ESP8266 einen HTTP-Server laufen zu lassen, und es i.d.R. >> sinnvoller wäre, stattdessen MQTT zu benutzen. > > Das klingt vernünftig > Ich finde es klingt vernüftig, beides zu machen. Mit dem ESP lassen sich sehr schnelle Webserver aufbauen. Datenübertragung mit MQTT ist ja schön und gut (mache ich auch gerne), aber für Konfigurationsseiten und Steuerungen, die direkt übers Web gehen sollen, sind Webseiten dann doch besser geeignet. Und da hakt es bei LUA eben etwas. Gruß Anreas
Richard B. schrieb: >> Der Hersteller des Chips hat denen kurz von knapp >> den Boden unter den Füssen weggezogen. > > Was war los? > Wann war das? https://github.com/nodemcu/nodemcu-firmware/issues/1319
Beitrag #7202932 wurde von einem Moderator gelöscht.
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.