Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Eric Bruecklmeier Newsgroups: de.sci.electronics Subject: Re: Frage zu ESP8266 Board ES-01 Date: Tue, 18 Apr 2017 09:00:54 +0200 Lines: 75 Message-ID: References: <9iq9fch2fj0pfilkfvece8jbh72au6fs0l@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net t4q9+0WAnLvLN49QQh7iAwaSSIWqObQAVXV4TPYGuEclPBOPjM Cancel-Lock: sha1:vad9emqVaSRjdTRPwLhM3At+NOE= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: Xref: csiph.com de.sci.electronics:226383 Am 18.04.2017 um 00:03 schrieb Wolfgang Strobl: > Eric Bruecklmeier : > >> Am 17.04.2017 um 18:37 schrieb Wolfgang Strobl: >>> Am Mon, 17 Apr 2017 11:16:37 +0200 schrieb Eric Bruecklmeier >>> : > >>> Was spricht denn dagegen, den Chip über UART 0 anzusteuern? Der Umstand, >>> daß sich beim Booten das Gebrabbel mit 74880 nicht unterdrücken läßt? >>> Das müsste sich doch notfalls mit genügend vielen 0x0C (Reset) lösen >>> lassen. >> >> ich würde halt gerne die Software "live" in lua auf dem 8266 entwickeln >> und dafür brauche ich Zugang über UART0 > > Nicht wirklich. Hier im Wohnzimmer liegt seit inzwischen mehreren > Monaten als zu 90 % fertiges Projekt eine Variante der schon mal > erwähnten LED-Streifen-Leuchte, diese soll eine Art indirekte > Beleuchtung in einem Schrank werden, auch ein Geschenk, der Pfiff ist > einerseits die Steuerung per WLAN und sind andererseits ebenfalls die > div. Lichteffekte in der Lampe. Die IR-Komponente habe ich diesmal > weggelassen. Die Firmware habe ich einmal aktualisiert, weil ich ein > Modul (nicht Lua-Modul, sondern in in C implementiertes aus der vom > Projekt gelieferten Grundausstattung) nachrüsten wollte, dafür mußte ich > die Platine aus dem aus einem Stück Holz gefrästen Gehäuse rauspulen.. > Ansonsten wird die Lampe nicht mehr angefasst und ist jeweils mehrere > Wochen lang durchgelaufen. Entwickelt und herumprobiert wird i.W. an > den Effekten, die i.W. alle jeweils kleine Lua-Schnipsel sind, die von > einem Loader geladen und deren Funktionen von div. Timern aufgerufen > werden. Viel mehr als "lade eine Datei hoch" und "führe einen String als > Lua-Codeblock aus" ist nicht nötig, um das ganz ohne UART aus der Ferne > via WLAN machen zu können. Klar, mein Konstrukt ist nicht so elaboriert > wie z.B. ESPlorer und ziemlich zusammengestümpert, aber da ich die > Funktionalität ja eh brauchte, um die Lampe aus der Hand geben und > nachher Updates liefern können, warum nicht gleich damit anfangen? > > Kurz gesagt, für den Anfang reicht ein Bootloader, der mit fest > eingestellten WifiDaten im "Hausnetz" einen TCP-Server z.B. auf dem > Telnetport aufmacht und dort zwei Kommandos kann, u für "Upload" und ! > für Execute. Der Rest ist Verpackung. Man kann das notfalls mit Telnet > beschicken (unter Windows Putty), oder gleich aus einer Vorlage einen > kleinen Telnetclient zusammenbasteln, der ein paar clientseitige > Kommandos versteht. > > Ich will nicht behautpen, daß das eine optimale Lösung ist, aber es geht > jedenfalls so. Das das geht ziehe ich nicht in Zweifel, es wäre mir jedoch (für die ersten Schritte) viel zu umständlich. >> >>> Sicher, mit zwei UART wäre der Wechsel zwischen Flashen einerseits und >>> Debuggen und Produktionsbetrieb andererseits einfacher. Jedoch ergibt >>> sich bei der Vielzahl an unterstützten Protokollen und der begrenzten >>> Zahl von anschließbaren Pins eine gewisses Motiv zur Beschränkung. >>> Gerade beim Basteln sind mir Chips oder Platinen lieber, bei denen sich >>> eine gewisse feste Zuordnung (meinetwegen mit jeweils einer >>> Alternativzuordnung) erahnen läßt als solche, bei denen beliebiger >>> Wildwuchs herrscht und man bei jedem Umstecken oder Umprogrammieren erst >>> drei mal prüfen muß, welche willkürliche Zuordnung de Jour gerade gilt. >> >> Jajaja ;-) prinzipiell gefällt mir das Teil ja recht gut. >> >>> Jedenfalls wäre mit NodeMcu und Lua mein Ansatz, die serielle >>> Schnittstelle nur noch einmalig für das Flashen der Firmware und das >>> grobe Debugging zu benutzen und dann alles weitere, incl. Tests und >>> Debugging über WLAN zu erledigen. >> >> hmmm, das machts halt wieder deutlich umständlicher. Der Bedarf scheint >> da zu sein, denn ESP32 hat mehrere UARTS... > > Der hat ja auch mehrere Kerne :-) Zwei, um genau zu sein. Schon klar, es zeigt aber, wo der Bedarf liegt.