I am writing a simple RTOS i have some tasks the works with different frequencies and priorities each task is represented by a function void f1(void),..etc. f1 is higher priority than f2 and it interrupt its execution and when finished f2 continues. the question is how to calculate the actual execution of f1 and f2 without pauses? second question? is their anyway to calculate the worst case execution time of a functions?
There are no general way to compute the worst-case execution time, since a low-priority task can be starved forever.
To measure execution time you can have your task switching code keep track of timers/counters.
Or you may have your different threads own one LED each.
Have the threads turn on the LED when active and turn it off when calling a sleep function.
The blinking of the LED for the high-prio thread will directly represent each iteration of the loop it is running.
The blinking of the LED for the second most high-prio thread will also blink corresponding to the iteration of the inner loop. But you need to subtract the time when the high-prio LED is lit since then the high-prio thread have stepped in and is stealing time.
Same for lower-prio threads - more and more other threads that can step in and steal time. If any LED of higher prio is on, then you need to subtract that time from the pulse-length you measured for your low-prio LED.
Thanks but I want the scheduler to automatically calculate the fragmented execution time of any task or function and store it as "last execution time" for for this task block. Should I use RTC OR WHAT
Haven't you tabulated a list of all your available timing resources and then given them + or - for their advantages or disadvantages? What exact functionality does your specific RTC give you? Can it measure short enough times with the required resolution? Can it measure long enough times with the required resolution? Can it function as an RTC at the same time as you use it to measure time slices?
You - the designer - must be the one who keeps track of what resources you have, and what timing resolution they have, and what timing resolution you want/need for computing the length of the individual time slices. And what the shortest/longest time slices possible are. And what happens if/when the timing hardware overflows.
Note that some threads may consume a tiny sliver of time before returning back to calling one of the "wait" methods available, while some other threads may try to get as much time as possible requiring the OS itself to step in and force a task switch.
Next thing to consider - should you try to compute time spent in interrupts? If they aren't instrumented for the task, then it's likely that such measurements will consume a significant amount of additional CPU time. And what about time spent in system functions?
Being a software designer means that you must spend own time actually designing. Decisions you must make, based on your specific requirements. There are not any one single correct answer you can poll the world for - the difference between being a good or bad designer is just how often you'll select a route that is good enough, and how often you need to rework a bad choice. But it's still better to sometimes makes a bad decision compared to always expecting someone else to think for you.