nodemcu / nodemcu-firmware

Lua based interactive firmware for ESP8266, ESP8285 and ESP32
https://nodemcu.readthedocs.io
MIT License
7.66k stars 3.12k forks source link

Upgrade to latest SDK 3.0.x #3008

Closed marcelstoer closed 2 years ago

marcelstoer commented 4 years ago

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

TerryE commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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] commented 2 years ago

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.