Hallo zusammen. Ich habe einen ESP-12S und dort den IO16 mit Reset verbunden damit der deep sleep funktioniert. Der ESP geht auch wie erwartet in den Tiefschlaf, und wacht auch auf, schreibt mir ets Jan 8 2013,rst cause:2, boot mode:(3,6) aber das Programm startet nicht. Was ich mit dem Oszi sehen konnte ist: - An IO15, da habe ich nur einen 4,7 kOhm Pulldown, wackelt es hin und her, mal 0 V, mal die VCC Spannung 3,6 V. - An I2C habe ich Sensoren und da liegt nach dem Tiefschlaf dauerhaft die Clock SCL (IO0) an. Was habe ich schon probiert? Ich habe einen 100 nF Kondensator an Reset entfernt. Reset hat einen 10 kOhm Pullup. Der IO2 hat einen 10 kOhm Pullup. Ich habe aus meinem Programm alle I2C Bestandteile entfernt (auch wire). Und trotzdem toggelt SCL dauerhaft nach dem Tiefschlaf. Meine Fragen sine jetzt: - Muss ich in meinem Programm irgendwelche Dinge beachten nach dem Aufwachen? - Ich verwende Wire für I2C, kann ich das irgendwie vor dem Tiefschlaf deaktivieren damit da SCL dauerhaft aus bleibt? - Ich habe am I2C einen VEML7700 und einen BME280. Die werden vor dem Tiefschlaf auch korrekt gefunden und liefern ordentliche Werte, alles wunderbar. Nach dem Tiefschlaf liegt aber SCL dauerhaft an, auch wenn ich wire und I2C in meinem Programm nicht verwende. Während des Tiefschlafs ist SCL dauerhaft low. SCL ist an IO0 und SDA an IO4. habe ich da einen Fehler gemacht? Nachtrag: Ich habe jetzt versucht vor dem Tiefschlaf beide Sensoren am I2C auch in den Tiefschlaf zu schicken mit: settings.mode = BME280::Mode_Sleep; bme.setSettings(settings); veml.enable(0); Hat aber nichts gebracht. Direkt nach dem Aufwachen sehe ich wieder die I2C Clock. Nachtrag2: Über einen Taster an Reset startet der ESP wunderbar neu und startet auch das Programm. Edit: Sorry, bitte in das uC Forum verschieben. Danke!
:
Bearbeitet durch User
Hallo, ich habe meist 10k an GPIO15, der Wert ist aber relativ egal. Warum hast Du I2C an GPIO0 und 5? GPIO0 ist kritisch, weil er entscheidet, wie gebootet wird, der muß beim Reset/Aufwachen sicher auf H liegen. Üblich ist eher GPIO4 und 5 für I2C, die sind da unkritisch. Ein ESP8266-12 mit BME280 und BH1750 an einer LiFePO4 Zelle hat hier noch nie Probleme gemacht. Gruß aus Berlin Michael
Da gibt es eine ganze Menge zu beachten. Michael hat den Anfang gemacht, aber da sind noch mehr Pins, die zum Start bestimmte Pegel haben müssen. Am besten liest du dich mal dort ein: http://stefanfrings.de/esp8266/index.html Ohne Schaltplan und Quelltext können wir dir nicht konkreter helfen.
:
Bearbeitet durch User
Michael U. schrieb: > Warum hast Du I2C an GPIO0 und 5? GPIO0 ist kritisch, weil er > entscheidet, wie gebootet wird, der muß beim Reset/Aufwachen sicher auf > H liegen. Da hatte ich nicht dran gedacht, bin Anfänger und das ist ein Lernprojekt. Ich habe da aber 4,7 kOhm als Pullup an SCL und SDA. Michael U. schrieb: > Üblich ist eher GPIO4 und 5 für I2C, die sind da unkritisch. OK, werde ich in Zukunft beachten. -------------------------------------------------------- So, jetzt habe ich eine 2. Platine nur minimal bestückt, also auch beide Sensoren am I2S weggelassen. Und auch mein Programm habe ich sehr minimalistisch gehalten. Das Problem besteht weiterhin. Nach dem Tiefschlaf startet der ESP und schreibt mir: ets Jan 8 2013,rst cause:2, boot mode:(3,6) Das ist exakt die gleiche Meldung wie wenn ich den Reset Taster drücke. Nur mit dem Unterschied, dass beim Reset Taster das Programm startet und SCL ruhig bleibt. Über den Reset nach dem deep sleep startet das Programm nicht und SCL toggelt fröhlich vor sich hin. Das Programm:
1 | int cap_u_gate = 12; |
2 | int cap_u_temp_u = 13; |
3 | int cap_o_gate = 2; |
4 | int cap_o_temp_m = 14; |
5 | int temp_gate = 15; |
6 | |
7 | void setup() { |
8 | pinMode(cap_u_gate, OUTPUT); |
9 | pinMode(cap_u_temp_u, INPUT); |
10 | pinMode(cap_o_gate, OUTPUT); |
11 | pinMode(cap_o_temp_m, INPUT); |
12 | pinMode(temp_gate, OUTPUT); |
13 | |
14 | digitalWrite(cap_u_gate,LOW); |
15 | digitalWrite(cap_o_gate,LOW); |
16 | digitalWrite(temp_gate,LOW); |
17 | |
18 | // UART |
19 | Serial.begin(74880); |
20 | Serial.println("Start!"); |
21 | |
22 | ESP.deepSleep(10e6,WAKE_RF_DISABLED); |
23 | delay(100); |
24 | } |
25 | |
26 | void loop() { |
27 | } |
Um Strom zu sparen habe ich vor ein paar Sensoren Schalter eingebaut. Die sollen als Default abgeschaltet sein digitalWrite(cap_u_gate,LOW); digitalWrite(cap_o_gate,LOW); digitalWrite(temp_gate,LOW); und nur zur Messung kurz eingeschaltet werden, also nur kurz Strom bekommen. Wie ist das mit dem deep sleep, was machen da die IOs? Behalten die den letzten Zustand, werden die hochohmig? Edit: Auch ein noch kleineres Programm wird nach dem deep sleep nicht erneut aufgerufen:
1 | void setup() { |
2 | Serial.begin(74880); |
3 | Serial.println("Start!"); |
4 | ESP.deepSleep(10e6,WAKE_RF_DISABLED); |
5 | delay(100); |
6 | } |
7 | |
8 | void loop() { |
9 | } |
Kann das was mit dem UART zu tun haben? Darf der beim Reset nach dem deep sleep nicht angeschlossen sein? Mich irritiert, dass der normale Reset über den Taster funktioniert und der ESP auch exakt die gleiche Meldung ausgibt, egal ob über Resettaster oder über automatischen Reset nach deep sleep.
:
Bearbeitet durch User
Ich zitiere mal von meiner eigenen Webseite: > Normaler Start: > GPIO0 = HIGH > GPIO15 = LOW > GPIO1 (TxD) = nicht herunter ziehen > GPIO2 (TxD1) = nicht herunter ziehen Prüfe diese Signalpegel. Einer davon wird wohl nicht stimmen. In der Nähe des ESP Moduls sollten alle Widerstände nicht mehr als 2,2kΩ haben, weil die Signale sonst von den eigenen Radiowellen gestört werden. 100kΩ sind dort ein absolutes No-Go. S1 ist gefährlich. Wenn er geschlossen ist, bootet das Ding nicht und wenn du diesen Pin versehentlich aus Ausgang konfigurierst, geht er auch noch kaputt! Bei deinem "cap_o_gate" Pin ist unklar, was du da angeschlossen hast. Wenn da eine kapazitive Last dran hängt (das kann auch ein MOSFET sein), dann kann das auch den Bootvorgang blockieren. > Kann das was mit dem UART zu tun haben? Darf der beim Reset nach > dem deep sleep nicht angeschlossen sein? Der darf schon angeschlossen sein, aber TxD muss auf High Pegel liegen. Wen du da einen USB-UART Adapter dran hängen hast, der keine Stromversorgung hat, dann wird er diesen Pin herunter ziehen, was nicht sein darf.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Ich zitiere mal von meiner eigenen Webseite: >> Normaler Start: >> GPIO0 = HIGH >> GPIO15 = LOW >> GPIO1 (TxD) = nicht herunter ziehen >> GPIO2 (TxD1) = nicht herunter ziehen > > Prüfe diese Signalpegel. Einer davon wird wohl nicht stimmen. Daran hatte ich mich gehalten bei der Schaltung. Aber gut, ich habe gemessen und zwar während der im tiefschlaf ist. Weil das ja der Zustand ist aus dem heraus der aufwacht. TXD High RXD High IO5 unverbunden, Low IO4 Pullup, High IO0 Pullup, High IO2 Pullup, High IO15 Pulldown, Low IO16 Pullup, High IO14 Pulldown, Low IO12 Pulldown, Low IO13 Pulldown, Low High und Low sehen auf dem Oszi wunderbar stabil aus und ändern sich während des Tiefschlafs auch nicht. Stefan ⛄ F. schrieb: > In der Nähe des ESP Moduls sollten alle Widerstände nicht mehr als 2,2kΩ > haben, weil die Signale sonst von den eigenen Radiowellen gestört > werden. 100kΩ sind dort ein absolutes No-Go. OK, dann tausche ich die mal aus. Konnte ich im Datenblatt nicht finden ... und ich betreibe den ja ohne WLAN. Stefan ⛄ F. schrieb: > S1 ist gefährlich. Wenn er geschlossen ist, bootet das Ding nicht Ja, aber wie denn sonst? Ich brauche den doch um in den Download Modus zu kommen? Bisher bootet der wunderbar wenn ich Reset (S2) drücke. Und auch nach dem Tiefschlaf bootet der da irgendwie, der schreibt mir ja diese eine Zeile und dort exakt den gleichen Boot Mode wie wenn ich den über S2 resette. Nur das Programm startet dann nicht, dafür toggelt die SCL. Stefan ⛄ F. schrieb: > wenn du diesen Pin versehentlich aus Ausgang konfigurierst, geht er auch > noch kaputt! Steht das im Datenblatt? Wenn ich den über Wire als SCL konfiguriere dann ist das doch ein Ausgang. Bisher lebt der IO. Auf einer anderen Platine seit mehreren Wochen. Stefan ⛄ F. schrieb: > Bei deinem "cap_o_gate" Pin ist unklar, was du da angeschlossen hast. Da soll natürlich was dran an den IO, aber jetzt in der Minimalbestückung ist nix dran. Da ist die Schaltung gerade genau so wie im Schaltplan. Stefan ⛄ F. schrieb: > Der darf schon angeschlossen sein, aber TxD muss auf High Pegel liegen. Ist angeschlossen, ein USB Adapter mit FT232RL, der bekommt seinen Strom natürlich über USB. Beide UART IOs sind High. Ich verwende ja für den Sleep ESP.deepSleep(60e6,WAKE_RF_DISABLED); aber man kann ja auch esp_sleep_enable_timer_wakeup(60*1000000); esp_deep_sleep_start(); nutzen wenn ich das richtig verstanden habe. Da muss ich aber z. B. "soc/rtc_cntl_reg.h" verwenden und die findet meine Arduino IDE nicht. Wo bekomme ich die her oder was muss ich dazu installieren um diese "nativen" Befehlen nutzen zu können? Und dann gibt es ja noch diese blaue LED am ESP. Kann man die einfach weglöten oder ist die irgendwie erforderlich? Edit: Alle Pullups und Pulldowns gegen 2 kOhm ausgetauscht. Verhalten bleibt leider gleich.
:
Bearbeitet durch User
So, Fehler gefunden, Lösung noch unbekannt. Gefunden hier: https://github.com/esp8266/Arduino/issues/5892 https://github.com/esp8266/Arduino/issues/6007 Was ist also das Problem? Der Resetpuls von IO16 ist eher kurz und schwach und schafft es nicht, Reset ordentlich runter zu ziehen. Siehe Oszi Bildchen. Ich habe extern keinen Kondensator dran. Und ich habe auch den 10 kOhm Pullup an Reset durch einen 300 kOhm ersetzt. Das zeigt das Bild. Da ist also intern im ESP-12S wohl ein Kondensator verbaut. Nach Datenblatt http://wiki.ai-thinker.com/_media/esp8266/a020ps01a0_esp-12s_product_specification.pdf sogar ein 1 uF. So wie ich das sehe kann ich das nicht am Modul (Software/Hardware) lösen ausser ich löte die Schirmung und den Kondensator weg. Machbar, klar, aber ne, will ich nicht. Wie könnte man das extern lösen? Ich bräuchte eine Schaltung die den Kondensator schneller entlädt oder den Resetpuls verlängert. Gleichzeitig geht es natürlich um den Tiefschlaf, die Schaltung darf also nicht viel Strom ziehen.
Ich habe jetzt verschiedene Dinge probiert aber ohne Erfolg. Dem ESP-12S habe ich die Schirmung geklaut (geht schnell und ohne Löten) und den Kondensator C8 (0402 zum Glück gut lötbar) entfernt. Dann konnte ich den Resetpuls also mal angucken wie der wirklich aussieht. Und tja, der ist sehr kurz. Ich vermute das ist eben ein CPU Takt. Das wollte ich irgendwie verlängern, also habe ich extern wieder verschiedene Cs hingelötet und rumprobiert. Wie es aussieht zieht der IO16 nur sehr kurz und eher schwach. Ein Pullup, auch der ESP-interne R2 (12k, 0402) zieht das schon schnell nach oben. Mein bestes Ergebnis ist weder Pullup noch Pulldown und ein sehr kleiner Kondensator um die 100 pF. Aber auch das reicht nicht für den Reset. Wobei ... irgendwas wird ja resettet, der ESP schreibt mir ja diese eine Zeile. Ich brauche also eine andere Schaltung um diesen kurzen Puls zu verlängern. Oder ich lass das mit diesem ESP. Boards anderer Hersteller scheinen ja weniger Ärger zu machen.
Gustl B. schrieb: > Ja, aber wie denn sonst? Ich brauche den doch um in den Download Modus > zu kommen? Wenn der Taster nur dazu dient, dann ist es Ok. >> wenn du diesen Pin versehentlich aus Ausgang konfigurierst, geht er auch >> noch kaputt! > Steht das im Datenblatt? Manche Dinge muss man wissen, ohne dass sie im Datenblatt stehen. Dazu gehört die Erkenntnis, dass ein Kurzschlusstrom in der regel weit über den Maximum Ratings ist, sofern das Gegenteil nicht ausdrücklich erwähnt wird. Wenn du dir da keine Sorgen machst, dann werfe mal eine Hand voll Schrauben in deinen laufenden PC. Ich denke, danach weist du Bescheid, was Kurzschlussfestigkeit angeht. > soc/rtc_cntl_reg.h Ich glaube, diese Datei ist Bestandteil des Espressif SDK. Aber da gibt es viele unterschiedliche Versionen und außerdem würde ich die Arduino Funktion nutzen, so weit es geht. Die machen vor dem Deep-Sleep sicher noch einige Vorbereitungen (z.B. Timer stoppen oder so), was nötig sein könnte. > Und dann gibt es ja noch diese blaue LED am ESP. Kann man die einfach > weglöten Ja
:
Bearbeitet durch User
Gustl B. schrieb: > So, Fehler gefunden, Lösung noch unbekannt. > Der Resetpuls von IO16 ist eher kurz Mach den Kondensator am Reset Pin weg. > Ich habe extern keinen Kondensator dran. Huch! Du hast in deinem Schaltplan aber einen drin (C7). Tue uns bitte einen Gefallen und diskutiere nicht über einen Plan, der nicht dem Aufbau entspricht. Probiere mal ein ESP-12F Modul, damit hatte ich noch keine Probleme.
:
Bearbeitet durch User
Hallo, ich hatte schon mehrere ESP8266-12E mit DeepSleep im Einsatz, einer davon über lange Zeit. Derartige Probleme hatte ich da nie. Am Modul generell 10k GPIO15-GND, Brücke GPIO16-Reset, EN über 10k an +Ub. Da einen 100mF Elko zwischen +Ub und GND am Modul. Ansonsten nur die Sensoren am I2C, BME280 im Forced Mode, dann schläft er sowieso von alleine wieder. Mit WAKE_RF_DISABLED hatte ich auch mal experimentiert, der reale Gewinn war mir aber dann den Aufwand nicht wert. Gruß aus Berlin Michael
Stefan ⛄ F. schrieb: > Huch! Du hast in deinem Schaltplan aber einen drin (C7). Tue uns bitte > einen Gefallen und diskutiere nicht über einen Plan, der nicht dem > Aufbau entspricht. Das steht schon im ersten Post, als erste Massnahme. Zeichnest du für jeden Test bei einer Fehlersuche erst einen neuen Schaltplan? Stefan ⛄ F. schrieb: > Wenn du dir da keine Sorgen machst, dann werfe mal eine Hand voll > Schrauben in deinen laufenden PC. Ver(störender) finde ich da solche abstrusen Vorschläge/Vergleiche. Und genau das Problem wird mit neueren ESP-12F in dem Issue genannt.
Stefan ⛄ F. schrieb: > Huch! Du hast in deinem Schaltplan aber einen drin (C7). Tue uns bitte > einen Gefallen und diskutiere nicht über einen Plan, der nicht dem > Aufbau entspricht. Dann lies doch mal welchen Wert C7 hat. Stefan ⛄ F. schrieb: > Mach den Kondensator am Reset Pin weg. Der externe Kondensator würde da mit 100 nF oder so kaum was ändern denn im ESP Modul ist ein 1 uF am Reset Pin. Den habe ich auch entfernt (C8). Ich sehe das jetzt als komisches Hardwareproblem von einem Modul das sehr schlecht designt ist. Guckt euch mal euren Resetpuls an mit dem Oszi. Der geht nicht mal soweit runter dass er das CMOS Low Level erreicht. Was der Hersteller da gemacht hat ist Pfusch. Ob das jetzt AI Thinker oder Espressif ist weiß ich aber nicht, vielleicht sind meine Module von Amazon auch keine Originale obwohl die recht original aussehen. Es könnte natürlich weiterhin auch ein Softwareproblem sein. Der ESP schreibt mir ja nach dem Aufwachen genau die selbe Zeile wie nach dem funktionierendem Reset mit Button. Auf Github in dem Thread hatte Jemand eine andere Deepsleep Funktion geschrieben die bei manchen Leuten das Problem gelöst hat. Bei mir leider nicht, ich bekomme da eine Bootloop. Ich gebe aber noch nicht ganz auf sondern werde mir einen schönen Resetpuls bauen. Irgendwie.
:
Bearbeitet durch User
Versuchs einfach mal mit der Firm/Hardware von einem der paar Tausend, wo es problemlos funktioniert.
Johannes S. schrieb: > Und genau das Problem wird mit neueren ESP-12F in dem Issue genannt. Welches Problem meinst du, das Aufwachen oder die kurzschlussfestigkeit? Wie wird es denn genannt, als gelöst oder noch offen?
Gustl B. schrieb: > Ich sehe das jetzt als komisches Hardwareproblem von einem Modul das > sehr schlecht designt ist. Guckt euch mal euren Resetpuls an mit dem > Oszi. Der geht nicht mal soweit runter dass er das CMOS Low Level > erreicht. Was der Hersteller da gemacht hat ist Pfusch. Das sehe ich auch so. Da ich damit noch keine Probleme hatte, wusste ich nicht einmal, dass der Pin überhaupt mit einem Modul-internen Kondensator beschaltet ist. Und dann auch noch so einen großen! Warum machen die das?
Ich wusste das auch nicht. Meine Vermutung ist, dass die das machen um was dem kurzen Resetpuls einen längeren Puls zu erzeugen. Das klappt ja auch, aber dann geht die Spannung nicht mehr weit runter und die Flanken sind nicht steil.
Ein externer Reset-Puls wird generell extern erzeugt und muß immer eine definierte Minimalbreite haben.
Nun, typischerweise wird GPIO16 verwendet für den Reset. ------------------------------------------------------------ Aber gut, es geht weiter: Ich habe jetzt an Reset einen schwachen Pullup. GPIO 16 ist nicht mit Reset verbunden weil ich mir das Signal an GPIO 16 mal getrennt angucken wollte. Der GPIO 16 ist erstmal Low. Sobald der ESP in den Tiefschlaf wechselt geht der GPIO 16 auf High. Wenn der Tiefschlaf vorbei ist wechselt der wieder auf Low. Ausserdem: Auch wenn der GPIO 16 nicht mit dem Reset verbunden ist schreibt mir der ESP nach der Tiefschlafzeit diese eine Zeile. Also irgendwie oder irgendwas im ESP wacht da auch komplett ohne Reset auf. Und dann gibt es ein weiteres Problem: Ich kann den also mauell resetten indem ich Reset mit einem Draht kurz mit Masse verbinde. Wenn ich das nach dem Tiefschlaf mache, dann funktioniert der manuelle Reset immer erst beim zweiten Versuch. Das sieht also so aus: - ESP wacht aus dem Tiefschlaf auf und schreibt mir diese eine Zeile, startet aber nicht das Programm. - Ich resette manuell und der ESP schreibt mir wieder nur eine Zeile. - Ich resette erneut manuell und erst dann startet das Programm. batman schrieb: > Versuchs einfach mal mit der Firm/Hardware von einem der paar Tausend, > wo es problemlos funktioniert. Firmwares habe ich noch keine probiert, davon habe ich keine Ahnung. Ich habe bisher nur in der Arduino IDE ein Board gewählt und diesen Code verwendet: ESP.deepSleep(10e6,WAKE_RF_DISABLED); delay(100);
Stefan ⛄ F. schrieb: > Da ich damit noch keine Probleme hatte, wusste ich > nicht einmal, dass der Pin überhaupt mit einem Modul-internen > Kondensator beschaltet ist. Und dann auch noch so einen großen! Warum > machen die das? Wir hatten hier mehrmals das Problem, daß die ESP an bestimmten Versorgungen nicht richtig starteten. Das lag am Ende nicht am Strom für den Funk, der läuft erst viel später an, sondern am Reset. Der Prozessor läuft schon los, wenn die Spannung eigentlich noch zu niedrig ist. Da gehört eigentlich ein Resetbaustein hin. Bevor es diese Bausteine gab, hat man gerne den Resetpuls über einen Kondensator verzögert, Resetbaustein für Arme. Ich vermute, dazu ist er da. Statt also den GPIO16 direkt mit Reset zu verbinden, sollte man dort einen Resetbaustein mit Reseteingang einbauen. Gustl B. schrieb: > Firmwares habe ich noch keine probiert, davon habe ich keine Ahnung. > Ich habe bisher nur in der Arduino IDE ein Board gewählt und diesen > Code verwendet: Was die Arduino IDE erzeugt, ist die Firmware. Gustl B. schrieb: > Es könnte natürlich weiterhin auch ein Softwareproblem sein. Der ESP > schreibt mir ja nach dem Aufwachen genau die selbe Zeile wie nach dem > funktionierendem Reset mit Button. Der ESP hat gar keinen Deepsleep. Er kann sich nur selbst ausschalten aber nicht wieder einschalten. Er hat aber einen Timer, der unabhängig läuft. Mit seinem Ausgang, den man auf GPIO16 legen kann, weckt er dann den ESP mit einem Reset wieder auf. Für den ESP ist das ein ganz gewöhnlicher Reset, daher die gleiche Meldung. MfG Klaus
Klaus schrieb: > Der Prozessor > läuft schon los, wenn die Spannung eigentlich noch zu niedrig ist. Na gut, das kann ich ausschließen, denn die ganze Zeit über liegt eine schöne Spannung an. Die bricht auch nicht ein. Also wenn der aus dem Tiefschlaf aufwacht und resettet dann ändert sich die Spannung am ESP Modul nicht oder nur minimal. Ich habe dazu ja extra diesen eher dicken DCDC verbaut und einen 100 uF Kerko an den VCC Anschluss des ESP Moduls gesetzt. Klaus schrieb: > Was die Arduino IDE erzeugt, ist die Firmware. OK, na dann erstelle ich also mit jeder Kompilation eine neue Firmware, fein. Klaus schrieb: > Für den ESP ist das ein ganz > gewöhnlicher Reset, daher die gleiche Meldung. Tja irgendwie ja nicht denn er wacht anders auf. Und nach dem Tiefschlaf funktioniert auch der erste manuelle Reset über den Taster nicht. Auch da schreibt mir der ESP dann diese eine Zeile, startet aber nicht mein Programm. Ohne Tiefschlaf funktioniert der Reset immer ohne Probleme. Aber wenn der ESP vorher im Tiefschlaf war, dann funktioniert der erste manuelle Reset nicht mehr. Ein zweiter manueller Reset aber schon. Ich vermute also irgendeinen Fehler in der Tiefschlaf Funktion. Aber ich habe weitergebastelt^^: Jetzt habe ich ein AND Gatter genommen und das extern an den Reset getan. Reset <= VCC AND GPIO16 Wenn der GPIO16 Low ist, ist Reset auch Low und zwar schön sauber auf Masse. Funktioniert aber trotzdem nicht. War aber auch zu erwarten, weil nach dem Tiefschlaf ja auch der erste manuelle Reset den ESP nicht korrekt startet und beim manuellen Reset über Taster wird Reset ja auch schön nach Masse gezogen. Ich bin jetzt der Meinung das ist ein Softwareding. In dem Github Thread hatte Jemand eine andere Tiefschlaf Funktion gepostet, ich verstehe die nicht, aber vielleicht versteht die ja hier Irgendwer. Bei manchen Usern auf Github hat die das Problem behoben, bei mir führt die Funktion zu einer Dauerbootschleife.
1 | #define ets_wdt_disable ((void (*)(void))0x400030f0) |
2 | #define ets_delay_us ((void (*)(int))0x40002ecc) |
3 | #define _R (uint32_t *)0x60000700 |
4 | void nk_deep_sleep(uint64_t time) |
5 | { |
6 | ets_wdt_disable(); |
7 | *(_R + 4) = 0; |
8 | *(_R + 17) = 4; |
9 | *(_R + 1) = *(_R + 7) + 5; |
10 | *(_R + 6) = 8; |
11 | *(_R + 2) = 1 << 20; |
12 | ets_delay_us(10); |
13 | *(_R + 39) = 0x11; |
14 | *(_R + 40) = 3; |
15 | *(_R) &= 0xFCF; |
16 | *(_R + 1) = *(_R + 7) + (45*(time >> 8)); |
17 | *(_R + 16) = 0x7F; |
18 | *(_R + 2) = 1 << 20; |
19 | __asm volatile ("waiti 0"); |
20 | } |
Hallo, Klaus schrieb: > Der ESP hat gar keinen Deepsleep. Er kann sich nur selbst ausschalten > aber nicht wieder einschalten. Er hat aber einen Timer, der unabhängig > läuft. Mit seinem Ausgang, den man auf GPIO16 legen kann, weckt er dann > den ESP mit einem Reset wieder auf. Für den ESP ist das ein ganz > gewöhnlicher Reset, daher die gleiche Meldung. naja, für die DeepSleep Geschichte muß ja Betriebsspannung anliegen bleiben. Der ESP8266 kann bei niedriger und (noch) instabiler Betriebsspannung in den Zustand kommen, daß er komplett hängenbleibt und dann gut 20mA und mehr verbraucht, Da kommt er auch nicht wieder raus. Reset ist eigentlich mit dem internen PullUp sehr zuverlässig, ein langsamer Anstieg der Spannung an Reset hat hier jedenfalls nie Fehlfunktionen ausgelöst. Ich habe DeepSleep schon mit diversen ESP8266 mal genutzt, vom -01 mit nachgerüsteter Brücke vom GPIO16, auch beim -03 und -07, es gab hier nie solche Probleme. GPIO manchmal per Schottkydiode mit Reset verbunden, um Kollisionen mit externem Taster oder der DTR/RTS-Logik zu vermeiden. Gruß aus Berlin Michael
Gustl B. schrieb: > #define ets_wdt_disable ((void (*)(void))0x400030f0) > #define ets_delay_us ((void (*)(int))0x40002ecc) das nimmt an das die Funktionen auf diesen Adressen liegen. Bei verschiedenen SDK Versionen können die sicher an verschiedenen Stellen liegen, so das es nur mit einer bestimmten Version funktioniert. Im Boardverwalter sollten sich andere Versionen auswählen lassen, also mal mit anderen probieren? Ich habe 2.4.1 installiert, da passen die Adressen, stehen in c:\Users\ich\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.4 .1\bootloaders\eboot\rom.ld
Johannes S. schrieb: > Ich habe 2.4.1 installiert, da passen die Adressen, Fein, du meinst von 2.4.1 von esp8266? c:\Users\ich\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.4 .1\bootloaders\eboot\rom.ld Gibt es bei mir nicht. Windows findet auf meinem Rechner keinen Ordner "ArduinoData". Ich habe die 2.7.2 installiert. Habe jetzt auch die rom.ld gefunden. Die Adressen passen, aber wie kann ich überprüfen ob auch #define _R (uint32_t *)0x60000700 stimmt?
Habe auch noch etwas gesucht, die Adressen sind fix im ROM, das sollte sich nicht ändern. Aber es muss ja einen Grund geben das der einfache delay nach Start zur Endlosschleife wird. Ja, meine 2.4.1 ist schon alt.
Gustl B. schrieb: > Firmwares habe ich noch keine probiert, Wie gesagt kannst du in der Arduino IDE im Boardmanager unterschiedliche Versionen der ESP8266 core laden, womit sich auch die Firmware Version ändert. Probiere den Core 2.3.0, der läuft gut.
Klaus schrieb: > Bevor es diese Bausteine gab, > hat man gerne den Resetpuls über einen Kondensator verzögert, > Resetbaustein für Arme. Ich vermute, dazu ist er da Ja, das wäre eine plausible Erklärung.
Gustl B. schrieb: > Die Adressen passen, aber wie kann ich überprüfen ob auch > > #define _R (uint32_t *)0x60000700 > > stimmt? Die Trickserei mit dem _R durchschaue ich nicht. Sieht jedenfalls sehr fragil aus.
Klaus schrieb: > Er hat aber einen Timer, der unabhängig > läuft. Mit seinem Ausgang, den man auf GPIO16 legen kann, weckt er dann > den ESP mit einem Reset wieder auf. Das ist fast richtig. Der Chip wacht auf ohne diese Verbindung von GPIO16 zu RESET auf, aber er macht dann nichts sinnvolles, verplempert nur Strom. Ich vermute, dass diese Verbindung ein Workaround für einen Fehler im Chip-Design ist. Eigentlich müsste es auch einen Sleep Modus geben, in dem das RAM erhalten bleibt und man ohne Neustart fortsetzen kann.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Der Chip wacht auf ohne diese Verbindung von > GPIO16 zu RESET auf, aber er macht dann nichts sinnvolles, verplempert > nur Strom. Danke! Ja genau so ist das auch, aber mit Eigenheiten. Der wacht auch ohne die Verbindung auf und gibt sogar diese eine Zeile über UART aus. Aber selbst mit Verbindung und korrektem Reset wacht der nach dem Tiefschlaf ebenfalls zuerst nicht richtig auf. Zumindest bei meiner Software. Stefan ⛄ F. schrieb: > Wie gesagt kannst du in der Arduino IDE im Boardmanager unterschiedliche > Versionen der ESP8266 core laden, womit sich auch die Firmware Version > ändert. Probiere den Core 2.3.0, der läuft gut. Ah, das meinst du mit verschiedenen Firmwares. Ich dachte da gäbe es mehrere verschiedene ESP8266 Bibliotheken, aber da finde ich nur die eine. Welches Board sollte ich denn auswählen? Bisher verwende ich das NodeMCU 1.0. Jetzt wollte jetzt 2.3.0 installieren und bekomme java.lang.NullPointerException Was ist das denn für ein kaputtes Ökosystem? Da verwendet man das ein paar Tage und schon zerbröselt es förmlich ...
Gustl B. schrieb: > Ich dachte da gäbe es > mehrere verschiedene ESP8266 Bibliotheken Ja eben, die sind in dem Arduino Core drin. > Jetzt wollte jetzt 2.3.0 installieren und bekomme > java.lang.NullPointerException Probiere zuerst den ESP8266 Core zu deinstallieren und dann wieder zu installieren. Wenn das auch nicht klappt, installiere die ganze Arduino IDE neu oder downloade beide zusammenhängend als "portable" Version von meiner Homepage: http://stefanfrings.de/esp8266/index.html#arduinostart
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Probiere zuerst den ESP8266 Core zu deinstallieren und dann wieder zu > installieren. Hat funktioniert. Jetzt funktioniert mit der 2.3.0 void setup() { Serial.begin(74880); Serial.println("Start!"); } nicht mehr. Also ganz ohne Tiefschlaf. Nach einem Reset bekomme ich
1 | ets Jan 8 2013,rst cause:2, boot mode:(3,6) |
2 | |
3 | load 0x4010f000, len 1384, room 16 |
4 | tail 8 |
5 | chksum 0x2d |
6 | csum 0x2d |
7 | v6000001c |
8 | ~ld |
9 | ⸮*]X⸮⸮! |
Also sieht nach falscher Baudrate aus, habe aber genau die passende eingestellt. Naja egal. Welches Board sollte ich denn in der IDE auwählen wenn ich den ESP-12S verwende?
:
Bearbeitet durch User
Schrott-Meldungen nach einem Reset können passieren, wenn der Zugriff auf den Flash zu schnell ist. Probiere mal als Board einen "ESP8266 generic", dann als Flash Frequency "40 MHz" und den Modus "DIO". Damit laufen die meisten Module gut. Siehe http://stefanfrings.de/esp8266/index.html#flash Und nochmal http://stefanfrings.de/esp8266/index.html#arduinostart
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Ich vermute, dass diese Verbindung ein Workaround für einen Fehler im > Chip-Design ist. Das klingt zusammen mit einigen anderen Aussagen, die ich gelesen habe, plausibel. MfG Klaus
Stefan ⛄ F. schrieb: > Und nochmal http://stefanfrings.de/esp8266/index.html#arduinostart Danke. Hatte ich schon gelesen, aber ich hatte eher gehofft, dass ich irgendwo ein ESP-12S Board finde. > Reset Method: NodeMCU, spielt keine Rolle wenn die > Reset+Flash Tasten manuell drückt Was bewirken denn die unterschiedlichen Einstellungsmöglichkeiten? Klaus schrieb: > Das klingt zusammen mit einigen anderen Aussagen, die ich gelesen habe, > plausibel. Gibt es dann auch bugfreie ESP Boards? Wie sind die Boards/Module von Espressif selbst? Können die auch alle mit der Arduino IDE verwendet werden oder ist diese Kompatibilität zur Arduino IDE eine Leistung der OpenSource Gemeinschaft? Ich meine, wenn Espressif das nicht selber macht, dann muss sich Jemand finden oder auch nicht und es ist nicht sicher dass alle Espressif Module mit der Arduino IDE verwendet werden können. --------------------------------- Der ESP kann sich selbst resetten und auch korrekt starten. Und zwar wenn ich in der Arduino IDE ein Programm/Firmware aufspiele kann der danach automatisch neu starten und das Programm ausführen. Geht wunderbar. Es sind dazu keine Buttons nötig. Dann sollte der nach dem Tiefschlaf auch korrekt starten können. Das wird immer mehr zu einem Softwareding.
Gustl B. schrieb: > Was bewirken denn die unterschiedlichen Einstellungsmöglichkeiten? Lies doch einfach die Webseite. Die Nodemcu Reset Methode ist dort beschrieben. Die andere kenne ich nicht.
Gustl B. schrieb: > Gibt es dann auch bugfreie ESP Boards? Wahrscheinlich nicht. Das Hauptproblem ist die Software. Die ist so komplex und eilig zusammen gestrickt, dass sie wohl nie wirklich fertig wird. Die ESP-12F Module von AI-Tinker haben allerdings einen guten Ruf. > Wie sind die Boards/Module von Espressif selbst? Brauchbar. Die haben sich aber dem ESP32 zugewendet. Im ESP8266 Bereich ist nichts großartiges mehr zu erwarten. > Ich meine, wenn Espressif das nicht selber > macht, dann muss sich Jemand finden Tue dir keinen Zwang an, fange an! Beklage dich nicht, dass die Hobbyentwickler nicht alle Module kennen und unterstützen. Das ist doch ein Fass ohne Boden! Dabei gibt es das "generische ESP8266 Board", damit laufen alle. Man muss die Parameter nur passend einstellen. Die ganzen Boards unterscheiden sich (in Arduino) nur in den Parametern. Du kannst die boards.txt selbst erweitern.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Die andere kenne ich nicht. OK. > We recommend that you use CHIP_EN, instead of EXT_RSTB, to reset the chip. Aha, das empfiehlt Espressif. Also sollte ich doch eine ordentliche Resetschaltung bauen die sich an die Vorgaben hält. Wobei Espressif auch vorschlägt IO16 mit Reset zu verbinden um aus dem Tiefschlaf aufzuwachen. Stefan ⛄ F. schrieb: > Tue dir keinen Zwang an, fange an! Tja da bin ich noch Anfänger, ich liefere da ungerne schlechten Code ab. Andere Sachen gebe ich gerne weiter, aber ja, vielleicht sollte ich mir mal einen Github Account klicken ... Stefan ⛄ F. schrieb: > Die ESP-12F Module von AI-Tinker haben allerdings einen guten Ruf. Sehr fein. Stefan ⛄ F. schrieb: > Die ganzen Boards unterscheiden sich (in Arduino) nur in den Parametern. Ah OK. Na dann ... Zusätzlich zu der Arduino IDE gibt es noch die Software von Espressiv selbst. Ich habe eine Empfehlung für diese Tiefschlaffunktion bekommen: esp_sleep_enable_timer_wakeup(time); esp_deep_sleep_start(); Was muss ich machen um diese Funktionen (vermutlich nativ aus der Espressif Software) in der Arduino IDE nutzen zu können?
:
Bearbeitet durch User
Gustl B. schrieb: >> We recommend that you use CHIP_EN, instead of EXT_RSTB, to reset the chip. > Aha, das empfiehlt Espressif. Vorsicht, wenn die Software abschmiert hilft oft nur ein richtige Reset. Der Enable Eingang reagiert dann nicht mehr. Gustl B. schrieb: > Was muss ich machen um diese Funktionen (vermutlich nativ aus der > Espressif Software) in der Arduino IDE nutzen zu können? Ich habe weiter oben bereits davon abgeraten. Programmiere bei bestehenden Funktionen nicht am Framework vorbei - es sei denn, die hast Lust auf ganz schwierige Probleme.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Lust auf ganz schwierige Probleme. Ja naja, wenn die Funktion vom Framework mein Problem nicht löst würde ich das gerne trotzdem anders versuchen. Ich bin jetzt alle Versionen vom ESP8266 Framework durch und das waren nicht wenige. Edit: Kann es sein, dass es die Funktionen esp_sleep_enable_timer_wakeup(time); esp_deep_sleep_start(); für den ESP8266 nicht gibt sondern nur für den ESP32?
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Ich vermute, dass diese Verbindung ein Workaround für einen Fehler im > Chip-Design ist. Gustl B. schrieb: > Gibt es dann auch bugfreie ESP Boards? Wenn es ein Problem im Chip ist, wie soll ein Board das besser machen? Auf den Modulen ist doch eigentlich nichts drauf. Da ist der ESP und das serielle Flash. Da der ESP aus seinem ROM daraus bootet, muß das Flash exakt so angeschlossen werden, wie es ist. Dazu ein paar Pullups, Pulldowns, Stützkondensatoren und ne Leiterbahn als Antenne. Je nach Modul ESP01 bis ESP12 werden mehr oder auch alle GPIOs rausgeführt. Inzwischen haben auch die ESP01 meisst größere FLASH, kosten ja fast nix. Alles andere ist nicht essentiell, weder ein Spannungsregler noch ein USB-UART. Das kann man auch extern anschließen. Ich packe ESP01, wenns steckbar sein soll, ESP07 mit externer Antenne oder ESP12 auf meine eigenen Platinen und benutze für alle die gleiche Basissoftware. Deepsleep nutze ich gar nicht, Wifi und Lowpower passen für mich nicht zusammen. Für mich sind die ESP Ersatz für Ethernet, billiger als ein Magjack plus Kabel. Die Diskussion um die Boards kommt mir vor wie ein Streit welcher Jahrgang eines Weins der bessere ist. MfG Klaus
Klaus schrieb: > Die Diskussion um die Boards kommt mir vor wie ein Streit welcher > Jahrgang eines Weins der bessere ist. Naja manche ESP Module sind ja schon länger am Markt und andere noch nicht so lange. Da könnte es durchaus bugbereinigte Versionen vom gleichen Chip geben.
Hallo, Gustl B. schrieb: > Klaus schrieb: >> Die Diskussion um die Boards kommt mir vor wie ein Streit welcher >> Jahrgang eines Weins der bessere ist. > > Naja manche ESP Module sind ja schon länger am Markt und andere noch > nicht so lange. Da könnte es durchaus bugbereinigte Versionen vom > gleichen Chip geben. wenn man lange zurück sucht findet man bei Espressif was zum WakeUp/GPIO16 Problem. Es ist ein Designfehler des ESP8266, mir ist nicht bekannt, daß der jemals behoben wurde oder werden sollte. In der ArduinoID bzw. in den neueren SDK Versionen gibt es auch ein problem mit WAKE_RF_DISABLED, das ging irgendwann nicht mehr bzw. nicht mehr richtig. Da habe ich nicht verfolgt, ob es irgendwann wieder repariert wurde. Aber das findet man ja problemlos raus, indem man eben mal WAKE_RF_DEFAULT setzt. Ich habe jetzt auf Anhieb nur diesen Thread aus der Zeit gefunden: https://www.esp8266.com/viewtopic.php?f=33&t=16949 Ich habe das seit damals (könnte so 2018 gewesen sein) nicht mehr weiter verfolgt. Gruß aus Berlin Michael
:
Bearbeitet durch User
Wo ist jetzt der Zusammenhang? Hängts von der WAKE_..-Option ab?
Ne, auch ohne Option ist das Problem gleich. Aber gut, Designfehler. Tja ... dann werde ich wohl einen anderen ESP verwenden ...
In dem langen Thread auf GitHub hatte ja auch jemand geschrieben das es am Flash liegt und der Fehler nach Austausch weg war. Das ist wohl auch ein bekanntes Problem und in den generischen ESP wurde eingebaut das der bis 20 MHz runter getaktet werden kann.
Tja irgendwie hat jeder Lösungsvorschlag irgendjemandem geholfen. Das mit dem Flash hatte ich aber noch nicht probiert, vielen Dank! Aus dem Code oben wäre noch interessant wie man den Wert, also vermutlich eine Start Adressen von _R herausfindet.
Gustl B. schrieb: > Aus dem Code oben wäre noch interessant wie man den Wert, also > vermutlich eine Start Adressen von _R herausfindet. das müssten irgendwelche Register der RTC sein, muss man aus den .ld files rausfinden. Und die RTC Struktur für die Felder die da gesetzt werden. Die Adressen dürften doch festgenagelt sein, meine Vermutung das die sich mit der Firmware ändern ziehe ich zurück. Wenn ich jetzt richtig verstehe hat der ESP ein Bootrom und das ist schon lange unverändert. Und es scheint ja mehrere Ursachen für das Problem zu geben: 1) Firmwarefehler in älterer Version mit dem Wakeup Mode, aber schon länger gefixt 2) Bei einigen WeMos ist eine Automatik mit Transistoren drauf die nicht richtig kompatibel ist 3) schlechte (zu langsame) Flash Speicher. 4) das übliche Power Problem. Wobei da ja bekannt ist das der ESP durstig ist.
Das hier ist noch interessant bzgl Boot Prozess: https://richard.burtons.org/2015/05/17/esp8266-boot-process/ Und sein folgender Blog mit GitHub Link.
Johannes S. schrieb: > 1) Firmwarefehler in älterer Version mit dem Wakeup Mode, aber schon > länger gefixt Also was meinst du mit Firmware? Das was ich über die Arduino IDE hochlade oder das was dauerhaft in dem Baustein bleibt? Johannes S. schrieb: > 3) schlechte (zu langsame) Flash Speicher. Ich habe jetzt mal mit geringererem Flash Takt versucht, aber auch das bringt nix. Johannes S. schrieb: > 4) das übliche Power Problem. Wobei da ja bekannt ist das der ESP > durstig ist. Gut, das kann ich ausschließen. Wenn ich den Resetpuls nach dem Tiefschlaf anlege bootet der nicht korrekt, bei einem zweiten Resetpuls nach dem Tiefschlaf aber immer korrekt. Ausserdem habe ich da einen DCDC der große Ströme kann und auch noch dicke Kondensatoren. Die Versorgungsspannung bricht laut Oszilloskop nicht ein, also ein paar wenige mV, aber nur sehr greing.
Gustl B. schrieb: > Also was meinst du mit Firmware? Das was ich über die Arduino IDE > hochlade oder das was dauerhaft in dem Baustein bleibt? Nochmal: Die Arduino IDE erzeugt eine Firmware. Diese basiert auf einer bestimmten Version des SDK von Espressif, welches wiederum einen wesentlichen Teil in Binärform ohne Quelltext enthält. Dein Arduino Sketch ist die Firmware. Oder nur der Teil von Espressif - je nach Sichtweise. Wenn du die Version des Arduino Cores änderst, änderst du damit auch die Version des Teils, den Espressif dazu beigesteuert hat. Und dann gibt es da noch den Bootloader, der ist fest im Chip drin und nicht veränderbar. Der Bootloader überträgt die Firmware vom seriellen Port in den Flash Speicher.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Oder nur der Teil von Espressif - > je nach Sichtweise. Genau darum geht es mir. Bei einem Android Handy z. B. könnte man das Android das man da "flasht" auch als "Firmware" bezeichnen und macht das wohl manchmal auch. Aber da ist dann noch viel weitere Software im Gerät wie der Bootloader, das Recovery, das Baseband, ... Firmware ist normalerweis als die Software definiert, die zur Hardware gehört. Die vom Hersteller aufgespielt wird und vom Benutzer nicht verändert werden kann. Beim ESP würde ich also den Bootloader oder wie auch immer man das dennt, als Firmware bezeichnen. Stefan ⛄ F. schrieb: > Nochmal: Die Arduino IDE erzeugt eine Firmware. OK, wenn hier diese Definition gemeint ist, dann ist das Bootproblem definitiv nicht für alle ESP8266 behoben.
Gustl B. schrieb: > Firmware ist normalerweis als die Software definiert, die zur Hardware > gehört. Die vom Hersteller aufgespielt wird und vom Benutzer nicht > verändert werden kann Als Softwareentwickler bist du der Hersteller. Dein Programm ist die Firmware. Wenn du mit Arduino Arbeitest, hast du Bootloader + Firmware. Die Firmware erzeugt die Arduino IDE. Deine Sichtweise, dass oben drauf noch Anwendungsprogramme laufen passt eher zur NodeMCU Firmware. Die installiert man tatsächlich nur einmal und lädt dann zusätzlich eigene austauschbare LUA Scripte hoch.
:
Bearbeitet durch User
OK, Verstanden. Nun, ESP-12E und ESP-12F sind kompatibel (Abmaße und Belegung) zum ESP-12S. Glaubt ihr bei denen funktioniert der Tiefschlaf oder sollte ich zum ESP32 wechseln?
Gustl B. schrieb: > Glaubt ihr bei denen funktioniert der Tiefschlaf Bei meinen funktioniert er anstandslos.
Der Deep Sleep Betriebszustand hat ein paar Begleitumstaende, um den ueberhaupt zu ermoeglichen. Es geht darum extrem wenig Power zu verbrauchen. Daher sollten alle unbeschalteten Eingaenge auf Ausgang geschaltet werden. Wenn man die Wahl eines Pullup oder Pulldown am Eingang hat, welcher verbraucht weniger Strom ? Ein Spannungteiler von 1MOhm zieht auch schon 3uA... Was geschieht mit der Peripherie ? Die sollte sinnvollerweise auch in einen Stromsparzustand gehen. Und das waere dann der eigensichere Zustand. Also eben nicht - Heizung Ein, Vollgas oder Dergleichen. Als Anfaenger, in einem Lernprojekt ... das Datenblatt genau in jedem Abschnitt lesen.
Joggel E. schrieb: > Daher sollten alle unbeschalteten Eingaenge auf Ausgang > geschaltet werden. Ich habe das mit dem Ardino Core 2.3.0 überprüft und musste feststellen, dass definierte Pegel an den Pins durch externe Beschaltung oder Programmierung überhaupt keinen Unterschied machen. Man kann sie alle unbeschaltet und als Eingang belassen. Offenbar sorgt entweder Arduino oder die Firmware-Teile von Espressif schon dafür, dass die Pins sauber still gelegt werden.
:
Bearbeitet durch User
So, ESP-12F funktioniert, aber: Mit ESP.deepSleep(zeit_ms); delay(100); funktioniert der Tiefschlaf nicht, also so wie bei meinem ESP-12S. Mit der oben geposteten Funktion nk_deep_sleep(zeit_us); funktioniert der Tiefschlaf, aber zu beachten ist, dass die Funktion den Chip sofort schlafen legt. Wenn man also Serial.println("Text"); nk_deep_sleep(zeit_us); macht, dann wird die serielle Übertragung nicht vollständig durchgeführt, es kommen nur wenige Bits des ersten Bytes aus dem ESP und dann geht der schon schlafen. Das hielt ich beim ESP-12S für einen Fehler, jetzt am ESP-12F konnte ich das mit einem Delay dazwischen lösen. Also vielleicht geht Tiefschlaf mit nk_deep_sleep(zeit_us); auch beim ESP-12S. Habe ich jetzt noch nicht mit Delay getestet weil ich jetzt den ESP-12F bestückt habe. Jedenfalls bin ich jetzt zufrieden. Edit: Nein, bin nicht zufrieden ... der zieht im Tiefschlaf fast 3 mA. Habe alle Pullups/Pulldowns auf >100 kOhm und der DCDC zieht ohne Last 400 uA. Man man man ... mal gucken wo da der Strom fließt.
:
Bearbeitet durch User
Gustl B. schrieb: > mit > ESP.deepSleep(zeit_ms); > funktioniert der Tiefschlaf nicht Es sind Mikrosekunden, nicht Millisekunden. Den Fehler habe ich auch mal gemacht. > Wenn man also > Serial.println("Text"); > nk_deep_sleep(zeit_us); > macht, dann wird die serielle Übertragung nicht vollständig > durchgeführt Logisch, die findet ja Asynchron aus einem Puffer heraus statt.
:
Bearbeitet durch User
Hallo, bei mir waren es einige ESP-01s die die Fehlstarts nach einem deep sleep hatten. Nach einem Austausch des Flash-Bausteins traten keine Fehlstarts mehr auf. Eingebaut waren: Noname T25S80 PQ19P1 (1M) eingebaut wurden: Winbond 25Q32FVSIG (4M)
Bitte 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.