Update of NONOS_SDK to 3.0.4+

[dirkmueller]

Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• I have tested that the issue is present in current master branch (aka latest git).
• I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• I have filled out all fields below.

Problem Description

It seems espressif has released a v3.0.4+ NONOS_SDK including some interesting sounding commits like

espressif/ESP8266_NONOS_SDK@cae7ba2

can we try another time to upgrade to a newer sdk? I don't know what steps or testing needs to be performed, happy to try out some things with some guidance.

[arihantdaga]

I would like to be a part of contribution, if someone can guide me or give some pointers.

[devyte]

At top level, I think the steps needed are along the lines of the below. If needed, this should be edited to reflect reality.

1. Download the new sdk and make the equivalent of the Blink app plus wifi connection. No core involved at all here.
   This serves 2 purposes:
   a. provides a reference binary to check against for plan A (this one)
   b. serves as a starting point for plan B (see below)
2. Starting with a git install of the core, replace the current sdk libs with the new. ones, one by one.
3. Try to build.
   a. Figure out any compiler errors, e. g. sdk api function signature changes
   b. There will be missing symbols errors on link, e. g. the flash partition table. Figure out the easy ones from the reference app above. Figure out the harder ones from doing inspecting and searching thea sdk lib symbols or. via. some other way.
4. Figure out which functions need to be in IRAM, which functions need to be moved to IFLASH.
5. Figure out memory alignment issues, if any.
6. Figure out any problems with exception handlers, e. g. we use different handlers than the sdk.
7. Assuming that after the above you get a functioning binary, test loops/sec. The last pre-3 sdk upgrade attempted showed a drastic decrease in loops/s. The current suspicion is that the slowdown was caused by a misaligned mem access to a 32bit aligned mem area which results in repeated calls to a misaligned access handler, which is slow.
8. Assuming all of the above is addressed, get all examples and device side tests to work correctly.

If the above steps hit an impassable wall, there's a plan B:
1. Start with the reference app above
2. Restructure the code to a format similar to our current core and toolchain. No setup/loop or any core code yet.
3. Implement the CONT/SYS context switching. One way to do this is the same approach as our current core, which isn't pretty, but it works. Another would be to use some cleaner way, such as setjmp/longjmp. In CONT, implement setup/loop.
4. Add parts of the lower code layers of the core little by little: wiring, uart, etc.
5. Integrate 3rd party upstream libs like lwip and bssl
6. Add the higher code layers of the core
7. Add special features like the 4K stack optimization, exception handlers, post mortem, etc
8. Test loops/sec, figure out any problems
9. Get all device tests and examples to work with the new core

[devyte]

There was a first attempt for plan A in #4853.

[midnight-wonderer]

Espressif is dropping support for NONOS_SDK, only critical bug fixes in the future.
No wonder some people just give up Arduino altogether.

I guess I have to make my choice too.

[5chufti]

as most of the releases didn't solve known problems but did bring new ones to discover, at leat the current situation promises a stable basis to learn living with and working around the existing bugs. If someone is concerned about any commercial fitness of the esp8266 arduino core now: it was a wrong strategic move from the start, independent from nonos or rtos based core.

[slonopotamus]

I believe this was fixed by #8736