Hi Leute, nach ewigem Probieren und Googlen seit ihr meine letzte Hoffnung. Ich habe einen ESP8266 (WemosD1 mini) im Battiebetrieb laufen und im DeepSleep für jeweils ca. 1h. Er wacht auf, sendet seine Daten und geht wieder schlafen. Am Gerät selbst befindet sich auch ein Resetknopf, welcher den RST Pin beim Drücken gegen Masse schaltet. Drückt man rauf, startet der ESP neu. Soweit so gut. Funktioniert auch alles, aber: Nun suche ich nach einer eleganten Lösung zu unterscheiden, ob der Wakeup durch das Ablaufen des WDT oder durch den Resetknopf ausgelöst wurde. Hintergrund: Die Daten werden stündlich an einen Server übermittelt. Wenn ich auf den RST Button drücke, möchte ich jedoch, dass sich das OLED mit anschaltet und ich alle Infos auf diesem angezeigt bekomme. Das dauert eine Weile und kostet Strom. Daher sollte es eben auch nur beim Drücken des RST Buttons passieren. Das Problem: Befindet der ESP sich gerade im Deep Sleep und man drückt den Knopf bekomme ich immer den Reset Cause 5=Awake from Deep-sleep. 2 Lösungen habe ich schon gefunden, die aber nicht so dolle sind: (1) Man drückt den Reset Knopf 2 mal schnell hintereinander. Beim ersten Start bekommen man Reset Cause 5=Awake from Deep-sleep, beim zweiten Mal, weil der ESP noch nicht im DeepSleep ist, korrekt den Reset Cause 6=Hardware reset. (2) Man tauscht den Resetknopf (NO) gegen einen NC aus und lässt die Stromversorgung darüber laufen. Das hat zur Folge, dass beim Drücken des Knopfes die Versorgungsspannung unterbrochen wird. Beim Loslassen und Starten des ESPs bekommt man dann den Reset Cause 0=Power reboot. Hier ist das Problem, dass man ca. 0,5s den Strom unterbrechen muss, damit der Restart auch sauber ist. So jetzt strengt mal Eure Murmeln an :) Vielleicht gibts wirklich eine coole, verlässliche und intuitive Lösung dafür. Bin für alles dankbar.
:
Bearbeitet durch User
Bei vielen Controllern ist der Resetgrund über Register lesbar.
Manu O. schrieb: > Vielleicht gibts wirklich eine > coole, verlässliche und intuitive Lösung dafür. Ich denke schon. Das Zauberwort heist RTFM.
Roland E. schrieb: > Bei vielen Controllern ist der Resetgrund über Register lesbar. Wenn nicht: man schliesst den Resettaster zusätzlich an einen I/O-Pin an und liest in gleich als erstes ein. Georg
Georg schrieb: > Wenn nicht: man schliesst den Resettaster zusätzlich an einen I/O-Pin an > und liest in gleich als erstes ein. Oder setzt ein Registerflag bevor du ihn schlafen legst. Bei einem Reset sollte das dann nicht gesetzt sein.
Georg schrieb: > man schliesst den Resettaster zusätzlich an einen I/O-Pin an > und liest in gleich als erstes ein. Das wird beim ESP nicht zuverlässig funktionieren, weil er etwa 1 Sekunde zum Booten braucht. Manu O. schrieb: > Nun suche ich nach einer eleganten Lösung zu unterscheiden, ob der > Wakeup durch das Ablaufen des WDT oder durch den Resetknopf ausgelöst > wurde. Lies diese Doku: https://www.espressif.com/sites/default/files/documentation/esp8266_reset_causes_and_common_fatal_exception_causes_en.pdf
erlöser schrieb: > Manu O. schrieb: >> Vielleicht gibts wirklich eine >> coole, verlässliche und intuitive Lösung dafür. > > Ich denke schon. Das Zauberwort heist RTFM. Ernsthaft? Also so kann man sich auch outen keine Ahnung zu haben. :( Oder geht das etwas konstruktiver. Ich hoffte anhand meiner Beschreibung suggeriert zu haben, mich ausgiebig und leider erfolglos mit dem Thema beschäftigt zu haben. Dachte der Sinn von Foren ist es genau in einer Situation in der man -warum auch immer- nicht weiterkommt hier auf gesammeltes Wissen zugreifen zu können.
STK500-Besitzer schrieb: > Georg schrieb: >> Wenn nicht: man schliesst den Resettaster zusätzlich an einen I/O-Pin an >> und liest in gleich als erstes ein. > > Oder setzt ein Registerflag bevor du ihn schlafen legst. > Bei einem Reset sollte das dann nicht gesetzt sein. War auch eine meiner ersten Ideen :) Geht aber nicht, weil der Reset erst nach dem Release den Buttons ausgelöst wird und nicht beim Drücken. Das bedeutet in dem Moment wo der ESP startet ist der Button schon nicht mehr gedrückt :)
Manu O. schrieb: > Ich hoffte anhand meiner Beschreibung > suggeriert zu haben, mich ausgiebig und leider erfolglos mit dem Thema > beschäftigt zu haben. Glaube ich nicht. Das verlinkte PDF habe ich innerhalb 3 Sekunden mit Google gefunden, indem ich einfach nur die Stichworte "ESP8266 reset cause" eingab.
Manu O. schrieb: > Das bedeutet in dem Moment wo der ESP startet ist der Button schon nicht > mehr gedrückt :) Ja schon, aber ein C könnte sich das merken. Mit Diode und zwei Widerständen für auf- und entladen, ist das eine saubere Lösung. Viel Erfolg
Stefan ⛄ F. schrieb: > Lies diese Doku: > https://www.espressif.com/sites/default/files/documentation/esp8266_reset_causes_and_common_fatal_exception_causes_en.pdf Ich denke, dass Stefans Hinweiß zielführend ist. Siehe: 1.2. Identifying Reset Cause Using User Program
:
Bearbeitet durch User
Beitrag #7132371 wurde vom Autor gelöscht.
Gerald K. schrieb: > Ich denke, dass Stefans Hinweiß zielführend ist. Siehe: > > 1.2. Identifying Reset Cause Using User Program Leider nein. Beim ESP kann man den Sleep aufgrund eines Bugs im ROM nicht beenden. Was aber funktionert ist, dass die RTC GPIO16 bei Ablauf des Timers auf 0 zieht. Das nutzt man, indem man GPIO16 auf den Reset-Pin verdrahtet. Somit kann der Controller nicht entscheiden, ob jetzt die RTC oder der Resetknopf zum Reset geführt hat. Anscheinend werden beim Reset nicht alle Register gelöscht, deshalb weiss der ESP, dass er zuvor am schlafen war. Aber nicht, wieso er aufgewacht ist. Um einen Kondensator, ne Diode und nen Widerstand wird der TE nicht herumkommen.
:
Bearbeitet durch User
Eduard I. schrieb: > Beim ESP kann man den Sleep aufgrund eines Bugs im ROM > nicht beenden. Das ist in diesem Fall egal, denn er will nur zwischen Watchdog und andere Quellen unterscheiden.
Du könntest ein kleines Flip-Flop an den Reset Taster anschließen, z.B. 74LVC1G74 Das wird vom Taster gesetzt/gelöscht (je nach Funktionsweise des Tasters) und kann dann ganz bequem im Hauptprogramm ausgelesen werden. Nachteil: Du brauchst einen Pin zum zurück setzen.
So ins Blaue gedacht: Nach dem Aufwachen den RTC-Timer auslesen. Wenn der sagt dass 1 Stunde vergangen ist, dann war es wohl nicht der Reset-Taster.
Stefan ⛄ F. schrieb: > Manu O. schrieb: >> Ich hoffte anhand meiner Beschreibung >> suggeriert zu haben, mich ausgiebig und leider erfolglos mit dem Thema >> beschäftigt zu haben. > > Glaube ich nicht. Das verlinkte PDF habe ich innerhalb 3 Sekunden mit > Google gefunden, indem ich einfach nur die Stichworte "ESP8266 reset > cause" eingab. Lieber Stefan, diese Doku hatte ich sogar nach 1,423 Sekunden (lt. Google) gefunden. :P Wie ich im Eröffnungsthread versucht habe zu verdeutlichen, funktioniert es eben so nicht. Der Reset Cause 6 kommt nur bei einem Reset, wenn der ESP sich nicht im Deep Sleep befindet. War er im Deep Sleep kommt immer 5, unabhängig ob über WDT oder RST. Ich bekomme nur einen anderen Cause als 5, wenn ich den ESP von der Versorgungspannung nehme und damit quasi komplett resete. _______________________ Die Variante mit dem Kondensator, ner Diode, den den Widerständen hatte ich tatsächlich auch schon versucht umzusetzen, damit ein zusätzlicher Eingangskanal bis kurz nach dem Start quasi hochgezogen wird. Tja was soll ich sagen. Ich hab´s nicht umgesetzt bekommen. Vielleicht hatte ich auch die falschen Werte für die Komponenten genommen. Wenn hier jemand mal Vorschläge hätte wäre das ne super Sache. _______________________ Den FlipFlop Ansatz finde ich gar nicht so uninteressant. Zumindest in Punkto Zuverlässigkeit steht dieser wohl recht weit oben. Aber es gehen halt 2 Pins drauf. Einer zum Einlesen des Status beim Start und einer zum Resetten :( Die habe ich nicht mehr frei. _______________________ Nach dem Aufwachen den RTC-Timer auslesen: Geht das? Da muss ich mich mal schlau machen :) Hat natürlich auch eine gewisse Unschärfe, da die Genauigkeit vom WDT grottenschlecht ist (Schwankt bei mir um ca. 5 Minuten) aber bezogen auf die Stunde Deepsleep, könnte man evtl. sogar damit leben. Grenzwertig wird es eben nur wenn man z.B. innderhalb dieser 5 Minuten grundsätzlich von einen WDT Reset ausgeht :) Dann muss man in diesem Sonderfall eben wieder ein 2. Mal drücken. Geht ja nicht um Leben und Tod ;) _______________________ Alles sehr gute und konstruktive Vorschläge. Danke Euch. Der Thread bildet bestimmt eine gute Referenz, falls jemand ein ähnliches Problem hat. Jetzt haben wir schon 3 neue Lösungen, eine mit ohne zusätzlichen pin, einen mit einem und eine mit 2 Pins, die alle ihre Vor- und Nachteile haben :)
:
Bearbeitet durch User
Ich habe das Problem mit dem "Sleep" umgangen in dem ich den ESP nur für die Kommunikation verwende und diesen durch einen andern MC während den Kommunikationspausen von der Versorgung trennen lasse. Dieser zweite MC ist ein MSP430G2553, dieser übernimmt die eigentliche Verarbeitung, die Funktion zur Peripherie und kommuniziert mit dem ESP mittels AT Kommandos über die serielle Schnittstelle. Der MSP430 schaltet sich in den Sleepmodus und lässt sich über die Peripherie oder spätesten nach einer Stunde von einen Timer aufwecken. Der MSP430 schaltet dann den ESP an die Versorgung und schickt über diesen Zustandsmeldungen an einen übergeordneten Server (ein Raspberry Pi).
Angehängte Dateien:
-
flip-flop.png
2,2 KB
Manu O. schrieb: > Den FlipFlop Ansatz finde ich gar nicht so uninteressant. Zumindest in > Punkto Zuverlässigkeit steht dieser wohl recht weit oben. Aber es gehen > halt 2 Pins drauf. Einer zum Einlesen des Status beim Start und einer > zum Resetten Normalerweise kann man Pins umprogrammieren, ob sie Eingang oder Ausgang sein sollen. Und, das Einlesen und das Resetten passiert nacheinander. Da müsste man doch mit einem Pin auskommen? - alle AND-Pins sind high, DER_LETZTE_FREIE_PIN ist Eingang - ein Watchdog-Reset steuert hoffentlich(!) den Reset-Pin nicht an - das Programm startet neu und liest den Eingang (high) - jemand drückt den Taster, Reset - der erste Eingang wird low - der Ausgang wird low - der zweite Eingang wird low - der Taster öffnet wieder - der erste Eingang wird high - der Ausgang bleibt low - das Programmm startet und liest den Eingang (low) - der Pin wird auf Ausgang, high, umgeschaltet - beide AND-Eingänge sind high, der Ausgang wird high - der Pin wird wieder zum Eingang - der AND-Ausgang bleibt high Statt 74AUP1G97 sollte fast jedes CMOS-AND-Gatter funktionieren.
Bauform B. schrieb: > - ein Watchdog-Reset steuert hoffentlich(!) den Reset-Pin nicht an Leider doch. Lässt sich aber mit 2 Dioden beheben.
Gerald K. schrieb: > Ich denke, dass Stefans Hinweiß zielführend ist. ALter geht es noch? Hinweis!!!
Jefe schrieb: > Gerald K. schrieb: > >> Ich denke, dass Stefans Hinweiß zielführend ist. > > ALter geht es noch? Hinweis!!! Danke, hat nichts mit weiß zu tun!
Manu O. schrieb: > Wie ich im Eröffnungsthread versucht habe zu verdeutlichen, > funktioniert es eben so nicht. Der Reset Cause 6 kommt nur > bei einem Reset, wenn der ESP sich nicht im Deep Sleep befindet. Das ist mir schon klar. Deine Frage war aber: Manu O. schrieb: > Nun suche ich nach einer eleganten Lösung zu unterscheiden, ob der > Wakeup durch das Ablaufen des WDT oder durch den Resetknopf ausgelöst > wurde. Der WDT kann im Deep-Sleep Modus nicht ablaufen. Wenn der WDT abläuft, kann man dies als Reset-Cause einwandfrei abfragen. Du willst offenbar den Reset durch Wakeup-Timer erkennen. Wenn du das geschrieben hättest, hätte ich dir passend geantwortet. Denn dass der Timer-Ausgang mit dem externen Reset-Pin verbunden werden muss (und welche Konsequenz das hat), ist mir durchaus bekannt. Nächstes mal bitte die Frage präzisieren, sobald offensichtlich wird, dass sie falsch verstanden oder falsch gestellt wurde.
Manu O. schrieb: > War auch eine meiner ersten Ideen :) Geht aber nicht, weil der Reset > erst nach dem Release den Buttons ausgelöst wird und nicht beim Drücken. > > Das bedeutet in dem Moment wo der ESP startet ist der Button schon nicht > mehr gedrückt :) Wie jetzt? Der Watchdog leert auch den kompletten Speicher? (Ich kenne das "Problem" nur vom AVR, bei dem es ein Register mit der Angabe der letzten Resetquelle gibt.)
STK500-Besitzer schrieb: > Der Watchdog leert auch den kompletten Speicher? Der Watchdog nicht, aber danach kommt der Bootloader und danach das C Programm. Ich habe das auch mal kontrolliert, vom RAM bliebt offenbar nichts erhalten.
Stefan ⛄ F. schrieb: > Der Watchdog nicht, aber danach kommt der Bootloader und danach das C > Programm. Ich habe das auch mal kontrolliert, vom RAM bliebt offenbar > nichts erhalten. schade. Man könnte noch ein externes FlipFlop anbinden, das auch durch den Reset-Taster resettet wird.
Stefan ⛄ F. schrieb: > vom RAM bliebt offenbar > nichts erhalten. Gibt's da nicht die ~500 Byte "RTC Memory"-Region, die nicht explizit genullt wird? system_rtc_mem_read & system_rtc_mem_write bzw. ESP.rtcUserMemoryRead/Write im Arduino-Core? Aber hilft das weiter? Dieser Speicher bleibt ja beim Deep-Sleep-Wakeup genau wie beim Reset-Button-Drücken erhalten.
Εrnst B. schrieb: > Aber hilft das weiter? Dieser Speicher bleibt ja beim Deep-Sleep-Wakeup > genau wie beim Reset-Button-Drücken erhalten. Dachte ich mir auch. Man könnte vielleicht das Weckdatum mit dem aktuellen vergleichen. Oder, wenn es sich um einen Countdown handelt, den auf "0" vergleichen.
Stefan ⛄ F. schrieb: > > Der WDT kann im Deep-Sleep Modus nicht ablaufen. Wenn der WDT abläuft, > kann man dies als Reset-Cause einwandfrei abfragen. Du willst offenbar > den Reset durch Wakeup-Timer erkennen. Wenn du das geschrieben hättest, > hätte ich dir passend geantwortet. Denn dass der Timer-Ausgang mit dem > externen Reset-Pin verbunden werden muss (und welche Konsequenz das > hat), ist mir durchaus bekannt. > > Nächstes mal bitte die Frage präzisieren, sobald offensichtlich wird, > dass sie falsch verstanden oder falsch gestellt wurde. Da entschuldige ich mich. Hatte versucht das so präzise es geht mit meinem begrenztem Vokabular zu beschreiben. Wahrscheinlich steckst du tiefer in der Materie und hast es deshalb anders verstanden. Nun hast du mich aber abgehängt. Wenn gilt: >*"Wenn der WDT abläuft, kann man dies als Reset-Cause einwandfrei abfragen"* wie du das geschrieben hast, würde mir das völlig reichen. Bei allen anderen Fällen gehe ich dann eben von einen Reset über den Button aus. Oder verstehe ich das falsch. Der WDT (Watchdog Timer) wird beim "schicken" in den Deep Sleep auf einen bestimmten Wert gesetzt. Nach Ablauf (0) oder erreichen des Wertes, je nachdem wie das intern funktioniert, schickt der µC ein (Masse)Impulse auf einen Pin (D0 beim Wemos Mini) Wenn ich diesen Pin auf den RST Pin verbinde wird der ESP neu gestartet. Der RST Pin am Wemos selbst "sieht" aber nicht ob der Impuls vom D0 Pin (also über den WDT/D0) oder vom RST-Button ausgelöst wurde.
Gibt es keinen anderen Pin mit er aus dem Deep Sleep aufwacht? Normale uC haben mehrere solche Pins.
Εrnst B. schrieb: > Aber hilft das weiter? Dieser Speicher bleibt ja beim Deep-Sleep-Wakeup > genau wie beim Reset-Button-Drücken erhalten. ich denke schon. Man kann ja genau vor dem Deepsleep einen Marker setzen. Im Normalbetrieb ist der Marker eben nicht gesetzt. Ist beim boot der Marker gesetzt, war er vorher im deepsleep. https://hutscape.com/tutorials/rtc-memory
Manu O. schrieb: > Hintergrund: > Die Daten werden stündlich an einen Server übermittelt. > Wenn ich auf den RST Button drücke, möchte ich jedoch, dass sich das > OLED mit anschaltet und ich alle Infos auf diesem angezeigt bekomme. Das > dauert eine Weile und kostet Strom. Daher sollte es eben auch nur beim > Drücken des RST Buttons passieren. wenn du mit dem RTC nicht zurecht kommst, könntest ja nach dem Aufwachen zunächst den Server abfragen, wie alt die Daten dort sind - und wenn sie jünger als 1h sind, wars nicht ein deepsleep.
Bauform B. schrieb: > Gibt es keinen anderen Pin mit er aus dem Deep Sleep aufwacht? Normale > uC haben mehrere solche Pins. Naja, der ESP hätte vielleicht mehrere Alternativen. Pin7: CHIP_EN I an input pin. When CHIP_EN pin is HIGH chip works properly when LOW chip consumed an only small amount of current. Es gibt sogar: Pin32: EXT_RSBT is an input pin used to rest the chip by providing an external reset signal which is active at a low voltage level. Das Problem ist, ich komme beim Wemos D1 Mini Board nicht an die Pins ran. Und selbst wenn, müsste ich bei jeder Platine dann nochmal extra das Board bearbeiten. Und die Pins beim ESP8266 sind schon ziemlich klein :)
noiasca schrieb: > ich denke schon. > Man kann ja genau vor dem Deepsleep einen Marker setzen. > Im Normalbetrieb ist der Marker eben nicht gesetzt. Das Problem ist ja: Der ESP setzt den Marker, geht in den Deep-Sleep, und jetzt drückt jemand den Reset-Knopf, bevor der Wake-Up-Timer abgelaufen ist. d.H. der Marker im RTC-Memory ist gesetzt, egal ob's ein Tastendruck oder eine vom Timer-IO ausgelöste Flanke am RST war. Man könnte vor dem Sleep die aktuelle Zeit wegspeichern, und beim Aufwachen nachsehen, ob weniger als eine Stunde vergangen ist. Dafür braucht der ESP aber die Uhrzeit. Wenn die aus dem Netzwerk kommt, wird die Reaktion auf den Tastendruck sehr träge ausfallen, das Display schaltet sich erst nach Verbindungsaufbau, DHCP, NTP-Abfrage ein.
noiasca schrieb: > Manu O. schrieb: >> Hintergrund: >> Die Daten werden stündlich an einen Server übermittelt. >> Wenn ich auf den RST Button drücke, möchte ich jedoch, dass sich das >> OLED mit anschaltet und ich alle Infos auf diesem angezeigt bekomme. Das >> dauert eine Weile und kostet Strom. Daher sollte es eben auch nur beim >> Drücken des RST Buttons passieren. > > wenn du mit dem RTC nicht zurecht kommst, könntest ja nach dem Aufwachen > zunächst den Server abfragen, wie alt die Daten dort sind - und wenn sie > jünger als 1h sind, wars nicht ein deepsleep. Der Ansatz ist auf jeden Fall gut, hat aber einige Fallstricke: - der WDT ist nicht präzise (Schwankung ca. 5 Minuten bei einer Stunde) - es kann vorkommen, dass (durch Wifi o.Ä.) mal Daten nicht den Server erreichen. Dann würde das Programm in Folge immer von einen WDT Reset ausgehen. - die Kommunikation läuft über MQTT, da hat man nicht besonders gut in der Hand, wie/was/wann gesendet und empfangen wird. Wie gesagt, manchmal verschluckt er auch Daten oder sendet vor dem Empfangen ect. - Er braucht immer erst eine WiFi Verbindung, das dauert ca. 5 Sekunden. Haptisch also nicht so der Knaller ;) Ich denke alles was in die Richtung Zeitmessung geht ist unsauber, es sei denn, man kommt an den Wert des WDT irgendwie ran. Und selbst da ist es nicht 100% präzise, weil man nicht genau weiß, wann (also wie lange nach dem Rebboot) man diesen ausliest. Cool wäre so ein Wert wie "WDT abgelaufen" oder so :)
:
Bearbeitet durch User
Manu O. schrieb: > wie du das geschrieben hast, würde mir das völlig reichen. Offenbar nicht. Der Watchdog Timer hat nichts mit dem Wakeup Timer zu tun. Das sind zwei völlig unabhängige Dinge! Den Ausgang des Wakeup-Timer muss man mit dem Reset-Pin verbinden, weil der ESP sonst nur aufwacht aber nicht bootet (vermutlich Bug im Bootloader). Durch diese Verkabelung löst der Wakeup-Timer faktisch einen externen Reset am Reset Pin aus. Das heißt: Du kannst nicht zwischen Wakeup (aus dem Deep-Sleep) und einem externen Reset unterscheiden. Der WatchDog Reset ist eine ganz andere Sache, hat mit dem Aufwachen aus dem Deep-Sleep Modus nichts zu tun. Der Watchdog Reset tritt auf, wenn dein Programm in einer Endlosschleife hängt. > Gibt es keinen anderen Pin mit er aus dem Deep Sleep aufwacht? Nein leider nicht. Der ESP8266 ist halt eine beschränkte Gurke. Ich erwarte ja nicht viel von den Chinesen, aber dass sie nicht einmal den Bug im Bootloader beheben, das erstaunt mich doch sehr. Und die oftwareentwicklung lief ja auch nicht gerade gut. Dementsprechend wenig Interesse habe ich an weitere Produkt von dieser Firma. Nur wenn es ultra-billig sein muss nehme ich den ESP8266.
noiasca schrieb: > Ist beim boot der Marker gesetzt, war er vorher im deepsleep. Was allerdings nichts darüber aussagt, ob er via externem Reset oder Wakeup-Timer aufgeweckt wurde.
Manu O. schrieb: > Naja, der ESP hätte vielleicht mehrere Alternativen. > > Pin7: CHIP_EN I an input pin. When CHIP_EN pin is HIGH chip works > properly when LOW chip consumed an only small amount of current. Funktioniert nicht. Man muss wirklich einen Reset machen, um den Chip aus dem Deep-Sleep Modus zu holen. > Es gibt sogar: > Pin32: EXT_RSBT is an input pin used to rest the chip by providing an > external reset signal which is active at a low voltage level. Das ist keine Alternative, sondern der normale Reset Eingang, der üblicherweise mit dem Ausgang des Wakeup-Timers verbunden wird (GPIO16).
Hab nochmal genauer über die AND Gate Lösung nachgedacht, weil ich die im Ansatz richtig cool fand. Die zusätzliche Diode(n) zum trennen von WDT oder Button Signal wäre ja jetzt kein Problem. Ich vermute mal das wird aber dennoch nicht funktionieren. Das Problem ist DER_LETZTE_FREIE_PIN Dieser müsste vor dem DeepSleep als Ausgang und High definiert werden und während des DeepSleep auf High gehalten werden, damit der Zustand definiert ist. Kommt der Reset über den WDT läuft alles wie bauformb beschrieben hat. Wird jetzt aber der Resetbutton gedrückt,schaltet für die Zeit des Drückens zwar alles auf Low, beim Loslassen aber auch alles wieder auf High, weil der DER_LETZTE_FREIE_PIN noch auf OUTPUT und High ist. Oder hab ich jetzt einen Denkfehler?
Manu O. schrieb: > Die zusätzliche Diode(n) zum trennen von > WDT oder Button Signal wäre ja jetzt kein Problem. Das ist unmöglich. Der Watchdog Timer hat keinen herausgeführten Ausgang. Da gibt es nichts, wo man eine Diode anschließen könnte.
Manu O. schrieb: > Wird jetzt aber der Resetbutton gedrückt,schaltet für die Zeit des > Drückens zwar alles auf Low, beim Loslassen aber auch alles wieder auf > High, weil der DER_LETZTE_FREIE_PIN noch auf OUTPUT und High ist. > Oder hab ich jetzt einen Denkfehler? Kann ich nicht sagen, weil nicht klar ist, welchen Pin du dafür nehmen willst. Wie sich die Pins beim Starten verhalten, habe ich auf meiner Homepage beschrieben.
Stefan ⛄ F. schrieb: > Manu O. schrieb: >> Die zusätzliche Diode(n) zum trennen von >> WDT oder Button Signal wäre ja jetzt kein Problem. > > Das ist unmöglich. Der Watchdog Timer hat keinen herausgeführten > Ausgang. Da gibt es nichts, wo man eine Diode anschließen könnte. Ich glaube wir reden noch immer aneinander vorbei. :( Der WDT gibt ein Signal an D0, wenn die Zeit die für den DeepSleep definiert wurde abgelaufen ist. ESP.deepSleep(<wert>); Damit kann ich jetzt alles Mögliche machen, und wenn ich D0 mit dem RST Pin des Wemos verbinde starter dieser neu. Möglich das es technisch anders oder korrekter zu beschreiben ist und das nicht der WDT macht, sondern irgendeine andere Komponente im ESP die auf den WDT "guckt". Möglich auch, dass die Zeit nicht abläuft, sondern verrinnt und auch möglich das die Komponente nicht "guckt" sonder "hört" oder das Signal nicht "an" sondern "auf" D0 gegeben/geschoben/gelegt wird. Aber du verstehst doch hoffentlich mein grundsätzliches Anliegen?!
Stefan ⛄ F. schrieb: > Manu O. schrieb: >> Wird jetzt aber der Resetbutton gedrückt,schaltet für die Zeit des >> Drückens zwar alles auf Low, beim Loslassen aber auch alles wieder auf >> High, weil der DER_LETZTE_FREIE_PIN noch auf OUTPUT und High ist. >> Oder hab ich jetzt einen Denkfehler? > > Kann ich nicht sagen, weil nicht klar ist, welchen Pin du dafür nehmen > willst. Wie sich die Pins beim Starten verhalten, habe ich auf meiner > Homepage beschrieben. Langsam kommtich dahinter. Du magst mich vorführen :( Konstruktive Antwort wäre: Geht doch, du musst aber PIN<sowieso> nehmen. Kannst du auch unter meiner HP (www.guckstdumalhiernach.de) nachlesen. ___________________________________________________________________ Ich unterstelle mal, das es KEINEN Pin gibt, der solange ohne Code und im Deepsleep als OUTPUT und HIGH definiert ist bis er ein LOW Signal bekommt, und dieses dann hält und zum INPUT wird. Lasse mich aber gerne vom Gegenteil überzeugen.
:
Bearbeitet durch User
Manu O. schrieb: > Stefan ⛄ F. schrieb: >> Manu O. schrieb: >>> Die zusätzliche Diode(n) zum trennen von >>> WDT oder Button Signal wäre ja jetzt kein Problem. >> >> Das ist unmöglich. Der Watchdog Timer hat keinen herausgeführten >> Ausgang. Da gibt es nichts, wo man eine Diode anschließen könnte. > > Ich glaube wir reden noch immer aneinander vorbei. :( Der WDT gibt ein > Signal an D0, wenn die Zeit die für den DeepSleep definiert wurde > abgelaufen ist. > > ESP.deepSleep(<wert>); > > Damit kann ich jetzt alles Mögliche machen, und wenn ich D0 mit dem RST > Pin des Wemos verbinde starter dieser neu. Ja, ihr redet aneinander vorbei. Du solltest nach diversen Erklärungen kapiert haben, daß der Watchdog Timer dir beim Deep Sleep nicht helfen kann und nichts mit dem D0 Pin zu tun hat. Über D0 und Reset kann der ESP von der RTC neu gestartet werden, die im Deep Sleep weiterläuft. Also nutze nicht mehr den Begriff Watchdog Timer oder WDT in Zusammenhang mit deinem Problem, dann stellt sich Stefan vielleicht auch nicht mehr so begriffstutzig an. Du könntest doch einfach einen Kondensator nehmen, der beim Drücken des Reset Knopf (aber nicht von D0) entladen wird (beide über Schottky Dioden entkoppeln), und den hängst du an den übrigen Eingangspin. Geladen wird er über einen hochohmigen Widerstand, mit einer Zeitkonstante die gewährleistet, daß die Kondensatorspannung nach dem Bootvorgang noch sicher als LOW erkannt wird.
Hab ich tatsächlich erst jetzt kapiert. Dachte bisher wirklich der WDT wird hergenommen um den DeepSleep zu beenden. Tatsächlich scheint er also nur zu greifen, wenn ein z.B. ein anderer Fehler vorliegt, also das µC sich z.B. aufgehangen habt. Okay, danke für die Erläuterung. Der Reset Impuls kommt also von der RTC. Das Problem bleibt allerdings das gleiche! Man kann nicht unterscheiden, was den Reset ausgelöst hat. :( Die Variante mit dem Kondensator scheint sich nun mit als beste Lösung zu entpuppen. Da werde ich noch ein bisschen Hirnschmalz drauf verwenden.
Manu O. schrieb: > Der WDT gibt ein > Signal an D0, wenn die Zeit die für den DeepSleep definiert wurde > abgelaufen ist. Nein, das macht der Wakeup-Timer.
Robert schrieb: > dann stellt sich Stefan vielleicht auch > nicht mehr so begriffstutzig an. Entschuldige mal, ich bin hier ganz gewiss nicht Begriffstutzig. Ich habe auf die richtige Doku verwiesen und konsequent korrekt zwischen WDT und Wakeup-Timer unterschieben. Stefan ⛄ F. schrieb: > Lies diese Doku: > https://www.espressif.com/sites/default/files/documentation/esp8266_reset_causes_and_common_fatal_exception_causes_en.pdf Stefan ⛄ F. schrieb: > Der WDT kann im Deep-Sleep Modus nicht ablaufen. Wenn der WDT abläuft, > kann man dies als Reset-Cause einwandfrei abfragen. Du willst offenbar > den Reset durch Wakeup-Timer erkennen Stefan ⛄ F. schrieb: > Der Watchdog Timer hat nichts mit dem Wakeup Timer zu tun. Das sind zwei > völlig unabhängige Dinge! > Den Ausgang des Wakeup-Timer muss man mit dem Reset-Pin verbinden, weil > der ESP sonst nur aufwacht aber nicht bootet... > Der WatchDog Reset ist eine ganz andere Sache, hat mit dem Aufwachen aus > dem Deep-Sleep Modus nichts zu tun. Der Watchdog Reset tritt auf, wenn > dein Programm in einer Endlosschleife hängt. Stefan ⛄ F. schrieb: > Das (EXT_RSBT) ist keine Alternative, sondern der normale Reset > Eingang, der üblicherweise mit dem Ausgang des Wakeup-Timers > verbunden wird (GPIO16). Stefan ⛄ F. schrieb: > Das ist unmöglich. Der Watchdog Timer hat keinen herausgeführten > Ausgang. Da gibt es nichts, wo man eine Diode anschließen könnte. Manu O. schrieb: > Der WDT gibt ein Signal an D0, wenn die Zeit für den DeepSleep > definiert wurde abgelaufen ist. Nein! Wie kann es sein, dass du nach so vielen wiederholten Erklärungen immer noch diese falsche Schlussfolgerung ziehst? Also wenn ich begriffsstutzig bin, dann hier. Ich begreift nicht, wie das sein kann. Also naochmal zum mitmeißeln: Nicht der Watchdog Timer, sondern der Wakeup Timer gibt dieses Signal an D0 aus, welches man mit dem Reset Eingang verbinden muss. Manu O. schrieb: > Konstruktive Antwort wäre: > Geht doch, du musst aber PIN<sowieso> nehmen. Es gibt aber keinen geeigneten Pin! Das haben dir andere mehrfach geschrieben. > Kannst du auch unter meiner HP (www.guckstdumalhiernach.de) nachlesen. Wenn ich den Link zu oft poste, bekomme ich Shitstorm. Es ist http://www.stefanfrings.de
Stefan ⛄ F. schrieb: > > Nein! Wie kann es sein, dass du nach so vielen wiederholten Erklärungen > immer noch diese falsche Schlussfolgerung ziehst? Also wenn ich > begriffsstutzig bin, dann hier. Ich begreift nicht, wie das sein kann. > > Also naochmal zum mitmeißeln: > Nicht der Watchdog Timer, sondern der Wakeup Timer gibt dieses Signal an > D0 aus, welches man mit dem Reset Eingang verbinden muss. Sorry Stefan, ich schätze deine Beiträge und wollte dir nicht zunahe treten. Aus dem Kontext heraus war es mir klar was der TO möchte, und ich dachte dir ebenso. Deshalb haben ich mich über deine wiederholten Erklärungen gewundert.
Die Verwirrung kommt wohl von den chinesischen Abkürzungen. Mit "WDT" ist natürlich der "Wake-up from Deep sleep Timer" gemeint ;)
Bauform B. schrieb: > Die Verwirrung kommt wohl von den chinesischen Abkürzungen. Mit "WDT" > ist natürlich der "Wake-up from Deep sleep Timer" gemeint ;) Bitte nicht, ich finde das nicht lustig.
Bauform B. schrieb: > Die Verwirrung kommt wohl von den chinesischen Abkürzungen. Mit "WDT" > ist natürlich der "Wake-up from Deep sleep Timer" gemeint ;) So würde ich nochmal aus der Nummer rauskommen. :) Nee, Nee. Mal im Ernst, mein einziger Denkfehler war doch, dass der WDT eben nicht genutzt wird, um dein Wakeup zu triggern. Sorry das ich den Fokus nicht drauf gelegt habe, sondern auf das eigentliche Problem, was ja erst nach dem Triggern kommt.
:
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.