Nodemcu-firmware: FYI: non-OS SDK soon EOL(?)

[marcelstoer]

I have the feeling Espressif will declare the non-OS SDK EOL in the not too distant future. On several occasions developers we're "encouraged" to use the RTOS SDK instead when they reported issues against the non-OS SDK. One example: https://github.com/espressif/ESP8266_NONOS_SDK/issues/192#issuecomment-445102901

[jmd13391]

If it does go EOL, what does that mean for NodeMCU?

[TerryE]

It may be EOL, but we don't have enough RAM on the ESP8266 to run NodeMCU+RTOS. EOL in this case means that they aren't going to be adding new features to the non-OS SDK, but to be honest I can't think of any material changes that actually would benefit in recent releases that would benefit NodeMCU application developers.

[jmd13391]

Long live the ESP8266 NodeMCU Firmware! :-)

[marcelstoer]

If it does go EOL, what does that mean for NodeMCU?

We don't even know _if_ it goes EOL, let alone _when_. I only raised this issue to prepare our community that it might happen as I was noticing such signals.

Other than that I fully agree with Terry's statements. We can hopefully complete #2468 in the upcoming months. Then we'll just see what plans Espressif has for the non-OS SDK.

[TerryE]

I agree. It makes sense to go to 3.0.

[dtran123]

I am pretty happy with the SDK 2.2.1...let alone the improvement in RAM planned in SDK 3.0 (which I am super eager to try out despite any performance tradeoffs resulting from that). Personally not too concerned by the threat of EOL. Believe we reached the point of diminishing returns here. Probably better to migrate our energies to the ESP32 for larger applications.

[jmd13391]

ESP32 is not a replacement for the ESP8266. Each has its niche... especially if you factor-in cost when making the jump from your bench to an actual marketable product.

"Real" developers get 'er done in 45K. LOL :-)

[TerryE]

The V3 RAM savings only work for a limited class of very code-lean applications. The Lua VM (and doubly so if you want to load the TLS / SSL code to process HTTPS) just won't perform adequately with this. It really needs the 32Kb instruction cache.

I've got some pretty complex IoT apps and non need anything like 45Kb.

[dtran123]

@jmd13391 , Agree with you. That's why I said "ESP32 for larger applications" (requiring more RAM). I am planning to use the smaller brother ESP8266 for many many applications. I think the price difference is still significant (in volume) to justify the continued use of the smaller brother. To each its usecases!

[dtran123]

@TerryE , I do hope that with the V3 RAM savings tradeoffs with performance will not be a show stopper in some time critical workflows such as TLS negociations. There may be a need to increase somembedtls and/or https timeout settings but I do hope that we can live with the tradeoffs while opening new doors (e.g. more TLS cipher suites support, etc.)

I also hope that with V3 RAM optimizations, the user can tweak the instruction cache size (at compile time). For some applications, a value somewhere in the middle of 16 and 32 KB would be a good balance (e.g. 24KB). I am thinking "just enough to make my usecase pass the out of memory barrier". So no need to be extreme by setting to its lowest 16KB.

[TerryE]

I do hope that ...

Sorry, I just said: yes, it's a show-stopper. You can have 0, 16 or 32 Kb cache, and the Lua VM is pretty much unusable with a 16Kb cache.

[marcelstoer]

It's just been confirmed, buried in a GH comment: https://github.com/espressif/ESP8266_NONOS_SDK/issues/205#issuecomment-450778592