ESP8266: freeRTOS plus Arduino?

smurfix · April 10, 2022, 5:07pm

Hello,
On ESP32, framework=Arduino, the main loop runs on top of FreeRTOS, whose features can basically be used freely.
On ESP8266 there’s an Arduino framework and a separate FreeRTOS framework. Is there any way to combine the two?

Background: I have this program here which uses both Arduino- and FreeRTOS-style code quite freely. It works on ESP32, but I need to run it (or as much of it as will fit) on an ESP8266.

maxgerhardt · April 10, 2022, 6:03pm

Devs say ‘no’.

github.com/esp8266/Arduino

Migrate core from NONOS SDK to FreeRTOS SDK

opened 08:17PM - 19 Feb 19 UTC

devyte

## Problem Description We recently encountered issues with the latest pre3 NO…NOS 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.

Possible for sure, but it would need a large amount of effort.

rmm1 · April 11, 2022, 1:12am

It looks like the ESP8266_RTOS_SDK has been abandoned without anyone saying goodbye.

It’s been a year since the most recent release. The activity graph of the main branch has gone flat.

smurfix · April 11, 2022, 2:09am

The fact that there even is a separate SDK for it is rather annoying IMHO. If you want a sustainable ecosystem, you create one SDK. Then you write an open-source shim layer to adapt it to FreeRTOS mainline (where necessary) / add support for it to FreeRTOS mainline (where possible).

Presto, somebody else can do the same thing for any other RTOS.

Actually, now that I think of it, right now my best bet (assuming I want to spend that much effort, which is still up in the air) seems to be to replace the FreeRTOS-specific bits and pieces in the code I’m adapting with RIOT-specific bits and pieces. RIOT has an Arduino shim, so it’ll support the Arduino-ish parts without ripping those out also, and it runs on top of FreeRTOS (ESP32) as well as on bare metal (ESP8266). The problem is that platformio doesn’t support it (yet(?)); see RIOT-OS support · Issue #3456 · platformio/platformio-core · GitHub

raul-parada · April 17, 2023, 8:37pm

Is there any update?

alexcajas · October 28, 2023, 2:13pm

Hi! here an update, I recently published an arduino core for esp8266 based on RTOS_SDK (GitHub - espressif/ESP8266_RTOS_SDK: Latest ESP8266 SDK based on FreeRTOS, esp-idf style.), it is a lightweight version of FreeRTOS maintained by espressif that shares idf framework with FreeRTOS for esp32. The project is still in development, but for now you can use the FreeRTOS concurrency tools, basic esp32 arduino core Wifi libraries such as WebServer or HttpClient and others such as ESP32Time using the Arduino environment to develop and install your sketchs on an esp8266.

You can find the core at: GitHub - alexCajas/esp8266RTOSArduCore: This project delivers an Arduino core for the ESP8266_RTOS_SDK, a light version of FreeRTOS supported by espressif. Notably, it shares the same framework as the ESP32 Arduino core, ensuring compatibility with libraries designed for the ESP32 arduino core and advanced multitasking capabilities.

Please don’t hesitate to leave feedback and report issues! It will leave me to improve the core!