I am using these nodemcu things from amazon to read the internet, but they often came back with wdt reset and would just quit and start over.
well the solution is easy, just add a bunch of yield(); to your loops. add until it works is my motto.
good luck.
This paragraph from the Beginner's Guide to ESP8266 explains why the need for yield() (or delay()) in your programs.
Sharing CPU time with the RF part
One thing to keep in mind while writing programs for the ESP8266 is that your sketch has to share resources (CPU time and memory) with the Wi-Fi- and TCP-stacks (the software that runs in the background and handles all Wi-Fi and IP connections).
If your code takes too long to execute, and don’t let the TCP stacks do their thing, it might crash, or you could lose data. It’s best to keep the execution time of you loop under a couple of hundreds of milliseconds.Every time the main loop is repeated, your sketch yields to the Wi-Fi and TCP to handle all Wi-Fi and TCP requests.
If your loop takes longer than this, you will have to explicitly give CPU time to the Wi-Fi/TCP stacks, by using including delay(0); or yield();. If you don’t, network communication won’t work as expected, and if it’s longer than 3 seconds, the soft WDT (Watch Dog Timer) will reset the ESP. If the soft WDT is disabled, after a little over 8 seconds, the hardware WDT will reset the chip.
From a microcontroller’s perspective however, 3 seconds is a very long time (240 million clockcycles), so unless you do some extremely heavy number crunching, or sending extremely long strings over Serial, you won’t be affected by this. Just keep in mind that you add the yield(); inside your for or while loops that could take longer than, say 100ms.
You might also want to examine your code to see what is causing your loop() function to run so slow. Generally, in a well written program, your loop() should be running many times every second. Having blocking code in your loop is a bad idea even if you're not using an ESP8266.
There are some situations where code with long blocking duration is unavoidable (perhaps because you're using a poorly designed library) and in this case calling yield() is a good idea.
With the ESP many of the yealdings can be handled by freeRTOS.
The natural WDT time out for the ESP is the same as the rollover for the millis(), what 47ish days portMaxDelay. When the WDT timer in an ESP gets triggered before a portMaxDelay, the default time out of the WDT, something has went terribly wrong.
Many functions, with the ESP use freeRTOS, even though the programmer may not be directly using freeRTOS. As an example the ESP CAN buss library or the ESP SPI library makes use of freeRTOS queues, even though the CAN bus or SPI library user does not declare to use freeRTOS.
The void loop(), on an ESP, has the lowest priority, 1. The loop is, assigned clean up and runs when it can. Under freeRTOS the loop function is empty and other tasks are allowed to rise above priority 1.
As a starting place, I have found that many AdaFruit libraries cause Guru Meditation and or WDT errors. Your ESP should be providing more info then just a WDT error, which would go a long way towards finding the cause.
The natural WDT time out for the ESP is the same as the rollover for the millis(), what 47ish days portMaxDelay. When the WDT timer in an ESP gets triggered before a portMaxDelay, the default time out of the WDT, something has went terribly wrong.
From the Beginner's Guide to ESP8266
if it's longer than 3 seconds, the soft WDT (Watch Dog Timer) will reset the ESP. If the soft WDT is disabled, after a little over 8 seconds, the hardware WDT will reset the chip.
Those quotes seem to contradict.