Today it goes into the sleep laboratory. We put the ESP32/ESP8266 to rest, which helps save electricity in battery operation. In addition, the RTC module of the Micropython kernel and the DS1302 also offer the opportunity to store data that survive a restart. Usually, all variables and objects are gone when the controller restarts. How they can be preserved and which sleep modes and revival options ESP8266 and ESP32 offer, you will find out in
Micropython on the ESP32 and ESP8266
today
Sleeping Beauty sleep
We won't send our ESPs to hibernation for 100 years and we won't be kisses awake either. We prefer to leave that to the RTC. With the ESP32 we can also crawl some legs and if there is a level change, this can also lead to the controller waking up. In any case, he makes a restart and everything that was in the RAM has emigrated to nirvana. Everything, except for the data in the RTC RAM and the RTC itself. What do we need for the experiments?
Hardware
1 |
ESP32 Dev Kit C V4 unplacerated or |
1 |
Nodemcu Lua Amica Module V2 ESP8266 ESP-12F WiFi or |
1 |
|
1 |
|
1 |
|
1 |
DS1302 Serial Real Time Clock RTC real-time clock Clock module |
The software
For flashing and the programming of the ESP32:
Thonny or
Used firmware for the ESP8266:
Used firmware for the ESP32:
The micropython programs for the project:
ds1302.py Hardware driver for the DS1302
SSD1306.PY Hardware driver for the OLED display
oled.py API for the OLED display
DS1302 Set+Get.PY Program for the watch comparison NTP-RTC-DS1302
rtc set+get.py Program for the watch comparison NTP-RTC
wake_on_gpio.py Deep sleep and awakening by changing the level
deep sleep_demo.py Deep sleep and awakening by timer
Sleep types.py Possibilities for saving electricity
Sleep+Wachen.Py Test program for electricity savings on ESP8266 and ESP32
Micropython - Language - Modules and Programs
To install Thonny you will find one here Detailed instructions (English version). There is also a description of how the Micropython firmware (As of 18.06.2022) on the ESP chip burned becomes.
Micropython is an interpreter language. The main difference to the Arduino IDE, where you always flash entire programs, is that you only have to flash the Micropython firmware once on the ESP32 so that the controller understands Micropython instructions. You can use Thonny, µpycraft, or ESPTOOL.PY. For Thonny I have the process here described.
As soon as the firmware has flashed, you can easily talk to your controller in a dialogue, test individual commands and see the answer immediately without having to compile and transmit an entire program beforehand. That is exactly what bothers me about the Arduino IDE. You simply save an enormous time if you can check simple tests of the syntax and hardware to try out and refine functions and entire program parts via the command line before knitting a program from it. For this purpose, I always like to create small test programs. As a kind of macro, they summarize recurring commands. Whole applications then develop from such program fragments.
Autostart
If the program is to start autonomously by switching on the controller, copy the program text into a newly created blank tile. Save this file under boot.py in WorkSpace and upload it to the ESP chip. The program starts automatically the next time the reset or switching is on.
Test programs
Programs from the current editor window in the Thonny-IDE are started manually via the F5 button. This can be done faster than the mouse click on the start button, or via the menu run. Only the modules used in the program must be in the flash of the ESP32.
In between, Arduino id again?
Should you later use the controller together with the Arduino IDE, just flash the program in the usual way. However, the ESP32/ESP8266 then forgot that it has ever spoken Micropython. Conversely, any espressif chip that contains a compiled program from the Arduino IDE or AT-Firmware or Lua or ... can be easily provided with the Micropython firmware. The process is always here described.
The circuits
Image 1: ESP8266 - circuit
So that the ESP8266 can wake up, you have to connect the PIN GPIO16 = D0 to the RST connection. With the button module, I give the ESP8266 a flash key because the poor guy itself has no one on board.
An ESP32 doesn't need all of this. Nevertheless, he also gets a button from me so that he doesn't cry and above all so that I can tease it up.
Image 2: ESP32 - circuit
The controller goes to sleep
Well then good night!
This can be said if you have not kept it open to wake up the guy again, for example, to upload changes to the program. Because the ESP32/ESP8266 must of course be wide awake. We are looking at which sleep modes are available and, above all, what revival methods are available.
First of all, it is striking that the kernel for ESP8266 and ESP32 have different features. Thonny's object inspector explains. You can use the menu View - Object Inspector start.
Image 3: The ESP8266 Machine module
Image 4: The ESP32 Machine module
ESP8266
Deep sleep and reset
Let's slowly approach the matter. In interactive mode, i.e. via Repl, I put some commands off. I import some classes and functions, declare the tufle rtctag, and instantiate the object RTC.
>>> From machine import RTC, Deepsleep, reset_cause, reset
>>> rtctag=(2022,11,27,8,10,20,0,0)
>>> RTC=RTC()
>>> rtctag
(2022, 11, 27, 8, 10, 20, 0, 0)
The function reset_cause() As a reason for a reset, provides a number code according to the following Table 1.
ESP8266 |
|
|
Pwron_reset |
0 |
after turning on |
Wdt_reset |
1 |
According to the response of the Cerberus (= Watchdog aka Wachhund) |
Soft_reset |
4 |
After calling the Machine.Reset function () |
Deepsleep_reset |
5 |
After awakening from deep sleep |
Hard_reset |
6 |
After pressing the RST key |
Table 1: Reset codes
Immediately after switching on, we get a 0 at the ESP8266. After a soft reset, a 4.
>>> From machine import RTC, Deepsleep, reset_cause, reset
>>> reset()
….
>>> reset_cause()
4
>>> rtctag
Traceback (custody recent call load):
File "" , line 1, in <modules>
Name: Surname 'rtctag' isn't defined
With a hard reset like a soft reset, the data from the RAM disappeared and migrated to nirvana. So I had to import again.
Now plug a jumper wire from D0 = GPIO16 to the PIN RST on the Breadboard, as shown in Figure 1 above.
Now we send the ESP8266 to sleep for 5 seconds. If no time is handed over, the controller sleeps to St. Nimmerleinstag and can only be teased awake through the RST button.
>>> Deepsleep(5000)
…….
Micropython V1.19.1 on 2022-06-18; ESP modules wither ESP8266
Type "Help ()" for more information.
>>> reset_cause()
Traceback (custody recent call load):
File "" , line 1, in <modules>
Name: Surname 'reset_cause' isn't defined
The controller also forgot after awakening from deep sleep what we had imported on tools. So again from the front. This time we still put the RTC and convince ourselves whether it is ticking.
>>> From machine import RTC, Deepsleep, reset_cause, reset
>>> rtctag=(2022,11,27,0,8,10,20,0)
>>> RTC=RTC()
>>> RTC.DateTime(rtctag)
>>> RTC.DateTime()
(2022, 11, 27, 6, 8, 10, 31, 367)
>>> Deepsleep()
…….
Micropython V1.19.1 on 2022-06-18; ESP modules wither ESP8266
Type "Help ()" for more information.
>>> From machine import RTC, Deepsleep, reset_cause, reset
>>> reset_cause()
5
>>> RTC=RTC()
>>> RTC.DateTime()
(2022, 11, 27, 6, 8, 12, 15, 959)
Aha! After awakening from deep sleep, the controller can remember the time, he even continued the count of seconds. The situation is similar to a bytes object that can be written in the RTC memory. The ESP8266 can be around 500 bytes, and the ESP32 2000.
>>> RTC.memory(B "12345 this is a test!")
>>> RTC.memory()
B'12345 that's a test! '
>>> Deepsleep()
…….
Micropython V1.19.1 on 2022-06-18; ESP modules wither ESP8266
Type "Help ()" for more information.
>>> From machine import RTC, Deepsleep, reset_cause, reset
>>> RTC=RTC()
>>> RTC.memory()
B'12345 that's a test! '
This also works after a soft reset.
>>> reset()
…….
Micropython V1.19.1 on 2022-06-18; ESP modules wither ESP8266
Type "Help ()" for more information.
>>> From machine import RTC, Deepsleep, reset_cause, reset
>>> RTC=RTC()
>>> RTC.memory()
B'12345 that's a test! '
>>> reset_cause()
4
And even after a hard reset (RST key), the data is still there.
And even after a Hard-Reset (RST-button) are the Data still there.
>>> From machine import RTC, Deepsleep, reset_cause, reset
>>> RTC=RTC()
>>> RTC.memory()
B'12345 that's a test! '
>>> reset_cause()
6
>>> RTC.DateTime()
(2022, 11, 27, 6, 8, 20, 9, 603)
However, the RTC module is also deleted after a power failure, there is no buffer battery. So if you want to secure data in the switch-off state, then there are only two ways: either in a file in the flash memory of the controller, in the buffered RAM of a DS1302, or in a corresponding component.
Easy sleep
After the easy sleep, the ESP8266 can still remember the previously carried out value assignments of variables, of course also of the content of the RTC RAM storage.
>>> From machine import RTC, reset_cause, Lightsleep
>>> RTC=RTC()
>>> sleep=5000
>>> RTC.memory(B "1234 this is a test")
>>> Lightsleep(3000)
>>> RTC.memory()
B'1234 This is a test '
>>> sleep
5000
If we translate these commands into a program, we will find that this is continued in the line, which on the call of Lightsleep() follows.
While a current of 78 mA now flows in normal mode, it is reduced to values between 25 mA and 35 mA in Lightsleep mode. The current strength goes back to 3.3 mA in Deepsleep mode.
The RTC area is therefore always protected against data loss, provided the ESP8266 is supplied with sufficient voltage. The objects in normal RAM are only preserved in Lightsleep mode. When the board is switched off, the data is only preserved in an external battery-buffered RAM, as in the DS1302, or in a file in the flash of the controller block.
If the program is to be continued at the point after the sleep command, only the Lightsleep mode is suitable. A cold start is practically in Deep-sleep mode, in which the main program is started from the start.
With Sleep+Wachen.Py I made a program that can be used on the ESP8266, but it also runs on the ESP32 and helps to examine the various features of both systems.
# Sleep+Wachen.PY
#
From machine import reset_cause,\
Deepsleep, Lightsleep, \
sleep, Softi2c, Pin code
import sys
From OLED import OLED
port=sys.platform
lifetime=5000
sleep=5000
button=Pin code(0,Pin code.IN,Pin code.Pull_up)
wakepin=Pin code(14)
IF port == "ESP8266":
I2C=Softi2c(scl=Pin code(5),sda=Pin code(4))
ground={
0:"Poweron Reset",
1:"Watchdog Reset",
2:"???",
4:"Soft Reset",
5:"Deepsleep Reset",
6:"Hard Reset",
}
RC=reset_cause()
elif port == "ESP32":
I2C=Softi2c(scl=Pin code(22),sda=Pin code(21))
From machine import wake_reason
import ESP32
ESP32.wake_on_ext0(wakepin,ESP32.Wakeup_all_low)
ground={
1:"Poweron Reset",
2:"Ext0 Wake",
3:"Ext1 Wake",
4:"Deepsleep Reset",
5:"Touch Wake",
6:"Ulp Wake",
}
RC=wake_reason()
Else:
raise Runtime("Unknown Port")
print("Restarted by:",RC,ground[RC])
D=OLED(I2C,Heightw=64) # 128x32 pixel display
D.clearall()
D.writer("Restart through",0,0)
D.writer("{}".format(RC),0,1)
D.writer(ground[RC],0,2)
sleep(3000)
print(port, "walks into",lifetime,"MS sleep")
D.clearall()
D.writer("I'M AWAKE",0,0)
D.writer("for".format(RC),0,1)
D.writer("{} ms".format(lifetime),0,2)
sleep(lifetime)
IF button.value() == 0:
D.clearall()
D.writer("PROGRAM",0,0)
D.writer("COMPLETED",0,1)
sys.exit()
print(port, "Schlaeft now",sleep,"MS")
D.clearall()
D.writer("I AM SLEEPING",0,0)
D.writer("Now for".format(RC),0,1)
D.writer("{} ms".format(sleep),0,2)
# Lightsleep (Sleeptime)
Deepsleep(sleep)
IF port == "ESP8266":
RC=reset_cause()
Else:
RC=wake_reason()
print(port, "I woke up",sleep,"MS")
D.clearall()
D.writer("WOKE UP",0,0)
D.writer("THROUGH {}".format(RC),0,1)
D.writer(ground[RC],0,2)
In order for electricity measurements to be carried out, the ESP8266 board must be separated from the USB bus and supplied from its own source of voltage. To get feedback, I used an OLED display.
After importing some classes and functions, I declare a few variables and objects. The backslash allows me to extend the list over several lines.
From machine import reset_cause,\
Deepsleep, Lightsleep, \
sleep, Softi2c, Pin code
import sys
From OLED import OLED
port=sys.platform
The string constant sys.platform says which controller I have.
lifetime=5000
sleep=5000
Two variables for the wax and sleep phase
button=Pin code(0,Pin code.IN,Pin code.Pull_up)
With the flash button on GPIO0, I can cancel the program so that I don't get into the sleep phase if I want to upload program changes. With the combination Ctrl+C, It's not always that easy.
wakepin=Pin code(14)
For the ESP32 I define a PIN object with which I want to wake up the controller. This feature does not exist with the ESP8266. You could only use the RST key.
Depending on the port, I then carry out further actions.
IF port == "ESP8266":
I2C=Softi2c(scl=Pin code(5),sda=Pin code(4))
ground={
0:"Poweron Reset",
1:"Watchdog Reset",
2:"???",
4:"Soft Reset",
5:"Deepsleep Reset",
6:"Hard Reset",
}
RC=reset_cause()
There is not much to do with the ESP8266. The right i2C pins must be defined and the dictionary for the plain text of the Reset Ground must be declared. The function reset_cause () reveals the reason for the last reset. In Table 1 you will find an overview.
elif port == "ESP32":
I2C=Softi2c(scl=Pin code(22),sda=Pin code(21))
From machine import wake_reason
import ESP32
ESP32.wake_on_ext0(wakepin,ESP32.Wakeup_all_low)
ground={
1:"Poweron Reset",
2:"Ext0 Wake",
3:"Ext1 Wake",
4:"Deepsleep Reset",
5:"Touch Wake",
6:"Ulp Wake",
}
RC=wake_reason()
Else:
raise Runtime("Unknown Port")
For the ESP32 DITO, also two more imports, as well as the call of wake_on_ext0 (), to end the sleep mode by pressing a button on GPIO14. As you can see, there is a different assignment of the wake or reset events than the ESP8266. For the query of the reason, the function is the function of the ESP32 wake_reason() responsible. If it is not an ESP32 or ESP8266 board (PY board etc.), the program throws an exception.
print("Restarted by:",RC,ground[RC])
D=OLED(I2C,Heightw=64) # 128x32 pixel display
D.clearall()
D.writer("Restart through",0,0)
D.writer("{}".format(RC),0,1)
D.writer(ground[RC],0,2)
sleep(3000)
The following block provides information about the restart and its background in the terminal window and on the OLED display. The function is remarkable sleep(). Because she doesn't live in the module time, but in a machine. The delay is also not specified in seconds but in milliseconds. To do this, also compare Images 3 and 4.
print(port, "walks into",lifetime,"MS sleep")
D.clearall()
D.writer("I'M AWAKE",0,0)
D.writer("for".format(RC),0,1)
D.writer("{} ms".format(lifetime),0,2)
sleep(lifetime)
IF button.value() == 0:
D.clearall()
D.writer("PROGRAM",0,0)
D.writer("COMPLETED",0,1)
sys.exit()
Then the controller tells me that he is now still awake for 5 seconds. At the end of the waking phase, I have the opportunity to stop the program clean when I press and hold the flash button during this time. With an ESP8266 Node McU or one Amica If this is on the board, the ESP8266 D1 Mini (Pro) I have to sponsor an extra key module.
print(port, "Schlaeft now",sleep,"MS")
D.clearall()
D.writer("I AM SLEEPING",0,0)
D.writer("Now for".format(RC),0,1)
D.writer("{} ms".format(sleep),0,2)
# Lightsleep (Sleeptime)
Deepsleep(sleep)
Shortly before the controller goes to sleep, he informs me about it. Depending on which of the two lowest lines, the ESP8266/ESP32 now falls into a deep sleep in light or, as here.
IF port == "ESP8266":
RC=reset_cause()
Else:
RC=wake_reason()
print(port, "I woke up",sleep,"MS")
D.clearall()
D.writer("WOKE UP",0,0)
D.writer("THROUGH {}".format(RC),0,1)
D.writer(ground[RC],0,2)
If it was a deep sleep, I never see this last edition, because in this case, the program starts again. If it was Lightsleep, the program continues with the IF construct.
ESP32
The module machine The ESP32 also knows the two sleep modes: Lightsleep and Deepsleep. With the ESP32, I could not find any great differences in electricity consumption. When awake, the circuit of Image 2, if no program runs, pulls 38mA. During the command sleep Runs, flow 13MA, in deep sleep 12mA. The OLED display has a share of 3MA. When restarting, the current increases briefly to over 50 mA. But there is no significant difference in the current between Lightsleep and Deepsleep. If program commands are carried out during the waiting phases, the current strength is also almost 50 mA.
You can awaken the ESP32 in several types, timely-controlled by pressing a button that must be connected to one of the RTC GPIOs, or via a touchpad on one of the corresponding touch GPIOS. I present a sample program. The basis is the program Sleep+Wachen.Py, which experiences changes in corresponding places. The functions to be called are in the module ESP32 At Home, which is logically not available to the ESP8266.
The timer-controlled awakening happens with the ESP32 as well as the ESP8266 and therefore does not require any further explanation. On the other hand, it is new to awakening via one or more buttons or via a touchpad. With the function wake_reason() from the module machine, which only exists in the ESP32, the reason for awakening can be queried.
ESP32 |
|
|
Pwron_reset |
1 |
after turning on |
Ext0_wake |
2 |
After pressing a button |
Ext1_wake |
3 |
After pressing one of several buttons |
Deepsleep_reset |
4 |
After awakening from deep sleep |
TouchPad_wake / Soft_reset |
5 |
After touching a touchpad After calling the Machine.Reset function () |
Ulp_wake |
6 |
Ultra low power processor |
Table 2
Wake_on_ext0
With this function from the module ESP32, I open up the possibility of ending the sleep phase, no matter which one, via touch pressure.
wakepin=Pin code(14)
import ESP32
ESP32.wake_on_ext0(wakepin,ESP32.Wakeup_all_low)
With wakepin I hand over a pin object. One of the RTC GPIOs must be selected as a connection because only these are still active during the rest period. Nevertheless, the normal GPIO number is specified when the pin object is instantiated. Table 3 shows which connections can be considered.
Rtc_gpio0 |
GPIO36 |
Rtc_gpio3 |
GPIO39 |
Rtc_gpio9 |
GPIO32 |
Rtc_gpio8 |
GPIO33 |
Rtc_gpio6 |
GPIO25 |
Rtc_gpio7 |
GPIO26 |
Rtc_gpio17 |
GPIO27 |
Rtc_gpio16 |
GPIO14 |
Rtc_gpio15 |
Gpio12 |
Rtc_gpio14 |
GPIO13 |
Rtc_gpio11 |
GPIO0 |
Rtc_gpio13 |
GPIO15 |
Rtc_gpio12 |
Gpio2 |
Rtc_gpio10 |
GPIO4 |
Table 3
In the program Sleep+Wachen.Py If waking up is already installed by a button. The constant ESP32.Wakeup_all_low Has the value False (See Image 5) and ensures that the ESP32 wakes up when a low level is available on GPIO14. This corresponds to the circuit in Image 2. Alternatively, with Wakup_any_high The ESP32 wakes up when the level goes to 3.3V.
Image 5: Attributes of the ESP32 module
wake_on_ext1
With wake_on_etx1 (), several keys can wake up the ESP32. The PIN objects are then as a tupel or as list handover. The corresponding lines could look like this.
wakepin = Pin code(14)
button = Pin code(0,Pin code.IN,Pin code.Pull_up)
Keys = (wakepin, button)
import ESP32
ESP32.wake_on_ext1(tasty,ESP32.Wakeup_all_low)
Now the ESP32 can also be woken up via the flash key.
wake_on_touch
Also about one touchpoint can wake up the ESP32. It is possible to connect several touchpads. However, it cannot be worked on buttons at the same time, the interpreter reports a mistake.
Traceback (custody recent call load):
File "" , line 37, in <modules>
Value: NO resources
The elif-Part could now look like this. The wake_on_ext0-Iity is commented on.
elif port == "ESP32":
I2C=Softi2c(scl=Pin code(22),sda=Pin code(21))
From machine import wake_reason, Touchpad
import ESP32
wake1 = Pin code(15, Fashion = Pin code.IN)
wake2= Pin code(2, Fashion = Pin code.IN)
Touch1 = Touchpad(wake1)
Touch2= Touchpad(wake2)
Touch1.config(300)
Touch2.config(300)
ESP32.wake_on_touch(True)
#ESP32.Wake_On_EXT0 (WAKEPIN, ESP32.Wakeup_all_low)
ground={
1:"Poweron Reset",
2:"Ext0 Wake",
3:"Ext1 Wake",
4:"Deepsleep Reset",
5:"Touch Wake",
6:"Ulp Wake",
}
RC=wake_reason()
I have connected two pieces of boards to the Pins GPIO15 and GPIO2. The two touchpad objects generated are configured so that the TouchX.Read() read value without touch (e.g. 419) well above that of the method config() handed over and the value determined with touch (e.g. 65) significantly below.
If the program is started a second time and the ESP32 woken up with a touch, we get the reason for the previous awakening correctly.
Restart from: 5 Touch Wake
This is the Constructor of Oled Class
Size: 128x32
ESP32 goes in 5000 MS sleep
ESP32 Schlaeft now 5000 MS
Lightsleep(sleep)
# Deepsleep (Sleeptime)
If Lightsleep is activated instead of deep sleep, the program part is executed after the call, regardless of whether the ESP32 is covered by the timer or by touch or buttons. Then the program ends. If this part is to be run through several times, you would have to pack it in a while loop, this:
# Sleep+Wachen.PY
#
From machine import reset_cause,\
Deepsleep, Lightsleep, \
sleep, Softi2c, Pin code
import sys
From OLED import OLED
port=sys.platform
lifetime=5000
sleep=5000
button=Pin code(0,Pin code.IN,Pin code.Pull_up)
wakepin=Pin code(14)
IF port == "ESP8266":
I2C=Softi2c(scl=Pin code(5),sda=Pin code(4))
ground={
0:"Poweron Reset",
1:"Watchdog Reset",
2:"???",
4:"Soft Reset",
5:"Deepsleep Reset",
6:"Hard Reset",
}
RC=reset_cause()
elif port == "ESP32":
I2C=Softi2c(scl=Pin code(22),sda=Pin code(21))
From machine import wake_reason, Touchpad
import ESP32
wake1 = Pin code(15, Fashion = Pin code.IN)
wake2= Pin code(2, Fashion = Pin code.IN)
Touch1 = Touchpad(wake1)
Touch2= Touchpad(wake2)
Touch1.config(300)
Touch2.config(300)
ESP32.wake_on_touch(True)
#ESP32.Wake_On_EXT0 (WAKEPIN, ESP32.Wakeup_all_low)
ground={
1:"Poweron Reset",
2:"Ext0 Wake",
3:"Ext1 Wake",
4:"Deepsleep Reset",
5:"Touch Wake",
6:"Ulp Wake",
}
RC=wake_reason()
Else:
raise Runtime("Unknown Port")
while 1:
print("Restarted by:",RC,ground[RC])
D=OLED(I2C,Heightw=32) # 128x32 pixel display
D.clearall()
D.writer("Restart through",0,0)
D.writer("{}".format(RC),0,1)
D.writer(ground[RC],0,2)
sleep(3000)
print(port, "walks into",lifetime,"MS sleep")
D.clearall()
D.writer("I'M AWAKE",0,0)
D.writer("for".format(RC),0,1)
D.writer("{} ms".format(lifetime),0,2)
sleep(lifetime)
IF button.value() == 0:
D.clearall()
D.writer("PROGRAM",0,0)
D.writer("COMPLETED",0,1)
sys.exit()
print(port, "Schlaeft now",sleep,"MS")
D.clearall()
D.writer("I AM SLEEPING",0,0)
D.writer("Now for".format(RC),0,1)
D.writer("{} ms".format(sleep),0,2)
Lightsleep(sleep)
# Deepsleep (Sleeptime)
IF port == "ESP8266":
RC=reset_cause()
Else:
RC=wake_reason()
print(port, "I woke up",sleep,"MS")
D.clearall()
D.writer("WOKE UP",0,0)
D.writer("THROUGH {}".format(RC),0,1)
D.writer(ground[RC],0,2)
sleep(3000)
Image 6: ESP8266-Nodemcu with DS1302-RTC
With all the new findings, you are now able to develop more battery-saving circuits and preserve data beyond the sleep phases. However, it turned out that the effect on the ESP8266 is clearer than with his big brother. I could not determine the electricity strengths of a few µA in the deep sleep phase in any of the boards examined. Such information is probably only related to the chip and not to the entire board. However, the latter is crucial.
7 commenti
Werner
bei den Dateien wake_on_gpio.py und schlafarten.py kommt die Fehlermeldung:
“Not Found
The requested URL was not found on this server."
MisterD
Spannend wäre den testaufbau gleich noch für mehrere verschiedene Boards zu nutzen,vor allem würden mich der pico und pico w interessieren.
Thomas
Alter Kaffee. Solche Untersuchungen, allerdings in C++, gibt es schon seit Jahren. Einen nackten ESP (ohne USB, ohne ASM1117 und ohne LED) kann man auf ein paar µA im Schlaf trimmen. Wer wirklich mit Akku oder Batterie sinnvoll im Langzeitmodus expeirmentieren will, sollte daher keinen NodeMCU, Wemos oder ähnliches verwenden, sondern immer auf den nackten ESP zurückgreifen und ein bisschen löten. Es sei denn, er überlässt die Tiefschlafsteuerung einem Attiny oder einem Echtzeit-RTC, um den EN-PIN mittels geeigneter Schaltung auf VCC zu setzen bzw. zu trennen. Man muss dan naber auch damit leben, dass der ESP einen Neustart macht und nur noch weiß, was er im RTC-Memory oder im Flash als Datei gespeichert hat.
Reiner Knapp
Nur so als Hinweis zum Stromverbrauch mein Vortrag auf der Piandmore: https://piandmore.de/de/conference/pam12/call/public-media/2289
Man sollte sich nicht mit 12mA Stromverbrauch im standby zufrieden geben!
Harald
Das Unternehmen ist recht sinnlos. Zum Stromsparen muß man die reinen ESPs verwenden. Durch die Breakout-Boards wird extrem viel Strom verbaraucht. Deshalb ist auch zweischen light- und deep-sleep nur ein geringer Unterschied meßbar.
Veit
Hallo
Tolles Projekt. Leider nur in Micro Python. Ich bin fast 70 Jahre und habe mich in die Arduino IDE eingearbeitet. Mühselig und Langsamm !!
Eine neue Sprache muss und will ich nicht noch anfangen.
Viele Grüße an das tolle Team und weiter so.
Herbert Dietl
Hallo, folgende py codes lassen sich nicht downloaden:
wake_on_gpio.py
schlafarten.py