Groups > de.sci.electronics > #226211 > unrolled thread

Frage zu ESP8266 Board ES-01

Started by	Eric Bruecklmeier <usenet@nerdcraft.de>
First post	2017-04-13 17:18 +0200
Last post	2017-04-19 23:26 +0200
Articles	20 on this page of 40 — 6 participants

Back to article view | Back to de.sci.electronics

  Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-13 17:18 +0200
    Re: Frage zu ESP8266 Board ES-01 [SOLVED] Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-13 17:31 +0200
      Re: Frage zu ESP8266 Board ES-01 [SOLVED] Hanno Foest <hurga-news2@tigress.com> - 2017-04-13 17:44 +0200
        Re: Frage zu ESP8266 Board ES-01 [SOLVED] Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-13 18:21 +0200
          Re: Frage zu ESP8266 Board ES-01 [SOLVED] Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-13 19:19 +0200
            Re: Frage zu ESP8266 Board ES-01 [SOLVED] Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-13 19:23 +0200
              Re: Frage zu ESP8266 Board ES-01 [SOLVED] Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-13 19:31 +0200
                Re: Frage zu ESP8266 Board ES-01 [SOLVED] Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-13 19:44 +0200
                  Re: Frage zu ESP8266 Board ES-01 [SOLVED] Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-14 10:15 +0200
                    Re: Frage zu ESP8266 Board ES-01 [SOLVED] Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2017-04-14 10:24 +0200
                      Re: Frage zu ESP8266 Board ES-01 [SOLVED] Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-14 10:35 +0200
                    Re: Frage zu ESP8266 Board ES-01 [SOLVED] Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-14 10:31 +0200
                      Re: Frage zu ESP8266 Board ES-01 [SOLVED] Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-14 10:39 +0200
                Re: Frage zu ESP8266 Board ES-01 [SOLVED] Wolfgang Strobl <news4@mystrobl.de> - 2017-04-13 21:32 +0200
                  Re: Frage zu ESP8266 Board ES-01 [SOLVED] Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-14 10:14 +0200
              Re: Frage zu ESP8266 Board ES-01 [SOLVED] Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-13 19:33 +0200
          Re: Frage zu ESP8266 Board ES-01 [SOLVED] Wolfgang Strobl <news4@mystrobl.de> - 2017-04-13 21:38 +0200
            Re: Frage zu ESP8266 Board ES-01 [SOLVED] Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-14 10:18 +0200
    Re: Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-14 11:22 +0200
      Re: Frage zu ESP8266 Board ES-01 Wolfgang Strobl <news4@mystrobl.de> - 2017-04-14 12:25 +0200
        Re: Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-14 12:49 +0200
          Re: Frage zu ESP8266 Board ES-01 Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-14 13:32 +0200
            Re: Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-14 13:56 +0200
              Re: Frage zu ESP8266 Board ES-01 Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-14 14:16 +0200
                Re: Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-14 14:21 +0200
                  Re: Frage zu ESP8266 Board ES-01 Christian Zietz <newsgroup.1001@chz.xyz> - 2017-04-14 14:27 +0200
                    Re: Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-14 14:30 +0200
                Re: Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-05-08 21:09 +0200
    Re: Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-16 09:44 +0200
    Re: Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-16 17:41 +0200
      Re: Frage zu ESP8266 Board ES-01 Wolfgang Strobl <news4@mystrobl.de> - 2017-04-16 21:24 +0200
        Re: Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-17 09:56 +0200
          Re: Frage zu ESP8266 Board ES-01 Wolfgang Strobl <news4@mystrobl.de> - 2017-04-17 11:05 +0200
            Re: Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-17 11:16 +0200
              Re: Frage zu ESP8266 Board ES-01 Wolfgang Strobl <news4@mystrobl.de> - 2017-04-17 18:37 +0200
                Re: Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-17 19:44 +0200
                  Re: Frage zu ESP8266 Board ES-01 Wolfgang Strobl <news4@mystrobl.de> - 2017-04-18 00:03 +0200
                    Re: Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-18 09:00 +0200
                      Re: Frage zu ESP8266 Board ES-01 Waldemar <waldemar@zedat.fu-berlin.de> - 2017-04-19 18:21 +0200
                        Re: Frage zu ESP8266 Board ES-01 Eric Bruecklmeier <usenet@nerdcraft.de> - 2017-04-19 23:26 +0200

Page 2 of 2 — ← Prev page 1 [2]

#226258

From	Eric Bruecklmeier <usenet@nerdcraft.de>
Date	2017-04-14 12:49 +0200
Message-ID	<elbnp1FgfltU3@mid.individual.net>
In reply to	#226255

Am 14.04.2017 um 12:25 schrieb Wolfgang Strobl:
> Am Fri, 14 Apr 2017 11:22:34 +0200 schrieb Eric Bruecklmeier
> <usenet@nerdcraft.de>:
>
>> Update:
>>
>> So, nach Aufspielen der NodeMCU Firmware tut das Board nun auch
>> (zumindest ein bißchen was) - vielleicht hatte der Chinaman gar keine
>> Firmware aufgespielt.
>
> Davon ist auszugehen. Jedenfalls kann man eine Fatal Exception 0 (siehe
> die Doku dazu, die ich verlinkt hatte) unschwer produzieren, indem man
> den Flash komplett löscht und dann bootet.  Wer wie ich mit
> IBM-Mainframes großgeworden ist, kennt die analoge 360/370-Exception
> noch als 0C6 SPECIFICATION EXCEPTION.  Eine Zeile "SYSTEM ABEND S0C6"
> und rund 10 cm Dump aus dem Schnelldrucker. 10 cm dick, nicht breit.
> :-).
>
>> Jetzt muß ich mich erstmal durch die (teils
>> äußerst unerfreuliche) Doku wühlen, aber es sieht schon deutlich besser
>> aus...
>
> Es ist hilfreich, sich die "ESP8266 Non-OS SDK
> API Reference"
> https://espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf
> von vorne bis hinten durchzulesen, selbst dann, wenn man nicht vorhat,
> irgend etwas anderes als eine der div. damit realisierten Anwendungen
> (Frameworks, Sprachen, ..) wie z.B. die NodeMcu-Firmware zu verwenden.
>
> Abgesehen hilft auch die "unofficial FAQ" über einige Hürden. Meine
> Empfehlung derzeit ist, gleich die Vorabversion der nächsten Auflage zu
> lesen:
>
> https://github.com/TerryE/nodemcu-firmware/blob/b094e382ee23e8fa74a6c8d4a129c1ef14905c8b/docs/en/lua-developer-faq.md
>

Ich werde mich so langsam durch den Berg arbeiten. Das Problem scheint 
wie bei vielen OpenXXX Projekten ein großer Haufen von Dokufragmenten 
von höchst unterschiedlicher Qualität :-/

[toc] | [prev] | [next] | [standalone]

#226263

From	Christian Zietz <newsgroup.1001@chz.xyz>
Date	2017-04-14 13:32 +0200
Message-ID	<elbqaoFi3feU1@mid.individual.net>
In reply to	#226258

Eric Bruecklmeier schrieb:

> Ich werde mich so langsam durch den Berg arbeiten. Das Problem scheint 
> wie bei vielen OpenXXX Projekten ein großer Haufen von Dokufragmenten 
> von höchst unterschiedlicher Qualität :-/

Ich fand damals die Inbetriebnahme und Programmierung meines ESP-01 mit
NodeMCU-Firmware angenehm unkompliziert und problemlos. Will heißen: Die
Hardware hat auf Anhieb funktioniert und die einzelnen NodeMCU-Pakete
sind ja an einer Stelle gesammelt dokumentiert.

Aber vielleicht bin ich auch schon abgestumpft, weil ich mich in der
Firma mit einem deutlich komplexeren IC eines bekannten
Halbleiterherstellers herumschlagen darf, dessen Dokumentation
lückenhaft und widersprüchlich ist. Damit verglichen kommen mir
wahrscheinlich alle "OpenXXX-Projekte" logisch und verständlich vor. ;-)

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

[toc] | [prev] | [next] | [standalone]

#226265

From	Eric Bruecklmeier <usenet@nerdcraft.de>
Date	2017-04-14 13:56 +0200
Message-ID	<elbrnvFgfltU4@mid.individual.net>
In reply to	#226263

Am 14.04.2017 um 13:32 schrieb Christian Zietz:
> Eric Bruecklmeier schrieb:
>
>> Ich werde mich so langsam durch den Berg arbeiten. Das Problem scheint
>> wie bei vielen OpenXXX Projekten ein großer Haufen von Dokufragmenten
>> von höchst unterschiedlicher Qualität :-/
>
> Ich fand damals die Inbetriebnahme und Programmierung meines ESP-01 mit
> NodeMCU-Firmware angenehm unkompliziert und problemlos. Will heißen: Die
> Hardware hat auf Anhieb funktioniert

Das war im Prinzip hier auch so.

> und die einzelnen NodeMCU-Pakete
> sind ja an einer Stelle gesammelt dokumentiert.

Naja, es geht schon damit los, daß man auf der unsäglichen github Seite 
die binaries nicht wirklich findet... Aber das kann gut an mir liegen, 
ich hab ein gestörtes Verhältnis zu solchen Seiten...

> Aber vielleicht bin ich auch schon abgestumpft, weil ich mich in der
> Firma mit einem deutlich komplexeren IC eines bekannten
> Halbleiterherstellers herumschlagen darf, dessen Dokumentation
> lückenhaft und widersprüchlich ist.

Ohje, ich hatte im früheren Leben das Vergnügen mich mit ICs von Siemens 
Weird ähh Wired Communications rumzuschlagen... Ich hab dann bei machen 
Typen aus lauter Verzweiflung Zarlink eindesigned, weil die 
Siemensdatenblätter nicht zu verstehen waren...

> Damit verglichen kommen mir
> wahrscheinlich alle "OpenXXX-Projekte" logisch und verständlich vor. ;-)

Bei manchen Projekten ist es schlicht eine Katastrophe, dazu kommt dann 
noch die präpotente Oberlehrerart der Beteiligten - das kann es einem 
echt verleiden...

[toc] | [prev] | [next] | [standalone]

#226268

From	Christian Zietz <newsgroup.1001@chz.xyz>
Date	2017-04-14 14:16 +0200
Message-ID	<elbsspFija3U1@mid.individual.net>
In reply to	#226265

Eric Bruecklmeier schrieb:

>> und die einzelnen NodeMCU-Pakete
>> sind ja an einer Stelle gesammelt dokumentiert.
> 
> Naja, es geht schon damit los, daß man auf der unsäglichen github Seite 
> die binaries nicht wirklich findet... Aber das kann gut an mir liegen, 
> ich hab ein gestörtes Verhältnis zu solchen Seiten...

NodeMCU-Binaries? Lass sie Dir doch an Deine Anforderungen angepasst
bauen: <https://nodemcu-build.com/>. Das ist großes Plus gegenüber
anderen Projekten, bei denen man ggf. Stunden verbringt, um überhaupt
die Build-Umgebung zu installieren.

Dass man in einem *Source-Code*-Repository wie GitHub keine Binaries
findet, ist übrigens wenig verwunderlich; es ist ja dafür da, wenn Du
die Firmware selbst kompilieren willst.

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

[toc] | [prev] | [next] | [standalone]

#226269

From	Eric Bruecklmeier <usenet@nerdcraft.de>
Date	2017-04-14 14:21 +0200
Message-ID	<elbt6dFgfltU6@mid.individual.net>
In reply to	#226268

Am 14.04.2017 um 14:16 schrieb Christian Zietz:
> Eric Bruecklmeier schrieb:
>
>>> und die einzelnen NodeMCU-Pakete
>>> sind ja an einer Stelle gesammelt dokumentiert.
>>
>> Naja, es geht schon damit los, daß man auf der unsäglichen github Seite
>> die binaries nicht wirklich findet... Aber das kann gut an mir liegen,
>> ich hab ein gestörtes Verhältnis zu solchen Seiten...
>
> NodeMCU-Binaries? Lass sie Dir doch an Deine Anforderungen angepasst
> bauen: <https://nodemcu-build.com/>. Das ist großes Plus gegenüber
> anderen Projekten, bei denen man ggf. Stunden verbringt, um überhaupt
> die Build-Umgebung zu installieren.

Darauf warte ich gerade ;-) Aber da ich jetzt dann an den See aufbreche, 
wird das heute eher nix mehr...

Wie sind denn die Antwortzeiten in der Regel?

> Dass man in einem *Source-Code*-Repository wie GitHub keine Binaries
> findet, ist übrigens wenig verwunderlich; es ist ja dafür da, wenn Du
> die Firmware selbst kompilieren willst.

Nur landet man automatisch dort, wenn man den offiziellen Links zu 
aktuellen Versionen folgt... :-(

[toc] | [prev] | [next] | [standalone]

#226270

From	Christian Zietz <newsgroup.1001@chz.xyz>
Date	2017-04-14 14:27 +0200
Message-ID	<elbtgnFinggU1@mid.individual.net>
In reply to	#226269

Eric Bruecklmeier schrieb:

> Am 14.04.2017 um 14:16 schrieb Christian Zietz:
>> NodeMCU-Binaries? Lass sie Dir doch an Deine Anforderungen angepasst
>> bauen: <https://nodemcu-build.com/>. Das ist großes Plus gegenüber
>> anderen Projekten, bei denen man ggf. Stunden verbringt, um überhaupt
>> die Build-Umgebung zu installieren.
> 
> Darauf warte ich gerade ;-) Aber da ich jetzt dann an den See aufbreche, 
> wird das heute eher nix mehr...
> 
> Wie sind denn die Antwortzeiten in der Regel?

Bei mir -- das letzte Mal im März in Anspruch genommen -- max. zwei Minuten.

>> Dass man in einem *Source-Code*-Repository wie GitHub keine Binaries
>> findet, ist übrigens wenig verwunderlich; es ist ja dafür da, wenn Du
>> die Firmware selbst kompilieren willst.
> 
> Nur landet man automatisch dort, wenn man den offiziellen Links zu 
> aktuellen Versionen folgt... :-(

Naja, bei einem Open-Source-Projekt ist die aktuellste Version halt nun
einmal die, die man aus den Sourcen aus dem
Git-/SVN-/was-auch-immer-Repository selbst baut -- insofern ist es schon
richtig, dass die Links zur aktuellen Version zu GitHub führen. Aber
direkt auf der Startseite von NodeMCU auf GitHub steht ja: "Due to the
ever-growing number of modules available within NodeMCU, pre-built
binaries are no longer made available. Use the automated custom firmware
build service to get the specific firmware configuration you need, or
consult the documentation for other options to build your own firmware."

Da muss man nicht lange suchen, um zu erfahren, wie man an Binaries
kommt, wenn man denn nicht selbst compilieren will.

Christian
-- 
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

[toc] | [prev] | [next] | [standalone]

#226271

From	Eric Bruecklmeier <usenet@nerdcraft.de>
Date	2017-04-14 14:30 +0200
Message-ID	<elbtnnFgfltU7@mid.individual.net>
In reply to	#226270

Am 14.04.2017 um 14:27 schrieb Christian Zietz:
> Eric Bruecklmeier schrieb:
>
>> Am 14.04.2017 um 14:16 schrieb Christian Zietz:
>>> NodeMCU-Binaries? Lass sie Dir doch an Deine Anforderungen angepasst
>>> bauen: <https://nodemcu-build.com/>. Das ist großes Plus gegenüber
>>> anderen Projekten, bei denen man ggf. Stunden verbringt, um überhaupt
>>> die Build-Umgebung zu installieren.
>>
>> Darauf warte ich gerade ;-) Aber da ich jetzt dann an den See aufbreche,
>> wird das heute eher nix mehr...
>>
>> Wie sind denn die Antwortzeiten in der Regel?
>
> Bei mir -- das letzte Mal im März in Anspruch genommen -- max. zwei Minuten.

Häää? Hier passiert seit Stunde gar nix! Angeblich soll eine EMail 
kommen, wenn fertig...

Hmmm, ein Verdacht... Ohja - war im Spam.

>>> Dass man in einem *Source-Code*-Repository wie GitHub keine Binaries
>>> findet, ist übrigens wenig verwunderlich; es ist ja dafür da, wenn Du
>>> die Firmware selbst kompilieren willst.
>>
>> Nur landet man automatisch dort, wenn man den offiziellen Links zu
>> aktuellen Versionen folgt... :-(
>
> Naja, bei einem Open-Source-Projekt ist die aktuellste Version halt nun
> einmal die, die man aus den Sourcen aus dem
> Git-/SVN-/was-auch-immer-Repository selbst baut -- insofern ist es schon
> richtig, dass die Links zur aktuellen Version zu GitHub führen. Aber
> direkt auf der Startseite von NodeMCU auf GitHub steht ja: "Due to the
> ever-growing number of modules available within NodeMCU, pre-built
> binaries are no longer made available. Use the automated custom firmware
> build service to get the specific firmware configuration you need, or
> consult the documentation for other options to build your own firmware."

Das ist aber wieder so eine Hürde, die den Schnellmalausprobierbastler 
abhält...

> Da muss man nicht lange suchen, um zu erfahren, wie man an Binaries
> kommt, wenn man denn nicht selbst compilieren will.
>
> Christian
>

[toc] | [prev] | [next] | [standalone]

#227221

From	Eric Bruecklmeier <usenet@nerdcraft.de>
Date	2017-05-08 21:09 +0200
Message-ID	<enbu2uF1rf3U1@mid.individual.net>
In reply to	#226268

Am 14.04.2017 um 14:16 schrieb Christian Zietz:
> Eric Bruecklmeier schrieb:
>
>>> und die einzelnen NodeMCU-Pakete
>>> sind ja an einer Stelle gesammelt dokumentiert.
>>
>> Naja, es geht schon damit los, daß man auf der unsäglichen github Seite
>> die binaries nicht wirklich findet... Aber das kann gut an mir liegen,
>> ich hab ein gestörtes Verhältnis zu solchen Seiten...
>
> NodeMCU-Binaries? Lass sie Dir doch an Deine Anforderungen angepasst
> bauen: <https://nodemcu-build.com/>. Das ist großes Plus gegenüber
> anderen Projekten, bei denen man ggf. Stunden verbringt, um überhaupt
> die Build-Umgebung zu installieren.

So, es ist an der Zeit nochmal Danke für den Support zu sagen. Vieles 
läuft jetzt, die Besonderheiten des Controllers (ereignisorientierte 
Programmierung) habe ich mittlerweile gerafft - Fazit: Macht großen Spaß 
und Lern/Erfolgskurve ist sehr steil! ;-)

[toc] | [prev] | [next] | [standalone]

#226306

From	Eric Bruecklmeier <usenet@nerdcraft.de>
Date	2017-04-16 09:44 +0200
Message-ID	<elglmcFftiaU1@mid.individual.net>
In reply to	#226211

So, jetzt läuft alles.

Danke für die zahlreichen Hinweise!

[toc] | [prev] | [next] | [standalone]

#226326

From	Eric Bruecklmeier <usenet@nerdcraft.de>
Date	2017-04-16 17:41 +0200
Message-ID	<elhhlnFjkp2U1@mid.individual.net>
In reply to	#226211

Gleich noch eine Frage an die Spezies hier:

Bin ich zu blöd, oder gibts in NodeMCU tatsächlich kein SoftUART Modul, 
das die Bitbangerei erledigt? Ein UART ist halt a bissi knapp...

[toc] | [prev] | [next] | [standalone]

#226328

From	Wolfgang Strobl <news4@mystrobl.de>
Date	2017-04-16 21:24 +0200
Message-ID	<pbe7fctqmb9ll7lktvgq8anums3aqshniu@4ax.com>
In reply to	#226326

Am Sun, 16 Apr 2017 17:41:43 +0200 schrieb Eric Bruecklmeier
<usenet@nerdcraft.de>:

>Gleich noch eine Frage an die Spezies hier:
>
>Bin ich zu blöd, oder gibts in NodeMCU tatsächlich kein SoftUART Modul, 
>das die Bitbangerei erledigt? Ein UART ist halt a bissi knapp...

Die Hardware hat zwei UART, genauer gesagt UART 0, das wahlweise auf
zwei verschiedene Pinpaare geschaltet werden kann, sowie ein zweites,
das nur TX hat und wohl für Debuggingzwecke gedacht war.

Die NodeMcu-Firmware (d.h eLua) unterstützt, soweit ich das überblicke,
nur UART 0, genauer gesagt, für serielle Kommunikation nur dieses, i.W.
unter Nutzung der ROM-Funktionen via SDK.  Ein Modul, das für den
Betrieb von WS2812-Streifen dient - und vielleicht ein paar ähnlich
gestrickte, keine Ahnung - zweckentfremdet UART 1 zur Produktion dessen
ziemlich speziellen Protokolls zur Übertragung einer Folge von
32-bit-Werten. Es kann auch UART 0 für den Parallelbetrieb von zwei
Streifen verwenden, dann ist aber natürlich keine serielle Kommunikation
mehr möglich.  

Bitbanging für ein SoftUART wäre theoretisch möglich, aber nur mit
Klimmzügen, die die Sache mehr oder weniger nutzlos machen würde. Man
sollte nicht vergessen, daß das Hardware- und ROM-design ursprünglich
ein Single-Purpose-Design war, gedacht für die AT-Software, nicht als
Hardwareplattform für beliebige Realtimeanwendungen.  Es gibt faktisch
nur einen Thread und harte Priorität und Realtimeanforderungen für den
WLAN-Betrieb. Wenn man so will, läuft die Anwendung nur in den Lücken,
die die Firmware im ROM läßt, wenn sie nicht damit beschäftigt ist,
802.11 b/g/n/d/e/i/k/r und alles weitere zu realisieren, das in
https://espressif.com/sites/default/files/documentation/0b-esp8266_system_description_en.pdf
beschrieben ist. 

TL;DR für Bitbanging ist der ESP8266 denkbar schlecht geeignet.
-- 
Wir danken für die Beachtung aller Sicherheitsbestimmungen

[toc] | [prev] | [next] | [standalone]

#226350

From	Eric Bruecklmeier <usenet@nerdcraft.de>
Date	2017-04-17 09:56 +0200
Message-ID	<eljaqbFt8nU1@mid.individual.net>
In reply to	#226328

Am 16.04.2017 um 21:24 schrieb Wolfgang Strobl:
> Am Sun, 16 Apr 2017 17:41:43 +0200 schrieb Eric Bruecklmeier
> <usenet@nerdcraft.de>:
>
>> Gleich noch eine Frage an die Spezies hier:
>>
>> Bin ich zu blöd, oder gibts in NodeMCU tatsächlich kein SoftUART Modul,
>> das die Bitbangerei erledigt? Ein UART ist halt a bissi knapp...
>
> Die Hardware hat zwei UART, genauer gesagt UART 0, das wahlweise auf
> zwei verschiedene Pinpaare geschaltet werden kann, sowie ein zweites,
> das nur TX hat und wohl für Debuggingzwecke gedacht war.
>
> Die NodeMcu-Firmware (d.h eLua) unterstützt, soweit ich das überblicke,
> nur UART 0, genauer gesagt, für serielle Kommunikation nur dieses, i.W.
> unter Nutzung der ROM-Funktionen via SDK.  Ein Modul, das für den
> Betrieb von WS2812-Streifen dient - und vielleicht ein paar ähnlich
> gestrickte, keine Ahnung - zweckentfremdet UART 1 zur Produktion dessen
> ziemlich speziellen Protokolls zur Übertragung einer Folge von
> 32-bit-Werten. Es kann auch UART 0 für den Parallelbetrieb von zwei
> Streifen verwenden, dann ist aber natürlich keine serielle Kommunikation
> mehr möglich.
>
> Bitbanging für ein SoftUART wäre theoretisch möglich, aber nur mit
> Klimmzügen, die die Sache mehr oder weniger nutzlos machen würde. Man
> sollte nicht vergessen, daß das Hardware- und ROM-design ursprünglich
> ein Single-Purpose-Design war, gedacht für die AT-Software, nicht als
> Hardwareplattform für beliebige Realtimeanwendungen.  Es gibt faktisch
> nur einen Thread und harte Priorität und Realtimeanforderungen für den
> WLAN-Betrieb. Wenn man so will, läuft die Anwendung nur in den Lücken,
> die die Firmware im ROM läßt, wenn sie nicht damit beschäftigt ist,
> 802.11 b/g/n/d/e/i/k/r und alles weitere zu realisieren, das in
> https://espressif.com/sites/default/files/documentation/0b-esp8266_system_description_en.pdf
> beschrieben ist.
>
> TL;DR für Bitbanging ist der ESP8266 denkbar schlecht geeignet.

Das mag alles sein, nur gibt es halt eine Menge NodeMCU Module, die in 
irgendeiner Form bitbangen - da hätte es ja sein können... Mir würden 
9,6 schon reichen, hab aber keine Lust das selber zu stricken ;-)

[toc] | [prev] | [next] | [standalone]

#226353

From	Wolfgang Strobl <news4@mystrobl.de>
Date	2017-04-17 11:05 +0200
Message-ID	<jpv8fcpk622f0o4q2rs3613kcufj5927rp@4ax.com>
In reply to	#226350

Am Mon, 17 Apr 2017 09:56:59 +0200 schrieb Eric Bruecklmeier
<usenet@nerdcraft.de>:

>Am 16.04.2017 um 21:24 schrieb Wolfgang Strobl:
>> Am Sun, 16 Apr 2017 17:41:43 +0200 schrieb Eric Bruecklmeier
>> <usenet@nerdcraft.de>:
>>
>>> Gleich noch eine Frage an die Spezies hier:
>>>
>>> Bin ich zu blöd, oder gibts in NodeMCU tatsächlich kein SoftUART Modul,
>>> das die Bitbangerei erledigt? Ein UART ist halt a bissi knapp...
>> TL;DR für Bitbanging ist der ESP8266 denkbar schlecht geeignet.
...
>
>Das mag alles sein, nur gibt es halt eine Menge NodeMCU Module, die in 
>irgendeiner Form bitbangen - da hätte es ja sein können... Mir würden 
>9,6 schon reichen, hab aber keine Lust das selber zu stricken ;-)

Verständlich. Nun, da würden mich konkrete Beispiele interessieren,
vorzugsweise natürlich aus dem Biotop der NodeMCU-Firmware. 

Ich habe mir schon mal die Zähne an der Inputseite ausgebissen. Es
funktionierte, aber es war nicht zuverlässig hinzubekommen, egal mit
welchem Ansatz (Polling mit dem sog. Hardwaretimer, interruptgetriebene
Auswertung der Pulsetrain on the fly, interruptgetriebenes Mitschreiben
der Pulsetrain in einem vorab angelegten Buffer) ich es probiert habe.
Die Debugging-Möglichkeiten auf der Ebene sind nicht gut, die
Dokumentation durch Espressif auch nicht und irgendwann ist mir die Zeit
weggelaufen, weil das Ergebnis (eine bunte LED-Lampe mit IR- und
WLAN-Steuerung) als Geschenk fertig werden sollte. 

Ich habe schließlich einen einfachen PIC 12F1840 die IR-Dekodierung
übernehmen lassen und das Ergebnis seriell zum ESP8266 (kein NodemCU,
sondern nackter ESP12E) übertragen. Denn dafür hatte ich schon
funktionsfähigen Code, Platz für den Achtbeiner war noch vorhanden und
schließlich läuft das ganze unter Hobby und nicht unter
Produktentwicklung.

Wenn ich fragen darf, was hast Du mit den weiteren gewünschten UARTs
vor? 

-- 
Wir danken für die Beachtung aller Sicherheitsbestimmungen

[toc] | [prev] | [next] | [standalone]

#226355

From	Eric Bruecklmeier <usenet@nerdcraft.de>
Date	2017-04-17 11:16 +0200
Message-ID	<eljfflFt8nU3@mid.individual.net>
In reply to	#226353

Am 17.04.2017 um 11:05 schrieb Wolfgang Strobl:
> Am Mon, 17 Apr 2017 09:56:59 +0200 schrieb Eric Bruecklmeier
> <usenet@nerdcraft.de>:
>
>> Am 16.04.2017 um 21:24 schrieb Wolfgang Strobl:
>>> Am Sun, 16 Apr 2017 17:41:43 +0200 schrieb Eric Bruecklmeier
>>> <usenet@nerdcraft.de>:
>>>
>>>> Gleich noch eine Frage an die Spezies hier:
>>>>
>>>> Bin ich zu blöd, oder gibts in NodeMCU tatsächlich kein SoftUART Modul,
>>>> das die Bitbangerei erledigt? Ein UART ist halt a bissi knapp...
>>> TL;DR für Bitbanging ist der ESP8266 denkbar schlecht geeignet.
> ...
>>
>> Das mag alles sein, nur gibt es halt eine Menge NodeMCU Module, die in
>> irgendeiner Form bitbangen - da hätte es ja sein können... Mir würden
>> 9,6 schon reichen, hab aber keine Lust das selber zu stricken ;-)
>
> Verständlich. Nun, da würden mich konkrete Beispiele interessieren,
> vorzugsweise natürlich aus dem Biotop der NodeMCU-Firmware.

Möglicherweise habe ich mich auch getäuscht und die Module zur Steuerung 
verschiedener Sensoren setzen auf I2C oder SPI auf...

> Ich habe mir schon mal die Zähne an der Inputseite ausgebissen. Es
> funktionierte, aber es war nicht zuverlässig hinzubekommen, egal mit
> welchem Ansatz (Polling mit dem sog. Hardwaretimer, interruptgetriebene
> Auswertung der Pulsetrain on the fly, interruptgetriebenes Mitschreiben
> der Pulsetrain in einem vorab angelegten Buffer) ich es probiert habe.
> Die Debugging-Möglichkeiten auf der Ebene sind nicht gut, die
> Dokumentation durch Espressif auch nicht und irgendwann ist mir die Zeit
> weggelaufen, weil das Ergebnis (eine bunte LED-Lampe mit IR- und
> WLAN-Steuerung) als Geschenk fertig werden sollte.
>
> Ich habe schließlich einen einfachen PIC 12F1840 die IR-Dekodierung
> übernehmen lassen und das Ergebnis seriell zum ESP8266 (kein NodemCU,
> sondern nackter ESP12E) übertragen. Denn dafür hatte ich schon
> funktionsfähigen Code, Platz für den Achtbeiner war noch vorhanden und
> schließlich läuft das ganze unter Hobby und nicht unter
> Produktentwicklung.
>
> Wenn ich fragen darf, was hast Du mit den weiteren gewünschten UARTs
> vor?

Ansteuerung eines MP3-TF-P16

Der mir derzeit allerdings noch keine Rechte Freude macht und das 
Datenblatt verdient den Namen nicht...

[toc] | [prev] | [next] | [standalone]

#226371

From	Wolfgang Strobl <news4@mystrobl.de>
Date	2017-04-17 18:37 +0200
Message-ID	<9iq9fch2fj0pfilkfvece8jbh72au6fs0l@4ax.com>
In reply to	#226355

Am Mon, 17 Apr 2017 11:16:37 +0200 schrieb Eric Bruecklmeier
<usenet@nerdcraft.de>:

>Am 17.04.2017 um 11:05 schrieb Wolfgang Strobl:
>> Wenn ich fragen darf, was hast Du mit den weiteren gewünschten UARTs
>> vor?
>
>Ansteuerung eines MP3-TF-P16

Ah, ich sehe, <https://www.mikrocontroller.net/topic/425236>

>
>Der mir derzeit allerdings noch keine Rechte Freude macht und das 
>Datenblatt verdient den Namen nicht...

Das Problem ist ja offenbar gelöst.

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.
  
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.

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. 

-- 
Wir danken für die Beachtung aller Sicherheitsbestimmungen

[toc] | [prev] | [next] | [standalone]

#226375

From	Eric Bruecklmeier <usenet@nerdcraft.de>
Date	2017-04-17 19:44 +0200
Message-ID	<elkd7mF7o14U2@mid.individual.net>
In reply to	#226371

Am 17.04.2017 um 18:37 schrieb Wolfgang Strobl:
> Am Mon, 17 Apr 2017 11:16:37 +0200 schrieb Eric Bruecklmeier
> <usenet@nerdcraft.de>:
>
>> Am 17.04.2017 um 11:05 schrieb Wolfgang Strobl:
>>> Wenn ich fragen darf, was hast Du mit den weiteren gewünschten UARTs
>>> vor?
>>
>> Ansteuerung eines MP3-TF-P16
>
> Ah, ich sehe, <https://www.mikrocontroller.net/topic/425236>
>
>>
>> Der mir derzeit allerdings noch keine Rechte Freude macht und das
>> Datenblatt verdient den Namen nicht...
>
> Das Problem ist ja offenbar gelöst.
>
> 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

> 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...

[toc] | [prev] | [next] | [standalone]

#226382

From	Wolfgang Strobl <news4@mystrobl.de>
Date	2017-04-18 00:03 +0200
Message-ID	<rjcafc1cq5l9n1uifipinbiqrs9qfb1ve0@4ax.com>
In reply to	#226375

Eric Bruecklmeier <usenet@nerdcraft.de>:

>Am 17.04.2017 um 18:37 schrieb Wolfgang Strobl:
>> Am Mon, 17 Apr 2017 11:16:37 +0200 schrieb Eric Bruecklmeier
>> <usenet@nerdcraft.de>:

>> 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.

>
>> 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.  Das löst dann
auch noch ein anderes, viel schwerwiegenderes Problem, nämlich eben das
schon geschilderte, dass das SoC eben nicht wirklich ein general purpose
system ist, sondern ein extrem konfigurierbares WiFi-Device, das aber
nur eventgetrieben werden kann und das mit ziemlich engen Zeit und
Mengenvorgaben.  Hole einen Request ab, parse den und konstruiere dann
ebenfalls sequentiell die Response, das ist damit nicht zu machen. Mit
zwei Kernen, von denen einer nach Belieben konventionell sequentiell
programmiert werden kann, wird die Geschichte wieder ganz einfach.

-- 
Wir danken für die Beachtung aller Sicherheitsbestimmungen

[toc] | [prev] | [next] | [standalone]

#226383

From	Eric Bruecklmeier <usenet@nerdcraft.de>
Date	2017-04-18 09:00 +0200
Message-ID	<ellrt6Fg2orU1@mid.individual.net>
In reply to	#226382

Am 18.04.2017 um 00:03 schrieb Wolfgang Strobl:
> Eric Bruecklmeier <usenet@nerdcraft.de>:
>
>> Am 17.04.2017 um 18:37 schrieb Wolfgang Strobl:
>>> Am Mon, 17 Apr 2017 11:16:37 +0200 schrieb Eric Bruecklmeier
>>> <usenet@nerdcraft.de>:
>
>>> 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.

[toc] | [prev] | [next] | [standalone]

#226422

From	Waldemar <waldemar@zedat.fu-berlin.de>
Date	2017-04-19 18:21 +0200
Message-ID	<elph4kF7psaU1@mid.uni-berlin.de>
In reply to	#226383

Hallo Eric,

hole dir das Buch "Kolban's Book on ESP8266". Es ist alles ziemlich gut 
beschrieben.

http://neilkolban.com/tech/esp8266/

Waldemar

[toc] | [prev] | [next] | [standalone]

#226449

From	Eric Bruecklmeier <usenet@nerdcraft.de>
Date	2017-04-19 23:26 +0200
Message-ID	<elq2vdFbbokU1@mid.individual.net>
In reply to	#226422

Am 19.04.2017 um 18:21 schrieb Waldemar:
> Hallo Eric,
>
> hole dir das Buch "Kolban's Book on ESP8266". Es ist alles ziemlich gut
> beschrieben.
>
> http://neilkolban.com/tech/esp8266/

Hab ich, auch zum ESP32...

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

csiph-web

Frage zu ESP8266 Board ES-01

Contents

#226258

#226263

#226265

#226268

#226269

#226270

#226271

#227221

#226306

#226326

#226328

#226350

#226353

#226355

#226371

#226375

#226382

#226383

#226422

#226449