`<namespace>::*` forward declarations are not always created

[mcspr]

See https://github.com/esp8266/Arduino/actions/runs/5292564029/jobs/9579589045?pr=8828#step:5:183

onewire.ino cannot build because checkSwSerial is not generated after .ino -> .cpp conversion

xtensa-lx106-elf-g++ -o .pio/build/nodemcuv2/FrameworkArduino/LwipDhcpServer.cpp.o -c -fno-rtti -std=gnu++17 -fno-exceptions -Os -mlongcalls -mtext-section-literals -falign-functions=4 -U__STRICT_ANSI__ -ffunction-sections -fdata-sections -Wall -Werror=return-type -free -fipa-pta -DPLATFORMIO=60107 -DESP8266 -DARDUINO_ARCH_ESP8266 -DARDUINO_ESP8266_NODEMCU_ESP12E -DF_CPU=80000000L -D__ets__ -DICACHE_FLASH -D_GNU_SOURCE -DARDUINO=10805 -DARDUINO_BOARD="PLATFORMIO_NODEMCUV2" -DARDUINO_BOARD_ID="nodemcuv2" -DFLASHMODE_DIO -DLWIP_OPEN_SRC -DNONOSDK22x_190703=1 -DTCP_MSS=536 -DLWIP_FEATURES=1 -DLWIP_IPV6=0 -DVTABLES_IN_FLASH -DMMU_IRAM_SIZE=0x8000 -DMMU_ICACHE_SIZE=0x8000 -I.pio/build/nodemcuv2/core -I/home/runner/work/Arduino/Arduino/tools/sdk/include -I/home/runner/work/Arduino/Arduino/cores/esp8266 -I/home/runner/work/Arduino/Arduino/tools/xtensa-lx106-elf/include -I/home/runner/work/Arduino/Arduino/tools/sdk/lwip2/include -I/home/runner/work/Arduino/Arduino/variants/nodemcu /home/runner/work/Arduino/Arduino/cores/esp8266/LwipDhcpServer.cpp
/tmp/tmp3vs56zl4/src/onewiretest.ino: In function 'void loop()':
/tmp/tmp3vs56zl4/src/onewiretest.ino:31:2: error: 'checkSwSerial' was not declared in this scope
31 | checkSwSerial(&swSer1);
| ^~~~~~~~~~~~~
*** [.pio/build/nodemcuv2/src/onewiretest.ino.cpp.o] Error 1

Tried to fix it via platformio/platformio-core#4586, but I missed that it was reverted for Tasmota platformio/platformio-core#4594 when sketch uses multiple .ino files

PIO breaks even with a single file, since only 'simple' declarations are generated
arduino-cli would behave the same when two or more .ino files are used, when forward-decl is added before library header is included

[dok-net]

@mcspr Fixing and committing straight to main. Complete release coming up soonish.

As an aside, could you please try harder to review and merge the ESP8266 power-saving PR esp8266/Arduino#7055 from yours truly? I wouldn't ask so insistently if you had not mentioned you would and I am hoping every day :-) Another remark, I think d-a-v has gotten the "grain" in Scheduler wrong, using lcd instead of min, in my poor understand this seems to generally result in thrashing, despite looking smart on paper ;-) In any case, it should be documented why min isn't the right choice. Why I am asking? Because it's a divergence from the pattern I had in mind when I proposed the code to the delay-family of functions that got merged and is now used by that :-) I may be wrong, no questions.

[mcspr]

re. 7055, what mainly caught my eye is timers stuff that work arounds timed light sleep, which tbh asks to be replaced with something like this implementation
https://github.com/micropython/micropython/blob/38e7b842c6bc8122753cbf0845eb141f28fbcb72/ports/esp8266/modmachine.c#L102-L130
without relying on de-re-attaching timers, keeping user code from executing b/c of context switches, etc. I would guess it may work with the standard gpio-wake-up version with an additional code that sets up a timer to trigger another interrupt, which is set up separately. But, depends on how SDK does interrupt masking. Or, try reproducing whatever happens in idle function that 'powers down' everything running on the device, thus writing a proper version that does not rely on SDK.

Will comment on the rest in the PR as soon as I got the time.

re. Scheduler - I believe the idea with gcd is to allow wakeups doing something else instead of executing scheduled funcs. Open an issue to ping him?
I don't see anything in PR or internal discussion, so I suppose I thought of the same thing before merging. Especially if we don't use weird delays like 550 vs. 500? Any worse off apps, benchmarks, hard numbers?

[dok-net]

@mcspr I am sorry, but I don't know what you are telling me, certainly not at an actionable level. What I have implemented should be according to the freely available documentation from Espressif and provide an improvement over how things are handled now, no matter what. If you could find out how to handle the apparent race condition on going to sleep less verbosely, please provide the code?

I'll have to look at the Scheduler again and inject some diagnostic output to get a more detailed impression. On doing that, I will open an issue with code fragments such that we can discuss the implications.

To be sure: thank you for your efforts. Then again, I'm doing it all just for fun, either, no commercial work project uses the ESP8266, besides my use of the relatively recent GCC with C++ coroutine support switched on for validation of the whole idea (viz. libcoro).

[mcspr]

I hope I don't give an impression I get paid for this :)

I would just wary of following Espressif api to the point, if it does not accomplish the task (or does not do anything, even when it says it does... or get fixed anytime in 2023 or in the future).

Main highlight is waiti <LEVEL> - halt cpu until some interrupt wakes it up. In case above, just another example of working with hardware at hand.