Upgrade to latest SDK 3.0.x

[marcelstoer]

https://github.com/espressif/ESP8266_NONOS_SDK/releases/tag/v3.0.4 is possibly are more stable version of what we currently use.

[TerryE]

Marcel the current tag is 3.0.4. Here is the patch that rebases dev on 3.0.4. I have been trying it out and it seems fine so perhaps we can do this rebase before the next cut to master -- or do you prefer to leave it?

My preference would be getting this in as this is mostly minor bugfixes and no feature enhancements.

[marcelstoer]

I just went through the release notes 3.0.1 to 3.0.4. Each of them has new features some of which sound interesting e.g. for 3.0.2

• feat(wifi): Add Wi-Fi fast connect feature
• feat(mbedtls): Support SSL cipher suites SSL3.0
• feat(system): Store Wi-Fi parameter only when it is different from the one in flash

With Espressif you never know what you get...they certainly don't take semantic versioning seriously. I'd like to get our next master drop out the door as soon as possible. I stick by my proposal to drop everything from https://github.com/nodemcu/nodemcu-firmware/milestone/15 that is not a bugfix.

This one could then land right after we shipped our release.

[TerryE]

We need PR #3260 in before the drop as this is a priority bugfix, and I think that this is OK, given that 3.0.4 doesn't seem to impact this. In terms of your 3 bullets (1) is really valuable for sleep-based apps; (3) really helps prevent flash wear on the System Parameter area, so again helps extend ESP module life. (2) doesn't impact us yet as we have forked LWiP and mbedtls. Note that @nwf has plans to rebaseline these components against the current Espressif versions or better revert to the Espressif versions now that they are open and in github.

PS. For those that are interested here are the relevant release notes for 3.0.1, 3.0.2, 3.0.3 and 3.0.4. I support Marcel's recommendation that we do a 3.0.x rebaseline soon.

[nwf]

I have no concrete plans, sadly; the situation is terrible but yes, in the fullness of time, either we should give up and move to upstream's RTOS for ESP8266 (which is not EOL and has a more modern LwIP in it, but apparently consumes more heap out of the box) or we suffer, as the Arduino project suffers, through https://github.com/d-a-v/esp82xx-nonos-linklayer . I have not begun either and so nobody should consider attempting either as intruding on anything I'm doing. ;)

[TerryE]

Sorry Nathaniel, I don't think that we'll every have an ESP8266 RTOS version. There isn't enough heap left to be really usable.

[nwf]

So, as an experiment, I just went and built the RTOS wifi getting-started station example, which brings up at least enough of the WiFi engine and the LwIP stack to do DHCP. Even with the full icache setting, it still reports 57308 heap bytes free (using esp_get_free_heap_size) after getting its IP address. This is, of course, without any Lua linked in or running, but at a glance lua.cross has 8K of .data and a few hundred bytes of .bss on a 64-bit machine, so I'd hope it weighs in at less than 10K heap requirements unto itself. I know I keep harping on this, but... what more am I missing?

It'd be super nice to move over to the supported RTOS branch and get a little bit closer to having a unified tree with ESP32 again (and I keep hoping that we could extract the NodeMCU Lua engine and wire it on to other platforms, too...)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.