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!

asoleyman · November 17, 2024, 7:00pm

Hello Alex

First special thanks for making these tools.
I try step by step instruction
for this line :
… This proccess is to link configuration of the esp8266RTOSCore with Arduino IDE, but idf tools needs a git repository in the sdk, so, download this project with git and copy the entire git repository to the arduino core installation directory, even .git directory. Tipically, you core installation will be in:
can you more explain about “idf tools” files source download and replace it to Arduino location .
remove all and place new or overwrite?

BTW : I try to install it on Arduino IDE 2.3.3 (on Windows) too.
This is error messages for both 1.0.2 & 1.0.3
Please help me with the installation if it’s possible for you.

Thank you.

Tool esp8266RTOS:xtensa-lx106-elf@8_4_0-esp-2020r3 already installed
Downloading packages
esp8266RTOS:esp8266RTOS@1.0.2
Installing platform esp8266RTOS:esp8266RTOS@1.0.2
Failed to install platform: ‘esp8266RTOS:esp8266RTOS:1.0.2’.
Error: 13 INTERNAL: Cannot install platform: installing platform esp8266RTOS:esp8266RTOS@1.0.2: extracting archive: Create link C:\Users\Admin\AppData\Local\Arduino15\tmp\package-986200152\esp8266RTOSArduCore-1.0.2\components\coap\libcoap\README: symlink README.md C:\Users\Admin\AppData\Local\Arduino15\tmp\package-986200152\esp8266RTOSArduCore-1.0.2\components\coap\libcoap\README: A required privilege is not held by the client.

maxgerhardt · November 17, 2024, 9:28pm

Something is trying to create a symlink, but on Windows symlinks are tricky or you have to have special permissions for them…

alexcajas · November 21, 2024, 12:12am

Hi @asoleyman,

Your issue comes from the IDE version. The recommended and tested latest version is 1.8x.

Arduino sets some configurations when you install SDKs from the IDE, so, to link the IDE with the esp8266RTOSArduCore SDK, it is necessary to download it from the IDE using the json_index. On the other hand, IDF tools for RTOS_SDK need a git repository to work correctly, so you need to add some git configuration to the SDK downloaded from the IDE. The easiest way to do this is to download esp8266RTOCore as a regular git repository and replace all information from the SDK downloaded from the IDE with the git repository, including the .git extension.

Well, Espressif doesn’t have good compatibility with Windows, so all of this is a workaround to develop under Windows, but the recommended way is to use a Linux distribution.