To find, or even define, “best”, you need to define your exact requirements, and your “cost” model. Without those, we can only give “possible”, and maybe stumble on “good”.
I think it takes time to come to the optimal solution…
Initially, I thought about calling the timer every ms, but after listening to the advice, I realized that it was not cost-effective to just constantly call the timer callback so often.
At the moment, I have redesigned my functionality specifically for RTOS.
Now in one function I set the values of the time intervals I need, and then it starts the timer.
In turn, the timer launches another function that has its own algorithm, which each time sets the timer period for the next launch or stops it.
Remember that “Good Enough” IS “Good Enough”. Often you don’t NEED “optimal”, you always just need “Good Enough” (what meets the full specification). “Working Correctly” is more important that “Working Optimally”.
Each context switch to a new task cost some time (and power if you are worried about running on batteries), but if you are still running a surplus of that, it hasn’t become critical yet.
You do want to think a bit about what sorts of things have heavy costs, and try to avoid them. Things like checking EVERY millisecond is likely excessive for something that is “human scale”, as humans don’t work that fast, so slower is reasonable.
You are absolutely right)
I probably didn’t put it that way, but of course my goal is to do it right.
Don’t waste resources where they are not needed, but give these resources where they are really needed.