The test was done using the feature fast_connect WifiManager library
https://github.com/tzapu/WiFiManager/tr ... astconnect
and my basic app shell library BaseSupport which I use in all my applictions
https://github.com/roberttidey/BaseSupport
This requires a BaseConfig.h in the app to configure the options in the support library. The #define FASTCONNECT must be uncommented to enable this feature.
I then used a minimal sketch to measure timings. To keep things simple I used a GPIO input to determine whether wifi was on or off. The sketch uses this to control the variable setupWifi to determine whether Wifi is on or off. So I can perform resets in a controlled fashion with wifi on or off.
//test
#include "BaseConfig.h"
void setupStart() {
pinMode(13,INPUT_PULLUP);
if(digitalRead(13) == 0) {
setupWifi = 0;
} else {
setupWifi = 1;
}
Serial.println("Start ms: " + String(millis()));
}
void setupEnd() {
Serial.println("End ms: " + String(millis()));
}
void loop() {
}
The sketch measure the time when it first gets going and when the setup is complete and normal loop processing can start. Obviously the ESP8266 is boot time is not included and would typically be about 300mS.
When the wifi is enabled I see a start-end elapsed time of 200mS. When I disable wifi I see a start-end elapsed time of about 1mS or less. I can perform multiple no wifi start ups and then follow up with a wifi and still get elapsed time of 200mS.
This indicates that it is possible to mix the wifi on and off without affecting the fast connect time. In overall timing adding in the typical boot these would give a 500mS start up with wifi and 300mS with no wifi.
Now it is possible that the deep sleep operation is behaving differently somehow. I'll try some further experiments if I get a chance.