Hallo, ich bin neu in dem Gebiet ESP 8266 und habe dazu eine kurze Verständnissfrage. Ich würde diesen Chip gerne mit meiner Arduino IDE programmieren. Dazu gibt es 1000 Anleitungen im Netz. Ist es relevant welche Firmware ich auf dem Chip habe? Oder wird die Firmware bei jedem Download aus der Arduino IDE überschrieben. Standardmäßi8g wird der Chip ja mit "LUA - Firmware ausgeliefert. Auf Github kann ich mehrere Firmwares herunterladen, die mit dem ESPFlasher zu laden sind. Danke für eure Antworten...
:
Verschoben durch User
Hallo, das, was auf dem ESP8266 ist, ist seine aktuelle Anwender-Software. Eveb AI-Thinker, LUA usw. Wenn Du mit der Arduino-IDE und der ESP8266-Erweitrerung arbeitest. programmierst Du Deine eigene Anwender-Software für den ESP. Genau die läuft nach dem Flashen auf dem ESP und macht genau das, was Du da programmiert hast. Der ESP8266 selbst hat nur einen Rom-Bootloader, die entweder den Flash-Download startet (GPIO0 auf Low) oder eben die Anwender-Software. Wenn keine sinnvolle drauf ist, macht er eben nichts sinnvolles. Gruß aus Berlin Michael
Ok, danke. Hab ich soweit kapiert. Solange ich also nicht z.B. mit LUA oder den AT-Befehlen arbeiten will, ist es völlig egal was vorher auf dem Gerät drauf war. Sobald ich meine Anwendersoftware von der Arduino IDE drauf spiel, wird das was drauf war sowieso überschrieben. Was sind dann aber die Firmware, die ich hier (https://github.com/nodemcu/nodemcu-firmware/releases) herunterladen kann? Ist dies die Software für LUA um das Gerät dann z.b. mit ESPlorer zu programmieren?
Bei der nodemcu-firmware, bei der man in LUA programmiert, ist das tatsächlich etwas anders gelöst, als wenn man die Arduino-IDE benutzt. Während bei der Arduino-IDE bei jedem Programmieren quasi die komplette Software/"Firmware" ausgetauscht/überspielt wird, spielt man sich bei der nodemcu-firmware ein fertiges Firmware-Image auf, das dann auch erst einmal nicht mehr ausgetauscht werden muss; denn diese Firmware erzeugt dann in einem reservierten Bereich des Flash-Speichers ein kleines Dateisystem, in dem die eigentliche Anwender-Software als LUA-Dateien/Module abgelegt werden; entweder als .lua-Dateien (=unveränderter LUA-Source Code) oder als .lc-Dateien (=bereits in LUA-Bytecode vorkompilierter Code). Die meisten Leute hier scheinen für den ESP8266 die Arduino-IDE zu nutzen; ich persönlich bevorzuge gerade aus obigem Grund allerdings die nodemcu-firmware; denn bei diesem Ansatz ist es bspw. leicht möglich, ähnlich wie bei node.js/npm nützliche Module sowie deren Abhängigkeiten im laufenden Betrieb direkt über das Internet zu installieren/aktualisieren etc. Ausserdem kann man sich z.B. mit einer handvoll Zeilen Code eine komplette kleine LUA-REPL-Shell basteln, über die man online quasi komplette Kontrolle über den ESP hat.
Hallo, das wird sicher immer eine persöhnliche Entscheidung sein. Es gibt auch ESP8266Basic und MicroPhyton für die ESP-Module. Wird davon abhängen, in welcher Sprache man sich schon halbwegs auskennt und was man erreichen will. Ich bevoruger auch die Arduino-IDE und damit C/C++. Für mich passt das so und ich müßte vermutlich erst ziemlich schauen, ob und wie ich z.B. den RFM12 für meine 433MHz-Sensor-MQTT-Bridge in LUA o.ä. in Gang bekäme. So konnte ich selbst die Jahre alte RFM12-Empfangsroutine im Interrupt nahezu unverändert vom AVR auf den ESP tragen. Das wird auch der TO für sich herausfinden müssen... Gruß aus Berlin Michael
Michael U. schrieb: > das wird sicher immer eine persöhnliche Entscheidung sein. > Es gibt auch ESP8266Basic und MicroPhyton für die ESP-Module. > > Wird davon abhängen, in welcher Sprache man sich schon halbwegs auskennt > und was man erreichen will. Stimmt schon, ich kann das auch gut nachvollziehen - wenn man von AVR & Co. eh seit jeher gewohnt ist, Mikrocontroller in C/C++ zu programmieren, darin auch entsprechend erfahren ist, und dafür dann auch oftmals bereits funktionierende Code-Samples hat, die man fast ohne Änderung übernehmen kann - warum sich dann ohne Not in eine neue Sprache einarbeiten? Zumal es natürlich auch nicht von der Hand zu weisende Vorteile hat, die Programme hardwarenah in C/C++ zu schreiben und direkt als fertig kompilierter Maschinencode auf das Gerät zu laden (vor Allem: signifikant geringerer RAM-Verbrauch). Bei mir war es halt so, dass ich durch die nodemcu-firmware zum ersten Mal praktische Erfahrung mit dem Konzept gemacht habe, dass auf einem Mikrocontroller als zusätzliche Abstraktionsschicht noch ein Interpreter für eine Skript-Sprache werkelt. Zuvor hatte ich es als einzigen Vorteil einer derartigen Lösung betrachtet, dass man den Mikrocontroller so komfortabel in einer semantisch mächtigeren höheren Programmiersprache programmieren kann, mit der man vielleicht auch bereits mehr Erfahrung hat; seitdem ist mir aber bewusst geworden, dass damit durchaus auch noch andere Vorteile verbunden sind, an die ich zuvor gar nicht gedacht habe. > Ich bevoruger auch die Arduino-IDE und damit C/C++. Für mich passt das > so und ich müßte vermutlich erst ziemlich schauen, ob und wie ich z.B. > den RFM12 für meine 433MHz-Sensor-MQTT-Bridge in LUA o.ä. in Gang > bekäme. > So konnte ich selbst die Jahre alte RFM12-Empfangsroutine im Interrupt > nahezu unverändert vom AVR auf den ESP tragen. Verstehe ich. Wobei das streng genommen ja auch kein grosses Problem wäre, denn Du kannst bei der nodemcu/LUA-Firmware Deine Software-Komponenten alternativ ja auch in C schreiben, z.B. wo irgendwas zeitkritisch ist oder man aus sonstigen Gründen hardwarenahen Zugriff braucht. Bspw. sind auch fast alle mitgelieferten Basis-Module der nodemcu-firmware nicht in LUA, sondern halt in C geschrieben. Aber egal, mal jetzt mal was ganz Anderes: Dein 433MHz-Sensor (also: Empfänger?)-Lösung hat mich ziemlich neugierig gemacht. Funktioniert das gut? Ich hatte nämlich mal probiert, einen 433MHz-Empfänger zu nutzen, habe es dann aber doch bald aufgegeben. Das Problem war in meinem Fall, dass ich ursprünglich davon ausgegangen bin, dass sich ein 433MHz-Empfänger ungefähr wie ein IR-Empfänger a la TSOP173x verhält, wo am Daten-Pin nur dann etwas passiert, wenn halt gerade z.B. eine IR-Fernbedienung aktiv ist, und sonst ein bestimmter "Ruhe-Zustand" anliegt. Bei meinem (zugegebenermassen recht billigen, einfach auf gut Glück bestellten) 433MHz-Empfänger war es stattdessen aber vielmehr so, dass über den Daten-Pin eine Art "digitales Rauschen" ausgegeben wurde, wenn gerade kein 433MHz-Sender aktiv war, was mich vor massive Probleme gestellt hat, weil sich alle paar Mikrosekunden der Zustand geändert hat. Ist das bei Deiner Lösung mit dem RFM12 genauso? Wenn ja, wie hast Du das gelöst?
Hallo, Joachim S. schrieb: > Bei meinem (zugegebenermassen recht billigen, einfach auf gut Glück > bestellten) 433MHz-Empfänger war es stattdessen aber vielmehr so, dass > über den Daten-Pin eine Art "digitales Rauschen" ausgegeben wurde, wenn > gerade kein 433MHz-Sender aktiv war, was mich vor massive Probleme > gestellt hat, weil sich alle paar Mikrosekunden der Zustand geändert > hat. die einfachen benutzen OOK als Modulation, schalten also den Träger nur ein und aus. Im Ruhezustand empfangen die also alles, was kommt, bis runter zum Rauschen. Der Aufwand, das zu dekodieren ist für den µC also höher. Die rc-switch-Library ist für diese Protokolle mit einfachen Sendern/Empängern. Als Sender nutze ich die auch am ESP8266 als Bridge um normale Funksteckdosen per WLAN zu schalten. Ob Enpfangen mit dem ESP inzwischen geht, habe ich nicht nachgeschaut, es gab am Anfang Probleme mit dem Interrupt-Timing auf dem ESP. Hier hat offenbar jemand das genutzt: http://www.instructables.com/id/Using-an-ESP8266-to-Control-Mains-Sockets-Using-43/ Gruß aus Berlin Michael
Danke, Michael! Gut, dass ich vor dem Absenden meines Postings nochmal auf "Vorschau" geklickt und Dein Posting entdeckt habe, denn genau das wollte ich gerade nochmal sicherheitshalber nachfragen :-) - also ob wir hier auch wirklich gerade von 433MHz OOK/ASK reden. Denn ich brauche leider wirklich einen Empfänger für OOK/ASK, nicht FSK, hatte das aber dummerweise nicht explizit erwähnt. Okay, also... Wenn ich das richtig verstehe, ist das RFM12 für FSK gedacht und nicht dafür geeignet, OOK/ASK-Signale zu empfangen? Und wenn ich OOK/ASK-Signale empfangen will, läuft im Grunde kein Weg daran vorbei, das Rauschen auf Softwareebene im Mikrocontroller herauszufiltern?
Hallo, Joachim S. schrieb: > Okay, also... Wenn ich das richtig verstehe, ist das RFM12 für FSK > gedacht und nicht dafür geeignet, OOK/ASK-Signale zu empfangen? Und wenn > ich OOK/ASK-Signale empfangen will, läuft im Grunde kein Weg daran > vorbei, das Rauschen auf Softwareebene im Mikrocontroller > herauszufiltern? Der RFM12 macht FSK, richtig. Man kann ihne zwar auch zum OOK-Empfänger degradieren, dann kommt da aber auch aller Müll raus wie beim einfachen Empänger. Ich hatt den RFM12 auch zeitweise um OOK zu senden, geht mit einem Trick recht problemlos. OOK/ASK muß ein µC erledigen, oder eben Decoder-IC, der speziell darauf getrimmt ist. Die finden man dann z.B. in den Steckdosen. Bei Funkthermometern ist es ein µC, weil der da sowieso wegen Display usw. nötig ist. Also entweder einen kleinen AVR mit der RC-Switch-Lib mit Arduino nutzen o.ä. ohne Arduino. Oder schauen, ob Empfangen mit dem ESP und der Lib stabil geht. Zu LUA habe ich nichts gefunden, ob da jemand was gemacht hat. Allerdings kapern wir hier gerade einen Thread, sollten wir lieber lassen... Gruß aus Berlin Michael
:
Bearbeitet durch User
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.