Dear Deouss,
in Germany we say "The tone makes the music".
So I grab all my politeness and try to explain, what seems so difficult to see for you.
First lets look why core without RTOS can make sense.
Here is the challenge:
1. Part
You get a rising edge at an external pin.
You have to set high an output line as an answer. The deadline for this answer is 200ns.
Pull up the line for 250 ns, then drop it down.
_____________________
_____| Input
__________
___________| |_____ Answer Output
+max + precise
200 250
ns ns
max: dealine
precise: +/- 10 ns
The Timings have to be exact !!! Do not tell: Oh, there was a taskswitch, an other external interrupt
with higher priority, ....
I am really interested in your solution!
Here is mine:
A RTOS-task created and pinned to core 1. Disable Interrupts for core 1. (As above)
And this task is able fulfill the demands:
uint32_t irq=0, lastIrq=0;
uint32_t st3, noww;
while(1) {
irq=REG_READ(GPIO_IN_REG) & (1<<12); // 12 is the input line
if (irq != lastIrq) { // 166 ns +/- 10 ns can be garanteed!
REG_WRITE(GPIO_OUT_W1TS_REG,(1<<5)); // pin 5 high reaction:
st3=myGetCycleCount(); // get actual cpu-cycles
lastIrq=irq;
noww=st3;
// do the pulse
while ((noww-st3)<(60-22)) { // 60=244 ns, 120 = 496 ns, 240 = 1.000 µs --- 240MHz
__asm__ __volatile__("esync; rsr %0,ccount":"=a" (noww));
}
REG_WRITE(GPIO_OUT_W1TC_REG,(1<<5)); // end pulse width: --> low
}
}
And it works - even if the RTOS on core 0 is running to hell - because it needs no tick nor taskswitch.
Please test it with a scope AND tell me, how YOU solved the challenge.
Not theoreticaly, but with a source so I can test it !!!
By the way. It is an RTOS task and can be treated as such - using (other than interrupts) the full API.
The concept of isolated CPUs in Linux preempt is very similar.
Well - your solution?
------
2. Part
You can use RTOS also cooperative !
CoopOS is much lighter, but a lot of programs / tasks from RTOS can be easily transformed to CoopOS tasks. So if RTOS is an OS then CoopOS is it as well. The major difference: it is perfect for fast reactions -
not so good in number crunching and yes: the high frequency of task switches use a lot of the CPU capacity. Its good for tasks, which should be called very often.
For example: NeoPixels do have a strict timing: 400/800ns. I built an RTOS task to manage:
Lightning and dimming a color from zero to 0xff and back in 1 second. Than the next color without a delay and so on. I have to stop interrupts for some µs to get it stable.
And with a lot of timer- and external interrupts the timing of RTOS gets more and more undeterministic.
If I transfer it to CoopOS it does'nt matter - interrupts are disabled there.
RTOS is freed from this task - and CoopOS can do much more.
With 250000 taskswitches per second running 10 Tasks and more you can do a lot - just in time.
And you can do a lot of things for wich you would need a lot of timers and interrupts using RTOS alone.
Running CoopOS as a task (without ticks) on one core means:
The most of RTOS API is useable! It is possible to transfer data in both directions.
Yes, there are sometimes real advantages using such a cooperative system.
For instance: An RTOS-Interrupt routine sends a signal to the CoopOS and to another task running on core 0 with:
taskSetSignalFIQ(12); // --> CoopOS
xQueueSendFromISR(gpio_evt_queue, &gpio_num, NULL); // --> RTOS
CoopOS running 12 tasks reacts faster and with less jitter.
Conclusion:
With ONE task on core 1 doing polling you can react much faster than with RTOS alone
or
You have a coopertive system on core 1 where the tasks can react faster - because of the high taskswitch frequency. And there is a simple rule:
Tasks, wich are called very often (but the work is done very fast) gets the highest priority.
No task should work longer than some microseconds.
An RTOS task with high priority will effectively stop all other tasks.
An other example: Rotary dial switches are simple to read: They have a clock pin and a data pin.
If clock changes level: read data pin. If data is low it is turned left, if data is high it is turned right.
That is the theory. Its easy: Interrupt on clock and then read data.
But: if you turn the dial very fast you get a lot of bounces. Hundreds. And with distances down to 500ns.
Ok, you can build some electronics to suppress bouncing. But we want to do it with software.
With CoopOS it is simple. Read the switch 5 times (or more) with the time distance set to 1ms with low priority. With taskswitches every 5 µs it's no matter. Even if there is a jitter of 1 ms ( hard to reach -it means 400 times a taskswitch occures with another task with higher priority is READY ) there is no problem and you get a reliable result.
With RTOS without interrupt: you will not get all events.
With interrupt: how to mange the bursts of interrupts from the bouncing rotary dial contacts ?
The philosopy behind CoopOS as an cooperative multitasking operatingsystem is other than that of an RTOS. But there is nothing - really nothing - that you can do with an RTOS, which you can not do with an cooperative OS.
Some things are no tso efficient, not so deterministic and the percentage lost for taskswitching is much higher- but some things are done much faster. With RTOS you can promise to start a task every 10 ms exactly.
With CoopOS you may have a jitter - from 5 to 50 µs. But you can promise, that this task is called 200 times within 10ms. And that is sometimes much better.
If you have a lot of (isolated) tasks which are not cooperative you need preemtion.
But in some embedded sytems the tasks DO a taskswitch, because they are ready for now. Or they delay for some time, or they wait for somthing. So you may see systems running an RTOS where a timed preempt will never happen - because all tasks behave cooperative in this sense.
What I mean is: Women can do things men cannot do - and vice versa.
And that is the same with RTOS and a cooperative Multitasker. Together they are better than one alone.
And the statement: Cooperative Multitasking could not be an OS is just nonsense. Period.
You will find a lot to this theme in the internet - and the reason is simple:
(Example for you, because you dont like cooperation
- a joke)
If you have 8 cores and 6 are ok to run the Linux - is it possible to run something different on 2 cores ?
It will happen - take it for sure.
If you get more cores it sometimes makes sense to isolate a core from the OS to do something else.
And I am sure: you will see a solution for the ESP32 to run the RTOS on core 0 alone to do all the things like wifi and internet and all the fine things you got drivers for- and be free to run somthing else on "App core" - within ONE year.
Whats about a bet?
And last not least an advice: if you do not understand or have not enough experience - the best way is to ask - and learn and test!
Scientists where sure until some years ago: Bumblebees are not able to fly, it is impossible - but look at them. Mankind needed thousands of years to understand how they do it
PS: Don't forget the challenge !