Extending on the new WiFi-less startup and new power saving APIs in ESP class #7979

dok-net · 2021-04-13T09:18:19Z

Implementing in ESP class the sleep modes that are pertinent with and without WiFi:

forced light sleep, with/without timeout, with/without GPIO wakeup.
automatic light sleep when idling, like during delay()
automatic modem sleep when idling, like during delay()
never sleeping (NONE_SLEEP_T)

For sketches without WiFi, additional RF powersaving mode support on power up and deep-sleep resume. Could avoid power use spikes and delays during startup.

WiFi default is "off" now, don't force sleep in setup() of examples that do use WiFi.

Examples for the new modes.

Fixes #7055 - thanks to @Tech-TX for pointing this out.

cores/esp8266/Esp.cpp

cores/esp8266/core_esp8266_phy.cpp

cores/esp8266/Esp.cpp

cores/esp8266/Esp.h

Tech-TX · 2021-04-25T22:59:05Z

I've been doing some testing for Dirk for a week or two, and have re-verified the correct operation of this last commit 637f5d6. The timers are properly re-attached after Forced Light Sleep, which I never could get to. Thanks, Dirk! The three examples function as expected, and all power saving modes hit the right current levels. No surprises, no warts that I've seen. For people using servos I'd stop them before Forced Light Sleep, else they may slam the stops when PWM halts. You can restart them afterwards.

In order to maintain WiFi across Forced Light Sleep you must sleep the modem cleanly before ESP.forcedLightSleepBegin(). I tried it the dirty way and WiFi wouldn't recover after Sleep.
I tested WiFi.forceSleepBegin(0xFFFFFFF) (sleep forever) before putting it to sleep, and WiFi.forceSleepWake() after it had recovered from ESP.forcedLightSleepEnd(). No problems restoring the connection that way.

I need to revisit #6989 and clean that demo program up with the new API calls. When merged this closes #7055

I didn't review all of the code, merely tested the functionality very thoroughly.

Tech-TX · 2021-04-27T01:09:03Z

Utterly side comment, not required for this PR: I think I just figured out how the NodeMCU folks implemented something like 'wake from Forced Light Sleep with a CHANGE level interrupt', not just the HI LEVEL and LO LEVEL specified in the API Reference.

If you read the pin level of the interrupt pin just before going to Forced Light Sleep and set the interrupt to the opposite level, it accomplishes the same thing. Going in with a HIGH on the pin, set the interrupt to LOW and vice versa. Then any change during Forced Light Sleep wakes it, and the user doesn't care what state the pin had been in immediately prior to Sleep; any change wakes it up.

Since the interrupt attachment is done outside of this API wrapper, the end user would have to do this in their code.

Due to the delay() needed to put it to Sleep, there's a small but nonzero chance that the pin might change after you read it, and it wouldn't come out of Sleep at all without a Reset as the Sleep logic is all mangled.

cores/esp8266/Esp.cpp

doc/libraries.rst

cores/esp8266/core_esp8266_main.cpp

cores/esp8266/core_esp8266_phy.cpp

…ck-pressed button.

…nter when it is no longer needed.

… user_rf_pre_init Since WiFi is disabled at boot by default, and the above change to ESP.deepSleep..., (sample) sketches for special RF modes on resume from deep sleep may need fixing or documentation update. That's not done by this commit alone.

…ibs where feasible.

… weak symbol.

dok-net · 2023-03-12T01:25:15Z

Reinstated #define RF_PRE_INIT() due to its use in #8783

mcspr · 2023-06-19T11:49:06Z

cores/esp8266/Esp.cpp

+void EspClass::forcedModemSleepOff()
+{
+    const sleep_type_t sleepType = wifi_fpm_get_sleep_type();
+    if (sleepType != NONE_SLEEP_T) {
+        if (sleepType == MODEM_SLEEP_T) wifi_fpm_do_wakeup();
+        wifi_fpm_close();
+    }
+    wifi_fpm_set_sleep_type(saved_sleep_type);
+    saved_sleep_type = NONE_SLEEP_T;
+}


Combine with begin() as a single operation?
If begin() called once and then off(), sort-of works (if fpm was not enabled externally)
If begin() called once and then again, sleep mode gets overwritten

Any calls to the SDK or modifying sleep modes by sidelining this API is undefined behavior. Simple as that.
The saved_sleep_type, if that is what you are focused on, is rather a convenience than a full-blown requirement for this to be useful. I don't see any real malfunction if its used the way you described.

mcspr · 2023-06-19T11:50:10Z

cores/esp8266/Esp.cpp

+#ifdef HAVE_ESP_SUSPEND
+    esp_delay(10);
+#else
+    delay(10);


Are we waiting for certain condition to happen? Should it check something instead of assuming 10ms delay does something?
also not necessary ifdef

Your opinion may differ, even for a reason, but I implement to the public specification and as my comment // SDK turns on forced modem sleep in idle task explains, there shall be a delay for the idle task to take over.
Thanks for picking up the quite dated HAVE_ESP_SUSPEND, it's been so long, I don't even recall where and when it was ever defined.

mcspr · 2023-06-19T11:51:43Z

cores/esp8266/Esp.cpp

+    wifi_fpm_set_sleep_type(MODEM_SLEEP_T);
+    wifi_fpm_open();
+    saved_wakeupCb = nullptr;
+    if (wakeupCb) wifi_fpm_set_wakeup_cb(wakeupCb);


fpm_wakeup_cb_func will be called after system wakes up only if the force sleep
time out (wifi_fpm_do_sleep and the parameter is not 0xFFFFFFF).
fpm_wakeup_cb_func will not be called if wake-up is caused by
wifi_fpm_do_wakeup from MODEM_SLEEP_T type force sleep.

Also, perhaps, not necessary to expose to user? Isn't return signal enough of a result?

If there's no hurt in exposing it as an option, let's keep it this way, please.

cores/esp8266/Esp.cpp

mcspr · 2023-06-19T11:56:42Z

cores/esp8266/Esp.cpp

+#endif
+    {
+        esp8266::InterruptLock lock;
+        saved_timer_list = timer_list;


-//- as modem - if we hide timer list, it should not be possible for user to overwrite this accidentally. Single operation instead of separate begin() -> end()?

This way, it worked/works, other ways, it didn't work/does work, i.e. doesn't enter the power saving modes properly. It was all carefully measured by the other guy at the time. Whatever happened to him :-(

Single operation instead of separate begin() -> end()?

I don't understand that sentence, I am sorry.

This way, it worked/works, other ways, it didn't work/does work, i.e. doesn't enter the power saving modes properly. It was all carefully measured by the other guy at the time. Whatever happened to him :-(

Sadly, yeah, might be difficult to test at this point from our baseline of knowledge :/
As I understand it, we have issue where SDK processes timer list. So, that is what we try to avoid in code. If there is an ets_post to a task, does it still work? Are timers waking up early, or SDK never sleeps / idles to begin with?

I don't understand that sentence, I am sorry.

Something like InterruptLock. Imagine FpmThingy class that enables sleep on begin or construction, and disables on destruction. It may or may not be applicable to our internal usage, but seems like a better API for user side of things. Plus, it would not be necessary to expose too much methods to control it

@mcspr I have added an RAII class and modified libraries\esp8266\examples\ForcedLightSleep\ForcedLightSleep.ino. Please review that and let me know if that matches to what you had in mind. Thanks for the suggestion!

mcspr · 2023-06-19T11:57:50Z

cores/esp8266/Esp.cpp

+#endif
+    {
+        esp8266::InterruptLock lock;
+        saved_timer_list = timer_list;


Repeating the q from above - what is the difference between GPIO-activated sleep and timed one here? Is CPU really sleeping or we just simulate that it does?

OMG, you are asking questions that I cannot remember the answer to, except that I am 100% certain that we literally did hours of repetitive tests to show that power consumption dropped to the expected levels, and it didn't or the MCU became unreliable or the tables got corrupted if it wasn't done in exactly this - documented by Espressif - way. We really should not change a single line.

Right, but now we have a half-understood feature that maybe works?
Reading our issues simply repeats the above - we copy nodemcu and test how it did. I'd have to read that yet again if you don't have link or an explanation :/
(nodemcu/nodemcu-firmware#1231 (comment) and below)
edit: link oops

I'm not sure we are not talking past each other. The sleep isn't actived by the GPIO, but cancelled. Same for the timer. I'm sure that's what you meant. As far as it got measure two years ago, yes we were sure it did as advertised - sleeping to save power, resuming either by GPIO trigger - push of a button - or timeout.

@mcspr Is this now stalled again due to to unrelated workload, or have my changes and explanations been unconvincing so far? I would be totally relieved if this finally got merged, I am sure it will help people a lot, at least it might allow more specific reports about power-saving mode issues?

cores/esp8266/Esp.cpp

…and should be used unconditionally.

dok-net changed the title ~~WiFi default is off now, don't force sleep in setup() of examples~~ Extending on the new WiFi-less startup and new power saving APIs in ESP class Apr 15, 2021

dok-net force-pushed the wifioff branch from 38e75f8 to c663996 Compare April 15, 2021 18:12

dok-net mentioned this pull request Apr 15, 2021

[BREAKING] wifi: remove pseudo-modes for shutdown, expose ::[resumeFrom]shutdown() #7956

Merged

dok-net force-pushed the wifioff branch from c663996 to 3489f75 Compare April 15, 2021 18:38

dok-net mentioned this pull request Apr 16, 2021

WiFi fpm sleep type checks in mode() #7975

Open

6 tasks

dok-net force-pushed the wifioff branch 8 times, most recently from 5732573 to ab8a20e Compare April 18, 2021 09:58

mcspr reviewed Apr 18, 2021

View reviewed changes

cores/esp8266/Esp.cpp Show resolved Hide resolved

cores/esp8266/core_esp8266_phy.cpp Outdated Show resolved Hide resolved

cores/esp8266/Esp.cpp Outdated Show resolved Hide resolved

mcspr reviewed Apr 18, 2021

View reviewed changes

cores/esp8266/Esp.h Outdated Show resolved Hide resolved

dok-net force-pushed the wifioff branch 6 times, most recently from 1f08089 to 68875bf Compare April 25, 2021 11:05

mcspr reviewed Apr 27, 2021

View reviewed changes

cores/esp8266/Esp.cpp Outdated Show resolved Hide resolved

cores/esp8266/Esp.cpp Show resolved Hide resolved

doc/libraries.rst Outdated Show resolved Hide resolved

cores/esp8266/core_esp8266_main.cpp Show resolved Hide resolved

cores/esp8266/core_esp8266_phy.cpp Show resolved Hide resolved

dok-net force-pushed the wifioff branch 3 times, most recently from e8cab42 to 5a73c73 Compare May 1, 2021 14:04

dok-net force-pushed the wifioff branch 3 times, most recently from 2a34cbd to 336c1c9 Compare May 17, 2021 11:07

dok-net added 13 commits March 12, 2023 01:54

AttachInterrupt is not available in ISR (IRAM_ATTR), fix crash on stu…

213a2e0

…ck-pressed button.

SDK needs idle task to perform mode switching. Reset the callback poi…

56c40f3

…nter when it is no longer needed.

Fix serial bitrate in example.

affc7fc

Debounce the button GPIO in order to prevent crashes due to IRQ storms.

6015cec

Add documentation for the new ESP sleep modes to libraries.rst

b6e14f6

Fix headline in documentation as well.

ad454ea

By review comment.

74951fd

More comprehensive description of the usage of forcedLightSleep.

df7e909

Be more specific about ForcedLightSleepEnd.

1af1380

Describe forced light sleep initiation in more detail.

a9d9cda

Add neverSleep and neverSleepOff to Esp class, use them in core and l…

e8798ac

…ibs where feasible.

Apply suggested style fixes.

3fc7d23

dok-net force-pushed the wifioff branch from ae3479f to 3fc7d23 Compare March 12, 2023 00:56

There may exist code expecting this macro definition to overwrite the…

abd17a7

… weak symbol.

dok-net force-pushed the wifioff branch from d7d7150 to abd17a7 Compare March 12, 2023 01:22

dok-net mentioned this pull request Mar 12, 2023

Reading GPIO16 on power up #8783

Closed

Merge branch 'master' into wifioff

a6d1f73

mcspr mentioned this pull request Apr 22, 2023

light sleep mode & WiFi & millis() overflow #8913

Open

dok-net mentioned this pull request Apr 23, 2023

Minor release EspSoftwareSerial 8.2.0 requires ghostl as stand-alone lib dependency #8915

Open

dok-net added 3 commits April 23, 2023 09:55

Merge branch 'master' into wifioff

5a2c2db

Merge branch 'master' into wifioff

2d1cb1c

Merge branch 'master' into wifioff

9847e1f

mcspr reviewed Jun 19, 2023

View reviewed changes

dok-net added 3 commits June 21, 2023 21:28

Reviewer noticed that esp_suspend is part of the core for awhile now …

b8a95de

…and should be used unconditionally.

Implement RAII-patterned token class for ForcedLightSleep begin()/end().

dd6ea93

Code style fixes.

6252680

dok-net force-pushed the wifioff branch from 92c3a8a to 6252680 Compare June 24, 2023 18:34

Merge branch 'master' into wifioff

cd6d155

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Extending on the new WiFi-less startup and new power saving APIs in ESP class #7979

Extending on the new WiFi-less startup and new power saving APIs in ESP class #7979

dok-net commented Apr 13, 2021 •

edited

Loading

Tech-TX commented Apr 25, 2021 •

edited

Loading

Tech-TX commented Apr 27, 2021 •

edited

Loading

dok-net commented Mar 12, 2023

mcspr Jun 19, 2023

dok-net Jun 24, 2023

mcspr Jun 19, 2023

dok-net Jun 21, 2023

mcspr Jun 19, 2023

dok-net Jun 21, 2023

mcspr Jun 19, 2023

dok-net Jun 21, 2023

mcspr Jun 23, 2023

dok-net Jun 24, 2023 •

edited

Loading

mcspr Jun 19, 2023

dok-net Jun 21, 2023

mcspr Jun 23, 2023 •

edited

Loading

dok-net Jun 24, 2023 •

edited

Loading

dok-net Aug 5, 2023

Extending on the new WiFi-less startup and new power saving APIs in ESP class #7979

Are you sure you want to change the base?

Extending on the new WiFi-less startup and new power saving APIs in ESP class #7979

Conversation

dok-net commented Apr 13, 2021 • edited Loading

Tech-TX commented Apr 25, 2021 • edited Loading

Tech-TX commented Apr 27, 2021 • edited Loading

dok-net commented Mar 12, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dok-net Jun 24, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mcspr Jun 23, 2023 • edited Loading

Choose a reason for hiding this comment

dok-net Jun 24, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dok-net commented Apr 13, 2021 •

edited

Loading

Tech-TX commented Apr 25, 2021 •

edited

Loading

Tech-TX commented Apr 27, 2021 •

edited

Loading

dok-net Jun 24, 2023 •

edited

Loading

mcspr Jun 23, 2023 •

edited

Loading

dok-net Jun 24, 2023 •

edited

Loading