Exploring RTOS plugin possibilities

[martinus]

Decided to open a new topic on RTOS specifics that could be useful for specific plugins.

I have been reading quite a lot on FreeRTOS fundamentals the last couple of days.

Also build a first plugin to learn how RTOS could aid in running timing critical plugin tasks.
Timing critical in this context means a very smooth and consistent response to events or schedules.
(for things like high frequency pulse detection, ISR's would still be required)

Running a fast blinking LED without any interference from other tasks is fun to see at work:

Code: Select all

void P254_blinkLED( void * parameter ) {
  TickType_t xLastWakeTime;
  const TickType_t xFrequency = 50;
  xLastWakeTime = xTaskGetTickCount();
  boolean state = 0;
  pinMode(P254_LED, OUTPUT);
  while (true) {
    state = (!state);
    digitalWrite(P254_LED, state);
    vTaskDelayUntil( &xLastWakeTime, xFrequency );
  }
}

But a more useful option that i'm currently exploring is a handy LCD menu for safeboot or other runtime options.
To avoid that running other features will interfere with normal ESPEasy operation, the menu and it's launch actions will run from another RTOS task.
As I'm not planning to reinvent the wheel, work will be based on this library:https://github.com/tomsuch/M5StackSAM

The entire ESPEasy project was never build with being "ThreadSafe" in mind. And it looks not so "Easy" to make it so.
But RTOS could really add some value to specific plugins without to much work and risk if you take special care about addressing (updating) global datastructures and running global functions. The LCD menu will currently only run functions private to it's plugin so that should be safe...

[TD-er]

That's a nice topic to look into.
The ESP32 is now so well available and the prices are dropping, so it would really make sense to split time critical tasks to another core.
Or maybe the other way around, place blocking code on the "other core" so the rest will run as smooth as possible.

At least moving the web interface to another task is something that would really make sense, so running code in other tasks does not suffer as much from serving a web page as the current implementation does.

It would make sense to have these split into separate tasks:
- Handling CPlugin calls
- Handling NPlugin calls
- Handling Plugin calls
- Handling web interface
- Processing rules

These parts are already somewhat separated in the code, so these should be relatively easy to split.
Maybe even have their own copy of the settings and after each 'loop' each task can see if the settings have changed and need to be updated.
This will make the transition rather smooth and does push the need for proper locking a bit forward.

Then it could be a user setting to decide which of these RTOS tasks should be assigned to which core.

This will also eliminate the need for the scheduler we now use, as RTOS has its own scheduler, although I don't know yet what impact that may have.
So to start with, each task can have its own implementation of our scheduler.

[martinus]

The first experiments have left the crashing prototype stage and are actually working:

M5.png (675.85 KiB) Viewed 37743 times

Left picture shows the boot state after autodecting the devicetype based on flash stored Mac addreslist.
When the safebutton is pressed during boot, the system goes into the menu and that's using a separate RTOS task.
The menu can also be requested during normal operation and does not rely on ESPEasy because it's an RTOS scheduled task.

Well the menu is empty now, but it's just to illustrate what we can do in general. From here we could boot into safemode, change the LCD backlight level, show statistics and even start/stop/suspend/resume RTOS tasks, etc...

The webgui shows a list of RTOS tasks that are running on core 1:

RTOSInfo.png (37.31 KiB) Viewed 37743 times

Suspending task 1 puts ESPEasy on hold. Stopping it kills ESPEasy but the device still runs. It think it's even possible to restart ESPEasy without rebooting the ESP (?)

@TD: Looks like quite a challenge to start using the full potential of the RTOS SDK for ESPEasy. I don't even know if the "Arduino ESP32 Core" is threadsafe? Maybe everything now runs as a single task for a good reason. The RTOS features are exposed (not all of them unfortunatly), but likely to be used at your own risk

But it's certainly fun to start trying anyway

[martinus]

The ESP32 is now so well available and the prices are dropping, so it would really make sense to split time critical tasks to another core.
Or maybe the other way around, place blocking code on the "other core" so the rest will run as smooth as possible.

I don't thinks it's even needed to use core 0. It may also interfere with the core networking tasks.
My first experiments already show a very smooth and persistent experience because of the RTOS preemptive scheduler, just on a single core.

When looking at the fast blinking LED, i can't see any interference from accessing the webgui. Doing the same with the default 10persecond task makes a huge difference.

So choosing the ESP32 is not because of it's dual-core in the first place. Theoretically, a comparable result could be achieved on the single core ESP8266, but AFAIK there is no "Arduino Core" wrapped around the RTOS SDK for ESP8266.

[TD-er]

[...]
So choosing the ESP32 is not because of it's dual-core in the first place. Theoretically, a comparable result could be achieved on the single core ESP8266, but AFAIK there is no "Arduino Core" wrapped around the RTOS SDK for ESP8266.

That's the reason I made the timing stats page + logging, to track down the pieces of code in ESPEasy that take a lot of time, so we do achieve as multi-tasking feeling as much as possible.
The ESP8266 does have limited RAM, so task switching will take a lot of flash reads to move the code of the other thread in RAM.
So it will not be the same as on the ESP32.

[thalesmaoa]

Hi there, despite of being an old topic. This one is the best reference I could find so far about RTOS.

During some dev in espeasy code I've noticed an option called:

Enable RTOS Multitasking.

I've been working with CANBus (CAN) and one of their main advantages are reliability and error handling. I would love to know where I can find more info about RTOS and EspEasy. Perhaps I can implement CANOpen.

[TD-er]

I disabled it as it requires locking between structs to exchange among cores.
You can create RTOS threads, each with their own stack.
I do think you can create a separate task on a different core, however I do not think you should re-enable the ESPEasy RTOS flag as there is probably dead code which will cause all kinds of different issues.

[thalesmaoa]

Noted. I will not work with it. Thx

[TD-er]

Just keep in mind that not all ESP32-variants have multiple cores and on 'the other core' you're not alone as there is also WiFi running.