Standard Arduino practices cause WDT to reset esp8266

[Makuna]

One standard practice in many examples is to wait for serial input in a tight loop like ...

while (!Serial.available());

This will cause the WDT to trigger.

Can we insert a yield inside the available() when it would return false so that this common code fragment would not cause a processor reset?

[me-no-dev]

@Makuna doing it is not a bad idea, but it might put the current code to wait when that is not expected.
Any use cases that would have a problem come to mind?
Can't we find a better way? Maybe find out before wdt triggers and feed it? Do you know of any relevant interrupt vector?

[skandragon]

Does the standard Arduino even have a WDT enabled by default? I also see no mention of a WDT in this project's README, other than this little bit:

ESP-specific APIs

APIs related to deep sleep and watchdog timer are available in the ESP object,
only available in Alpha version.

Also, no mention how to find and use this "alpha" version (which I assume is based on master?)

[Makuna]

The standard Arduino (AVR) does NOT have the WDT turned on by default. AVR does support a WDT in the processor (I use it) but its uncommon to find it being used.
The esp8266 does due to the WiFi that runs in the background.
This is also why I believe most of the available() methods should contain a yield() so that the WiFi will continue to function as expected. Note that a few of the available() methods on libraries already have a yield() in them, but not all.
I have the changes and will be testing it shortly.

[Makuna]

This is what is done in some available() methods, and the proposal is to replicate something similar to all of them.

    static uint32_t lastPollTime = 0;

    if (lastPollTime > esp_micros_at_task_start())
        yield();

[me-no-dev]

reding the source behind, I come to conclusion that yield will be called every next time, but first, inside the same loop() call. Am i getting this right?
esp_micros_at_task_start is set before calling each loop()

[Makuna]

I think that code is flawed, you are correct in one way, but it has a problem, if the loop is entered when micros is near the top of the range, then wraps, this test will calculate true faster than it normally will.
The concept should be, if a specific amount of time has passed since the last yield (while start of the loop is ok also), then yield.

Here is my working example, removing the static variable completely. It also only yields when there is nothing available, with the thought that if there is something available, the caller will want to get to it quickly.

    if (!isAvailable && (micros() - esp_micros_at_task_start()) > 10000)
    {
        yield();
    }

[me-no-dev]

calling yield after the first time makes perfect sense when we are talking about network streams, because after consuming the first available, we need to yield to get the next packet in the buffer.
When talking about Serial, maybe yielding on nothing available or time close to wdt is better idea.

[me-no-dev]

you are correct on the flawed comparison

[Makuna]

What I list above will only yield if there is no data available, but it will yield often after 10ms since the last loop start.

[me-no-dev]

looks great

[Makuna]

new pull to help solve this #551

[Makuna]

please review the new pull, it is cleaner and provides a consistent experiences.
Further, the latest improvement will also never yield within an ISR.

[Makuna]

1154545 Merged