Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
R
rtic_f4xx_nucleo
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Package registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Niklas Lundberg
rtic_f4xx_nucleo
Commits
df457cd3
Commit
df457cd3
authored
4 years ago
by
Blinningjr
Browse files
Options
Downloads
Patches
Plain Diff
timing_exam 5)
parent
d477af96
No related branches found
No related tags found
No related merge requests found
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
examples/timing_exam.rs
+20
-0
20 additions, 0 deletions
examples/timing_exam.rs
with
20 additions
and
0 deletions
examples/timing_exam.rs
+
20
−
0
View file @
df457cd3
...
@@ -401,5 +401,25 @@ const APP: () = {
...
@@ -401,5 +401,25 @@ const APP: () = {
// - How would an ideal tool for static analysis of RTIC models look like.
// - How would an ideal tool for static analysis of RTIC models look like.
//
//
// [Your ideas and reflections here]
// [Your ideas and reflections here]
// RTIC has very little overhead compared to other solutions that use a thread based approach. In
// real time system it is very important that the overhead is small and that the system behavior is
// easy to predict. RTIC is very good at both, but the thread based approach is much worse in both
// aspects. It is much harder to follow the task execution order in a thread based system because
// it has less restrictions. It is also because it has less restrictions that the overhead is
// larger.
//
// From this exam it is clear that the theoretical model is very close to the measured results,
// but there are some small differences caused by the inaccuracy of machines that can make a big
// difference. These inaccuracies are extremely hard to account for because there are so many factors
// that can change the result. And as we can see from this exam a difference of just a couple of
// cycles can cause the result to be way different.
//
// I think the ideal tool would have to take the overhead into account in some way. The exact
// overhead is hard to know, thus i think the tool should give 2 sets of analysis. One that is the
// pure theoretical analysis and this could be seen as the lower bound. Then a second one that
// takes assumes that the overhead is large enough to cause the analysis to be different and this
// can be seen as the worst case. From this we could also get the needed overhead for the second
// analysis to happen. This gives a good understanding of the behavior of the system and how much
// overhead it tolerates before it becomes worse then it theoretically should be.
//
//
// Commit your thoughts, we will discuss further when we meet.
// Commit your thoughts, we will discuss further when we meet.
This diff is collapsed.
Click to expand it.
Edvin Åkerfeldt
@ironedde
mentioned in issue
#4
·
4 years ago
mentioned in issue
#4
mentioned in issue #4
Toggle commit list
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment