@@ -417,5 +417,28 @@ In this real life example we have some longer responsetimes which means it doesn
// - How would an ideal tool for static analysis of RTIC models look like.
//
// [Your ideas and reflections here]
/*
- RTIC and scheduling overhead
The re-scheduling OH in RTIC is ~180 cycles when running a mix of lower and higher prio tasks.
This is very low and is a very fair tradeof for what you get.
If you run the re-scheduler on a timestamp when there is no other tasks, you will see that the re-scheduler will finish much bellow 180 cycles_
The differnce in excection time for this procedure can make it hard to estimete WCET for the task.
The question is if it is possible to make this a constant time operation? And in that case, how?
I don't have the answers for this but it's an interesting thought.
- Coupling in between theoretical model and measurements
The OH of the context switching, preemption check and re-schedueling will give you a differense from the theoretical values deffined_
Basically the formula for the actual response time becomes_
R(t) = I(t) + B(t) + C(t) + OH(t)
- How would an ideal tool for static analysis of RTIC models look like.
It's a bit hard to make a educated guess without having in-depth knowledge about how the preemption check is implemented.
But my thoughts are that you would measure the WCET of the preemption check and re-scheduling (when using multiple tasks) and combine it with the OH for the context switching.
This would give you a static value that you can add to your response time during analysis.
These values would then be combined with the WCET of the User code to give you the WCET of the entire task.
*/
//
// Commit your thoughts, we will discuss further when we meet.
