Hallo Community,
ich bin absoluter Anfänger mit Microcontrollern und beschäftige mich
derzeit mit dem ESP8266 und dessen Programmierung mit MicroPython.
Ich habe einen Wemos D1 Mini auf einem Breadboard verbunden mit einer
RGB-LED, also von G (Masse) zur Kathode der RGB-LED und von D1, D2, D3
über einen jeweils passenden Widerstand zu den Anschlüssen für r,g,b.
Wenn ich nun den Wemos D1 Mini über den MicroUSB-Port mit Strom
versorge, leuchtet die RGB-LED rot. Und zwar ohne, dass ich das im
Programm entsprechend als Anweisung gegeben habe.
Definiere ich über
die GPIOs, erlischt die LED und lassen sich anschließen über rot.on()
und rot.off() usw. an- und ausschalten.
Sobald ich aber über ein
1
machine.deepsleep()
den ESP in den Deepsleep versetze, leuchtet die LED wieder rot.
Wieso fließt da (also beim Einstecken der Spannungsversorgung ohne
Ausführung von Programmcode und im Deepsleep) überhaupt ein Strom ohne
dass der ESP eine entsprechende Anweisung bekommen hat?
Martin K. schrieb:> rot = machine.Pin(0, machine.Pin.OUT, value=0) #D3
rot = machine.Pin(0, machine.Pin.OUT, value=0) #D3
das liegt wohl daran ... an pin0/d3 hängt auch die onboard led?!
wie genau hast du deine led an den port angeschaltet?
snafu schrieb:> das liegt wohl daran ... an pin0/d3 hängt auch die onboard led?!
Nein, laut https://www.wemos.cc/en/latest/d1/d1_mini.html und eigenem
Test ist die onboard LED an D4/GPIO2.
Die Kathode der RGB-LED ist mit G (also Masse) des WEMOS D1 mini
verbunden.
Und die Anschlüsse von r,g,b sind mit zwischengeschalteten Widerständen
mit D1,D2,D3 verbunden.
Das von Dir festgestellte Phänomen dürfe gar nicht am ESP8266 an sich
liegen, sondern daran, dass da zwei Umstände zusammen kommen:
1. Dass Du zur Steuerung der roten LED den "problematischen" (weil nur
eingeschränkt nutzbaren) GPIO-Pin GPIO0 verwendest:
>
2. dass Du keinen nackten ESP8266 benutzt, sondern ein komplettes Board
mit integriertem USB-UART-Wandler. Bei denen ist der von Dir verwendete
GPIO 0 nämlich in aller Regel mit dem USB-UART-Wandler verbunden.
Falls Du auf Deinem PC ein Terminalprogramm hast, mit dem Du die beiden
Steuerleitungen "RTS" und "DTR" gezielt steuern kannst, dann probiere
das mal aus - Du wirst vermutlich feststellen, dass Du auf diese Weise
vom PC aus die rote LED ein- und ausschalten kannst, zumindest bis Du
über die obige Anweisung den GPIO-Port als Output eingestellt hast.
Einfachste Lösung: Statt GPIO0 einen anderen GPIO-Pin verwenden.
Ich habe jetzt testweise rot über den auch zuvor schon
zwischengeschalteten Widerstand an GPIO 12, 13, 14 angeschlossen. Immer
das gleiche Ergebnis: ohne explizite Anweisung leuchtet die LED rot.
Allerdings ist mir aufgefallen, dass bei GPIO 15 und 3V3 die LED
bedeutend heller leuchtet, auch heller als vorher an GPIO 0.
Eigentlich sind die einzigen GPIOs, die sich so verhalten wie ich es
erwartet habe, GPIO 4 und 5. Bei diesen fließt erst dann Strom, wenn ich
die entsprechende Anweisung gebe.
Manchmal hilft der Blick in den Schaltplan um zu sehen, was an einem
GPIO wirklich dran hängt.
Dann auch ein Blick in die Prozessorkonfiguration, ob an dem Pin
wirklich GPIO-Mode eingestellt ist, oder auch ein Uart, SPI-Mode etc
aktiviert sein kann. Dann leuchtet es anders, als man denkt.
Man sollte nichts erwarten (darauf bin ich auch schon reingefallen),
sondern erst einmal die Doku lesen und verstehen.
Martin K. schrieb:> Wieso fließt da (also beim Einstecken der Spannungsversorgung ohne> Ausführung von Programmcode und im Deepsleep) überhaupt ein Strom ohne> dass der ESP eine entsprechende Anweisung bekommen hat?
Weil I/O Pins nicht zwangsläufig ein laufendes Programm brauchen.
Die Türe deines Büros kann auch wahlweise offen stehen oder geschlossen
sein, auch wenn dort niemand arbeitet.
Ob deine Firmware die I/O Pins vor dem Einschlafen deaktiviert, weiß ich
nicht. Dein Schaltplan nützt nichts, weil dort die RGB LED nicht
eingezeichnet ist.
