|
Post by gb0101010101 on Mar 24, 2019 17:35:57 GMT -8
It looks like the OLED update code has many delay() calls that are used to rotate the display screen when using most display formats. Also there are large delays for add on components which blatantly exceed the 5000 millisecond update interval: if (AS3935Present == true) { delay(3000); updateDisplay(DISPLAY_LIGHTNING_STATUS); delay(3000); } if (SunAirPlus_Present) { delay(3000); updateDisplay(DISPLAY_SUNAIRPLUS); delay(3000); } if (WXLink_Present) { delay(3000); updateDisplay(DISPLAY_WXLINK); delay(3000); I see there is REST handling code in the OLED update functions because of this so that REST calls can respond.
// Handle REST calls WiFiClient client = server.available(); if (client) { while (!client.available()) { delay(1); } if (client.available()) { rest.handle(client); } } - Is this considered a bug?
- If not then why not?
- If bug then is there any code "in the works" that implements non-blocking delays to update OLED? e.g. using timer intervals.
- If not in works then is there a plan to commit time to fix this?
|
|
|
Post by SDL on Mar 25, 2019 9:01:42 GMT -8
By and large, the ESP8266 code is single threaded. This makes everything harder to write and keep things flowing.
That is why the code is structured the way it is. You can respond to REST calls with a delay (before the HTTP client times out) so it works.
Is it a bug? No, not really. It is a function of the architecture. You can do much more in a threaded environment like the GroveWeatherPi code or our ESP32 based weather station.
BP
|
|
|
Post by gb0101010101 on Mar 26, 2019 9:22:35 GMT -8
Yes it is single thread but there are ways to do update OLED without tying up the thread using delay(). e.g. - Have an OLED buffer update function that writes display strings to a multidimensional array keyed by display page and then line.
- Have a timer callback function that checks current page and rotates display to next page. Rendering the page from buffer array. Then cycles back around.
- Set a timer to execute the callback every second or two to change the display page.
This way the delay() functions can be removed from the OLED functions and will not block execution of other scripts for a long time. Right now the 5 second loop update is delayed until the OLED finishing displaying all content would could be:
- Large display 4 pages x 1800milliseconds = 7.2 seconds
- Addons 6000 each with max 3 = 18 seconds
TOTAL 25.2 seconds! This is why the REST function is not responsive and you added code in OLED.It is also affecting my MQTT code.
Finally code does not detect if display is connected and will execute OLED updates all the time. So disconnecting the OLED does not help and you have to hardcode that OLED is not present to fix it.
I make the code changes to fix this but it would be a substantial change and I do not have the addon hardware to test that it works. That is why it would be great if you could do it.
|
|
|
Post by SDL on Mar 28, 2019 6:37:16 GMT -8
It is a huge change to the software. And it is tough to debug in the ESP8266. We have some ideas on where to go with this so stay tuned.
BP
|
|
|
Post by gb0101010101 on Mar 30, 2019 14:17:41 GMT -8
Had some time to kill so took a stab at this. Managed to get a lot done and have proof of concept working. Split out display updates into two types:
Console ------- Updates the screen instantly keeping a buffer of 6 lines displayed using text size 1. This is used at boot time and during updates.
Timed Screens ------------- This is used to rotate through all the screens during normal operation. Still has Small, Medium, Large, & Demo display formats but generates the display JIT.
Both ---- Have no delay() execution during the screen rendering.
Todo ---- OTA Updates - Test and make sure Console output is correct. Any chance I could get the server side PHP code? Captive portal setup - Works but Console messages do not make sense. I basically copied what was already there but it display info twice and shows empty IP sometimes. Stop timed screen rotation when Console in use during update. Code cleanup
Results ------- MQTT is publishing every 5 seconds on the dot! No lost data and no reconnects taking place. REST responds immediately and works every time! Screen rotates much quicker even though it has same time delay. WeatherSmall format previously seemed to cascade update of each line causing a flashing/wiping effect. This is gone.
Will post changes to GitHub when I am done but it will be many days till I have time again. Just wanted to let you know that I have something working so you do not waste time doing it.
|
|
|
Post by gb0101010101 on Apr 1, 2019 11:57:07 GMT -8
|
|
|
Post by SDL on Apr 2, 2019 5:51:25 GMT -8
Outstanding! Will do!
BP
|
|
|
Post by gb0101010101 on Apr 2, 2019 23:35:10 GMT -8
Let me know if you find any problems with new code. So far everything is working better than before. I have removed all extraneous REST handling code, from places that it should not be, and it continue to work for me now there is non blocking code. I am focused on MQTT for data updates instead of REST so I maybe overlooking something.
|
|
|
Post by SDL on Apr 3, 2019 11:08:51 GMT -8
Yes, the REST problems seem to be related to rate of access in one case and browser helper objects in the other.
BP
|
|
|
Post by gb0101010101 on Apr 4, 2019 15:24:43 GMT -8
FYI, tested OTA Update using my local server and it did update the firmware. Problem is that the REST response gets lost because the board reboots before returning it. Looking at the code it does not look like this is a new issue. Can you confirm this happening before? The only way I see around this is to set ESPhttpUpdate.rebootOnUpdate(false), set a global reboot flag, catch it in main loop(), which then executes ESP.restart(). But apparently that has problems github.com/esp8266/Arduino/issues/3137Which might be fixed by more force full restart. github.com/esp8266/Arduino/issues/1722#issuecomment-321818357WiFi.forceSleepBegin(); wdt_reset(); ESP.restart(); while(1)wdt_reset();
|
|
|
Post by SDL on Apr 5, 2019 8:50:01 GMT -8
Yes, that is what will happen.
BTW, we have had very sporadic luck with the software shutdown schemes for the ESP8266. The key was getting the device to reboot.
We have not tried the scheme above, however. That's a new one.
Have you tried it?
BP
|
|
|
Post by gb0101010101 on Apr 6, 2019 21:24:21 GMT -8
OK, thx for letting me know this was a pre-existing condition. I have not yet tried the "forced restart" method I mentioned. Since setting up my local OTA update server I have noticed that it fails many times. I do not know if this is WiFi connection issue or bug in restart. Have often needed to do REST 'updateOurWeather' 2 times to get latest firmware on the board. Looks like there is a difference between failed and successful updates in the reboot codes but I do not know what they mean or how to fix it.
|
|
|
Post by SDL on Apr 7, 2019 12:15:47 GMT -8
I would suspect that it is a combination of WiFi and the restart problem. Looking at this for an ESP32 project now.
BP
|
|
|
Post by gb0101010101 on Apr 8, 2019 8:51:14 GMT -8
Right I think it is related to Wifi not disconnecting too. That is the forceful restart code tries to do: Put Wifi to sleep, Rested Watchdog timer to get rid of any hanging ops, issue the restart request, and then try to kill anything in watchdog so that the restart takes place ASAP.
BTW I think this is a ESP8266 issue and not a problem on ESP32.
|
|
|
Post by gb0101010101 on Apr 8, 2019 20:08:21 GMT -8
|
|