Exploring RTOS plugin possibilities

Moderators: rtenklooster, Voyager, BertB, Stuntteam

Forum rules
You have entered the experimental forum, beware!!!
Post Reply
Message
Author
martinus
Normal user
Posts: 129
Joined: 15 Feb 2020, 16:57

Exploring RTOS plugin possibilities

#1 Post by martinus » 08 Apr 2020, 12:46

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
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Exploring RTOS plugin possibilities

#2 Post by TD-er » 08 Apr 2020, 14:11

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
Normal user
Posts: 129
Joined: 15 Feb 2020, 16:57

Re: Exploring RTOS plugin possibilities

#3 Post by martinus » 08 Apr 2020, 15:09

The first experiments have left the crashing prototype stage and are actually working:
M5.png
M5.png (675.85 KiB) Viewed 25223 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
RTOSInfo.png (37.31 KiB) Viewed 25223 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 :mrgreen:

But it's certainly fun to start trying anyway :ugeek:

martinus
Normal user
Posts: 129
Joined: 15 Feb 2020, 16:57

Re: Exploring RTOS plugin possibilities

#4 Post by martinus » 08 Apr 2020, 15:54

TD-er wrote: 08 Apr 2020, 14:11 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
Core team member
Posts: 8643
Joined: 01 Sep 2017, 22:13
Location: the Netherlands
Contact:

Re: Exploring RTOS plugin possibilities

#5 Post by TD-er » 08 Apr 2020, 22:18

martinus wrote: 08 Apr 2020, 15:54 [...]
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.

Post Reply

Who is online

Users browsing this forum: No registered users and 15 guests