I am in process of understanding the Task Scheduler functions. For example I am working on 32-bit Infineon Aurix Tricore controller whose Task Schedulers are designed for 5msec. Now, if I design to run my application on 10msec task scheduler function instead of 5msec what kind of data I should be consider into account?
Such as impact on CPU run-time, CPU load analysis etc?
Like how my change of task scheduler at low level code impact the code execution.
On
In short, the smaller the task slice time, the smoother the multitasking will appear to the user. On the other hand, more task switches increases the time spent switching tasks instead of running them.
Longer times with many tasks means long time distance revisiting the same task (e.g., more jerky behavior).
(Note: I normally use 1ms task switches on very low end MCUs with very good results with around 5-10 total tasks.)
If you are changing the entire scheduler to be run on 10ms instead of 5ms , then whether the SW will be able to detect the changes in your system in time should be considered (For example, if you have sensors like environment temperature sensor , the probability of change in value in 5ms is extremely rare.But on the other hand if you are detecting something like wheel speed 10ms might be slow ).Similarly whether you can control the actuators to create the desired response in the system should be considered as well. If these two things are considered and provided task execution time (not the frequency) is within limits the CPU load will not be a problem.
Note: If your application has code which calculates delays under assumption that the task runs in 5ms , then this needs to be changed
On the other hand if you are adding a 10ms task in addition to a 5ms task.then you should consider the following
1.Adding a new time slice adds additional context switch operation which will add a delay.
2.Also based on the task's priority and preemptive/co-operative behavior, one task can block the other for some duration which can potentially create lag on the functionality or cause it to malfunction, but this is just a probability and need not happen as well .
3.Context stitch also means you need now to use some more stack area than before, based on your project utilization this may cause an issue
You need analyse your SW to come to conclusion on points 2 and 3.I have given some examples which could help in the analysis
Ex1: If execution time(not the frequency) of your 10ms task is negligible compared to execution time of your 5ms task ,then better option is to schedule this functionality also in 5ms as this will save you the context switch time as well as stack size.
Ex2: If execution time of your 10ms task is comparatively long and it is of lesser priority(and preemptible by 5ms task ) than the 5ms , it is better to have the functionality in 10ms task as this will help the 5ms task to finish its execution before its next slice.