Migrate core from NONOS SDK to FreeRTOS SDK

[devyte]

Problem Description

We recently encountered issues with the latest pre3 NONOS SDK that forced us to revert to 2.2.1, ref #5784. The issues in the NONOS sdk, and their potential solutions, are tracked there.

This issue is meant to track solving a higher-level dilemma, which is what to do about the NONOS SDK moving forward.
Espressif has explained that the NONOS SDK will be maintained for the time being, but likely not enhanced. Their plan seems to be to EOL it, as emphasis will be kept on the FreeRTOS SDK and its migration to be similar to esp-idf.

There are then several paths forward possible:

1. Migrate to NONOS SDK v3.x

Pros:

• Maintains status quo in our core as NONOS (continuity in the architecture)
• Should address the current SDK issue dilemma (sleep bug vs. stability)
• Keeps results of recent efforts to free available heap and other high profile improvements
• Potential to eventually have full control if the closed libs ever get reverse-engineered
• Buys us time (we can always change our minds and migrate to FreeRTOS later)

Cons:

• Not straightforward to migrate due to the introduction of partitions
• NONOS sdk is meant for EOL anyways, so direction is destined to be a dead end in the (possible far) future, unless the closed libs get reverse-engineered far enough

2. Migrate to a full FreeRTOS SDK (currently at v3.1)

Pros:

• Espressif seems to want to move in this direction, so support would be better than for NONOS sdk
• Availability of an underlying OS (tasks, threads, IPC, etc)
• Likely allows a better architecture design (2 contexts that are real contexts)

Cons:

• Most likely free available heap will be far less than with NONOS sdk
• Huge design effort: this SDK aims to be similar to esp-idf, but esp-idf is not well-suited for the ESP due to RAM constraints. That means that some architecture parts need to have a different design. (E.g.: too many OS tasks, and each requires its own stack and msg queue, lots of C-C++ interface points, etc)
• Huge migration effort: will require a full rewrite of a whole lot of the core code
• Probably less control over some parts, such as lwip/ssl

3. Migrate to a limited FreeRTOS SDK (no preemptive)

Pros

• May get us off NONOS SDK the fastest (or may not)

Cons:

• No guarantees of stability (in fact, the chances of a whole lot of new bugs and overall functional breakage is rather high)
• Huge effort
• We'll be on FreeRTOS, but it will be a gutted version of the OS (not real-time, cooperative, etc)
• Migrating to a full FreeRTOS architecture still means a complete rewrite of a lot of code (doing this limited migration could potentially be wasted effort)
• Likely less available heap

@d-a-v @earlephilhower @igrr and other maintainers: floor is open for discussion.

After thinking about this at length, my own preferences are as follows:

• Pursue option 1: migrate to SDK v3.x first. We can choose at a later time, once we have a stable core, to migrate to FreeRTOS, or continue on NONOS.
• Avoid option 3 at all costs. I consider it very risky with very little return, and I think that migrating to a limited version of the FreeRTOS will buy us the worst of all worlds, and at a high price at that.

[devyte]

If we are to move directly to the FreeRTOS SDK, there are some decisions to make. For starters:

1. Where will our home be?
   a. in our own repo, and import the FreeRTOS SDK repo to pick the libs/sources we need/want, like we currently do
   b. as a component in the FreeRTOS SDK repo
2. Which toolchain will we use?
   a. Build our own, like we currently do
   b. The toolchain provided by the FreeRTOS SDK repo, which comes from an Espressif server
3. Which upstream libs will we use (lwip, bearssl, freertos)?
   a. Pull and build our own versions from upstream, like we currently do
   b. Use those in the FreeRTOS SDK repo

[TD-er]

If Espressif is actually putting NonOS to EOL, is there still any reason for them to keep their core libraries closed?
And what does that say about the roadmap they plan to keep producing the ESP8266/ESP8285?
After all the ESP32 is way more powerful and has a lot more memory and its price is already quite acceptable for mass deployment.
Does the current install base of ESP82xx CPUs need a newer core platform if it is making some serious development next to impossible due to lack of free memory?
For example, does FreeRTOS support SSL and is thus taking so much heap, or is the lower free heap also effectively preventing SSL support?

And to play advocate of the devil, if it takes (really) a lot of effort of both the esp8266-Arduino team and the users to convert to an Arduino platform based on FreeRTOS, is there still demand for an Arduino implementation? Why would users then still want to move to Arduino/C++ if there is already a very fast growing MicroPython community?
After all, for beginners is Python much easier to learn than C++/Arduino.
So if a change will take a lot of time to implement and make it stable, including rendering lots of examples outdated, won't that move people away to other platforms?

I think those are just about as important questions in this discussion. (I take it as a discussion ;) )

[devyte]

@TD-er The following are my own personal answers and opinions:

Is there still any reason for them to keep their core libraries closed?

Yes. I don't agree with the libs being closed, but I don't see Espressif opening that code.

What does that say about the roadmap they plan to keep producing the ESP8266/ESP8285

They will keep producing it for a long time to come, that is not in question. The ESP32 is more powerful, even the simpler versions, but it is still higher cost than the ESP, and it has its own list of issues. Migrating to the ESP32 may be an option for many users, but it is not an option for a whole lot of commercial users. In those cases, migration means complete redevelopment.
In addition, the formal stance by Espressif, per my own understanding from reading their comments, is that the nonos sdk is being given low priority for now, and that users are being encouraged to migrate to FreeRTOS. There has been mention of EOL for the SDK, but there has also been mention of of a long support time still to come.
In contrast, the FreeRTOS sdk is being given high priority for fixes and enhancements. It is from this that I read the situation as Espressif trying to consolidate their development/maintenance efforts behind the FreeRTOS sdk.

does FreeRTOS support SSL

That is like asking whether the nonos sdk supports ssl. The support is provided by our Arduino core due to integration of bearssl, and not by the nonos sdk. In the case of FreeRTOS, there is ssl support as a component, but if we migrate to FreeRTOS sdk we'd evaluate whether we use that (wolfssl/mbedtls), or port our own bearssl integration.

is there still demand for an Arduino implementation?

yes, in fact support for a FreeRTOS-based core was requested a long time ago.

Why would users then still want to move to Arduino/C++ if there is already a very fast growing MicroPython community?

The MicroPython fw offers very little available heap for the user app. The last time I checked, it was something like 20KB less than our core. i think they still have a long way to go in that regard.

So if a change will take a lot of time to implement and make it stable ... won't that move people away to other platforms?

That may be, which is why I'm of the opinion we should achieve a stable nonos core version first, with all big issues resolved, and then freeze there. Once that happens, we should start development on the core based on FreeRTOS SDK

I'd like to clarify that this issue is not meant for a general discussion about the future of the ESP, or ESP vs. ESP32, or C++ vs. Py, etc. This issue is meant for discussing how we should proceed with our core development to assure that we have a viable path forward before the nonos sdk is EOL'd, should that happen. That means we should decide what to do and proceed accordingly ASAP.
We could stick with NONOS and reverse engineer the closed libs and achieve development freedom. Or we could migrate to FreeRTOS sdk and assure support. Or something else.

[hreintke]

The positive on using FreeRTOS is that compatibility with esp32 is improved/better possible.
Maybe even code sharing between the two frameworks, but application migration should benefit.

[TerryE]

HI, I am the lead Lua core developer on the NodeMCU firmware project. My purpose for posting here, very much as a guest, is just to note that we are going through very similar discussions, though our drivers are somewhat different in that the Lua VM (like the Python VM) imposes some heavy runtime constraints on our implementation options, so I am monitoring your discussions and I invite you to do likewise with ours.

As far as I can see at the moment (up to V3.0) the ESP8266 non-OS and RTOS variants use pretty much the same set of closed-source hardware abstraction libraries. It's just that RTOS has an extra layer over these to provide the normal RTOS services (tasks, threads, IPC, ...) and it uses a completely different make / build architecture.

Like the JS-based nodeRED, our Lua VM employs an intrinsically non-blocking, task-based, single threaded paradigm, so RTOS offers us little functional benefit, and indeed could give our less experienced module contributers plenty of scope to screw things up.

Pre 3.0 this was all moot since the ESP8266 simply didn't have enough RAM resource to run RTOS + Lua VM + sensible apps, but one of he things that Espressif has added to 3.0 is a variant of our non-aligned address exception handler (which they had initially ported to RTOS) and this allows pretty much all const data to be moved into flash. (This increased our available RAM by almost 30Kb when we first introduced it in 2016.) Now that the SDK libraries also use this, our builds have freed an extra 12Kb RAM, which might open the option of us moving to RTOS for us in the future. (Our main driver here is that our ESP32 variant is RTOS based, and this fork is causing us real maintenance overheads and problems.)

[earlephilhower]

Howdy, @TerryE . Thanks for the info!

....but one of [t]he things that Espressif has added to 3.0 is a variant of our non-aligned address exception handler...Now that the SDK libraries also use this, our builds have freed an extra 12Kb RAM....

And hence the big slowdown seen in loops/second in 2.2.x and pre3.0, potentially.

The exception handler is neat from a usability perspective, but with an 8-10x performance penalty when it hits vs. inline using the 32b-only accesses to PMEM space it is not so neat for performance.

Did we see a 12KB bump in heap free when going from 2.2.x to pre3, @d-a-v? I don't think I remember quite such a leap...

[d-a-v]

Moving from sdk2.2.1 to sdk-pre3 with an empty sketch or a simple web-server shows:

• + 1200 bytes in flash
• - 120 bytes in heap

We were not using real sdk-v3, but an intermediate version #5521.

[devyte]

Hello @TerryE , it has been a while. Welcome to the discussion here.
My initial dabblings with the ESP were with the Lua firmware, I actually learned the Lua language as a result, and I fully understand the development approach and timing restrictions you have.
After I migrated here, I've been (trying) to keep up with the discussions in your Lua repo, so I'm aware that we're in the same boat regarding the future of the NONOS sdk.

I saw that you pushed to migrate to post-v3 sdk. We migrated to the last version of the sdk prior to v3, because the partitions introduced in v3 are giving us headaches. At this point, we're deciding whether it's worth the effort to push through to a post-v3, or to migrate directly to an implementation based on some form of the latest FreeRTOS sdk v3.x.

could give our less experienced module contributers plenty of scope to screw things up

In addition to the long migration effort, this is one of the sticking points being discussed. The question has come up whether we really need a full FreeRTOS.

And here's what I find interesting: your current approach is event-driven, while ours is dual-context (similar to cofunctions), but in both cases there are timing restrictions. In your case, each task must be very short, while in our case the second context (aka CONT) must yield to the primary context (aka SYS) often enough.

My personal opinion, based on my experience with the Lua firmware, and with the Arduino firmware here, is that, if designed correctly, a firmware architecture implemented over the full FreeRTOS sdk would relax a whole lot of restrictions. My thinking is simple: Have two threads: one that handles the wifi stack and maybe TCP/IP communication, and the other running the user application.
In our case, the user application would be the CONT context.
I didn't get deep enough into the C-side of your Lua firmware, but I think that in your case the user application would be the Lua VM.

[TerryE]

And hence the big slowdown seen in loops/second in 2.2.x and pre3.0, potentially.

We don't see a big slowdown. That may be because the Lua VM is already a pretty fat Flash-based app. I also put in some instrumentation into our handler to collect exception hotspots - the old Pareto principle applies, and looked at these:

• The bootROM memxxx and strxxx routines are flash aware and will do word-aligned access so long as the data starts are word-aligned. Use -O2 rather than -Os and the xtensa GCC does this automatically.
• I added some inline asm access macros for some frequently accessed byte fields for structures often held in Flash. These removed the exception at a cost of an extra instruction per access.

Plus a few other tweaks and recodes. So in our case the exception handler didn't get called that much.

IMO, it's also important to avoid the temptation of dropping the icache from 32k to 16k, as we found that this did crater runtime performance.

I've only dabbled with the Arduino IDE using Atmel chips and not ESP ones, but I must admit that I don't see how this would mate well with a RTOS environment, but that is your business not mine. 😊

[JAndrassy]

I vote for "we should achieve a stable nonos core version first, with all big issues resolved, and then freeze there"

[kpishere]

I second that, RTOS on esp8266 has low value : conveniance for code base supporters at cost of runtime cycles and power for users (other developers). If this code base gets stable, it will be in use for years to come and id say even become a frame of reference for these other OSs that get promoted. Case in point: 68HC11 is still shipping! k.

…

On Mar 7, 2019, at 10:58, Juraj Andrássy ***@***.***> wrote: I vote for "we should achieve a stable nonos core version first, with all big issues resolved, and then freeze there" — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Jason2866]

@JAndrassy How to get there?

I vote for "we should achieve a stable nonos core version first, with all big issues resolved, and then freeze there"

You dont get fixes from espressif for NON OS SDK anymore (soon). So you will never have a version without big issues....

[Jason2866]

@TerryE In project Tasmota we see performance issues with pre 3.0. It is much slower than 2.2.1

[TerryE]

@TerryE In project Tasmota we see performance issues with pre 3.0. It is much slower than 2.2.1

Thanks for the heads-up. I'll do some benchmarking.

[kpishere]

Yes, the threat of no more fixes in future sounds very familiar. However, even it it were true, sometimes known bugs are things you just live with and work around. In the end, the imperfection is still predictable -- that is nearly everything.

[TerryE]

@TerryE In project Tasmota we see performance issues with pre 3.0. It is much slower than 2.2.1

I really can't think of a clear reason why this would be the case. We typically just don't spend that much time in the SDK library routines, and I would feel that Tasmota would be even less. Using -O2 as I mentioned above is important, and we also compile our own copy of the LWiP stack from the open-sourced version using this flag. As far as that inline extuitrick to avoid the exception handler overhead, then you might want to look at my blog entry on this.

[cziter15]

When RTOS based SDK can be expected? How much time will it cost approximately to migrate?

[d-a-v]

I will personally take a serious look to this when espressif/ESP8266_RTOS_SDK#635.

[cziter15]

Isn't it better to start migration process asap and give that as beta?

I mean espressif will probably provide WPA2 Enterprise example soon, so it will be easy to add as another beta version. There are 'fresh' exploits for WPA2 Enterprise authentication anyway:
https://github.com/Matheus-Garbelini/esp32_esp8266_attacks. That means WPA2 PSK is more secure than WPA2 Enteprise on ESP8266 for now.

Can I help you somehow starting this process? As you said NONOS is EOL, so why not start migration earlier?

[d-a-v]

That process will be an intensive work from anyone who knows the core (mainly but not only cores/esp8266/core_esp8266_*.cpp). So a great free time window is needed, and above all a good motivation. I am not speaking in the name of all current maintainers though.
Right now we are busy fixing bugs, stabilizing the soft part of the core for release 2.6 and there is still lot to do for this release that was initially planned for this week. Note that I think I can say I'm speaking in the name of current maintainers :)
Volunteers are always welcome to help fixing bugs https://github.com/esp8266/Arduino/milestone/10

[devyte]

The plan is to seek a stability point after core release 3, then code freeze. Or rather, code chill: only critical bug fixes allowed.
Once that happens, investigation on the freertos sdk will proceed, and assuming a clear path becomes evident where we can eventually reach similar optimizations* as we currently have, implementation will start.

As @d-a-v hints, the effort expected to migrate is huge. Don't expect anything remotely resembling pre-alpha-prototype-experimental-usethisandboom for a long time.

*It would make no sense to migrate to freertos if e.g. it's impossible to optimize enough free heap to run a secure server (about 20-25KB free heap minimum to allow handling just 1 client at a time)

[ericbeaudry]

I'm not that involved in the community but reading through this makes me worried about the future of this project. If you factor in that many will be like me and may start looking at alternatives for fresh project, I think your best bet is to support your current user base, the ones (like me) that have invested time in building solutions that work on nonos. Be clear on a roadmap that keeps them happy with updates for as long as you can. Then announce an EOL date of your own and move on to new havens... RTOS if that is the right thing at that point.

So, my user's perspective to this discussion in simple, I don't want to rewrite stuff that works. There's rarely any customer value in doing this. I'd rather spend time fixing stuff that doesn't work or add new features.

Regards!

[devyte]

I said:

investigation on the freertos sdk will proceed, and assuming a clear path becomes evident where we can eventually reach similar optimizations* as we currently have, implementation will start

That means that a path forward to FreeRTOS that reaches a point equivalent to where we are here could potentially not open. We won't know until investigation proceeds to a certain point.
Espressif has expressed commitment to support the NONOS SDK for a (long) while still. There is time.

Also, I have a plan B for NONOS, which I don't want to discuss publicly at this point. It also requires big effort and investigation, though. I am (slowly) looking for ways to move forward with it in parallel with everything else. It requires some specific skills, though.

[d-a-v]

Reference to espressif LTS? support announcement for nonos-sdk .

That said, we actively work on maintaining this core.
We will eventually switch to RTOS-SDK at least when we have no other choice.

[matthijskooijman]

So, my user's perspective to this discussion in simple, I don't want to rewrite stuff that works. There's rarely any customer value in doing this. I'd rather spend time fixing stuff that doesn't work or add new features.

Sounds like a decent argument, but in this case I think this is complicated by the fact that (AFAIU) the SDK's that are used are not open, so some things simply cannot be fixed by the community and can only be fixed by Espressif, which has indicated it does not want to further develop the NONOS SDK.

[kpishere]

I see an opportunity for people to get more into assembly programming here and to re-construct the espressif SDK. The options presented are not good. Re-creating the existing SDK whilst un-familiar territory is a learning opportunity that a) has the smoothest transition from not having to having, and b) retains the hard work of many directly in project. For a long time coming, I see the esp8266 fulfilling a need where esp32 just isn't needed. FreeRTOS on the esp8266 would simply obsolete it.

[Jason2866]

Since espressif does LTS support support (as already d-a-v wrote) i see no reason for a change. The actual core 2.7.4 runs very reliable and we have no issues (Project Tasmota) which can not be handeld in code. The only thing we change is the PWM code, which is not working good enough as it is now (solution is already there with PR7231 :-) ). The ESP8266 is dying in commercial products already (nearly none new TUYA device do use it). So the ESP8266 will be only a MCU for DIY projects soon.
IMHO for DIY projects the current Arduino ESP8266 version is a great and stable platform.
Doing a change to RTOS will need "some" time and a lot of work with a unknow result. Will it statisfy DIY wants/needs?

We all dont know which nice new MCU the future will bring? ESP32 will not replace the ESP8266. This train has left already.
Maybe the RTL8170 is the new ESP8266 soon.

[RudyFiero]

We all dont know which nice new MCU the future will bring?

For me the ESP32-S2-MINI-1 looks like a good replacement for the ESP8266. I have played around with the esp32-s2-saola board. I like the flexibility they have with pin mapping. Cost for the ESP32-S2 modules are barely more than the ESP-12. I didn't like the larger size of the released modules, but the MINI cuts it down to size.

[fabianoriccardi]

We all dont know which nice new MCU the future will bring?

Looking at espressif, ESP32-C3 could be a good replacement for ESP8266, and it will benefits of esp-idf, so it will be "natively" included in esp32-arduino core.

[TD-er]

We all dont know which nice new MCU the future will bring?

Looking at espressif, iESP32-C3 could be a good replacement for ESP8266, and it will benefits of esp-idf, so it will be "natively" included in esp32-arduino core.

Isn't that a completely different architecture? (different from the 'old' ESP32)

[fabianoriccardi]

It is based RISC-V, but from the official page, I can quote:

ESP32-C3 will be supported through Espressif’s popular ESP-IDF platform

and

ESP32-C3 provides so much at a cost that is close to that of ESP8266

So I think there are good chances to use esp32-arduino core for ESP32-C3, which relays on esp-idf.

[marcelstoer]

@Jason2866 @fabiuz7 @RudyFiero if I'm not mistaken you all gave a variation of the same argument - and I have to agree. Time will solve this issue as "no need to change anything". Over time people will migrated to ESP32-or-successor models supported by the ESP-IDF and demand for ESP8266-based software will dry up. Espressif offers LTS for NonOS-SDK. We should be safe.

[45gfg9]

There you mentioned, NonOS is coming to an end..
Sure, I'd really like to see it implemented on FreeRTOS for that multitasking.

[fabianoriccardi]

NonOS is coming to an end as well as ESP8266 is coming to an end. Recently Espressif has released ESP32-C3 and ESP32-C6 that seems way better (comparative table) than ESP8266 in pretty much every aspect. They are natively supported in esp-idf (so multitasking support is there from FreeRTOS) and hopefully in esp32-arduino core. If a project needs multitasking, probably these new MCUs are the way to go. For hobbyists and makers that like to tinker and learn about IoT, esp8266 will remain an excellent alternative.

[adam-ah]

@fabianoriccardi I'm unsure about 8266 being EOL. It's much cheaper than the ESP32 chips but in some cases equally capable, and requires less energy to run. The main limitation is actually the software support rather than being taken over by newer chips.

What I'm struggling to understand (and it might be just my ignorance) is that Espressif provides and maintains a full RTOS SDK for 8266. The main problem with that one is that you can't really use third-party libraries due to incompatibilities and the lack of Arduino components. On the other hand, it enables interrupting running tasks and creating threads (which is rather important in most almost all applications apart from a blinking LED).

Would that be (too) much work to add the Arduino features from this library to the RTOS SDK maintained by Espressif? Or, to turn the current library into a "component", and use it as a component with IDF? Or was this Option 2, and therefore, a lot of work?

As the idea came up over 2 years ago, it would be nice to understand where we are heading :)

[fabianoriccardi]

@adam-ah I think there is no intention to change the underlying SDK for this Arduino core.

If you need ESP8266 capabilities, you can look at ESP32-C3, which seems way better in every aspect, from cost to performance to power consumption, and it can be programmed with ESP32 Arduino core, which integrated FreeRTOS (support to threads).

I had benchmarked the Arduino JSON library on both MCUs here, and in general, esp32-c3 seems a bit better, even if this test represents a very narrow view of the computation capabilities of these MCUs.

Or was this Option 2, and therefore, a lot of work?

From what I have understood, implementing Arduino Core as components is an option inside Option 2, so a lot of work.

[adam-ah]

I think there is no intention to change the underlying SDK for this Arduino core.

Thanks, @fabianoriccard.

I had benchmarked the Arduino JSON library on both MCUs here, and in general, esp32-c3 seems a bit better, even if this test represents a very narrow view of the computation capabilities of these MCUs.

It's quite interesting. Did you get to measure the energy consumption of the boards?
Regardless, speed never seems to be the main issue on these embedded devices; or, in other words, I'm yet to see people complaining about speed as opposed to library issues, power consumption, etc.

Price is a problem, however; and it seems like the C3 costs roughly the same as the original ESP32 but it's generally hard to get (not as many sellers stock it). To me, the C3 seems like a bad middle-ground between a D1 mini (8266) and a 30-38 pin ESP32, but we are getting a little bit off-topic here :)

[fabianoriccardi]

I don't think it is really off-topic since newer and (eventually) better alternatives should be considered in this kind of discussion.

I don't know where you look at prices, but on Mouser I see the bare chip esp32-c3 at 0.89€, while the esp8266 is 1.36€. On LCSC, they cost about the same 0.75€.

About power consumption, the deep sleep mode should be 5uA on esp32-c3 and 20uA on esp8266. Of course, this is just a parameter. I can't say much on active states, apart from the quick test I performed on the official devkits here.

[thorrak]

Given this announcement from Espressif, is migrating to FreeRTOS SDK even an option?

Unless I'm mistaken, the lack of esp-idf support for ESP8266 means that even though the controllers may not be EOL, all of the software that runs on them now is.

[fabianoriccardi]

Given espressif/ESP8266_RTOS_SDK#1166 from Espressif, is migrating to FreeRTOS SDK even an option?

IMHO, this announcement is another point supporting the idea that we shouldn't move to FreeRTOS SDK. In the end of the story, the EOL of both SDKs weren't so different (the latest significant release of NONOS was in 2020-Jun while the latest of FreeRTOS was in 2021-Apr).

[metarutaiga]

I tried NONOS and FreeRTOS in my repository, it has fota / httpd / https / mqtt / ota / uart.

	NONOS	FreeRTOS
Memory	47K	74K (56K)
Binary	342K	356K

IDE: Xcode
Compiler: esp-clang v15.0.0

NONOS is difficult for me to develop because it's not open source.
and its espconn has very poor performance.

FreeRTOS is FAT, but FAT is not from FreeRTOS.
mbedTLS is FAT, and WPA3-SAE is need mbedTLS and Elliptic curve from mbedTLS.
It cannot use crypto from wpa_supplicant only.
If someone want to reduce binary size, WPA3-SAE must be disabled. (WPA3-SAE will increase 64K binary size)
esp-mqtt is FAT also, it alloc many memory (about 10K).
Some MD5 / SHA1 can be use from bootrom. (AES Te0 Td0 Td4s is in 0x40000000 region)

FreeRTOS has a big problem, GPIO ISR wouldn't be triggered at many WiFi areas.
espressif/ESP8266_RTOS_SDK#626

esp-clang supported xtensa-lx106-elf now, but less optimization for size.

[rguca]

At this point in time I don't think we will get esp-idf for esp8266.
We should focus on the latest SDK to get all features available because it will be probably the last.

@alexCajas made an Arduino core for ESP8266_RTOS_SDK
https://github.com/alexCajas/esp8266RTOSArduCore