Klagarge/BikeComputer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Activity

ADD answer to questions

Browse Source
This commit is contained in:
Rémi Heredero 2024-11-18 09:14:12 +01:00
parent f6f3d59ef3
commit 86e033fe2f
1 changed files with 21 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
README.md
View File

@ -60,8 +60,26 @@ bikeSystem.start();
```
# Some questions
## If you print CPU statistics at the end of every major cycle (in the super-loop), what CPU usage do you observe? How can you explain the observed CPU uptime?
## Question 1
`If you print CPU statistics at the end of every major cycle (in the super-loop), what CPU usage do you observe? How can you explain the observed CPU uptime?`
We observe a 100% usage because on each CPU cycle it compare if time is done.
## If you run the program after the change from busy wait to sleep calls, what CPU usage do you observe? How can you explain the observed CPU uptime?
## Question 2
`If you run the program after the change from busy wait to sleep calls, what CPU usage do you observe? How can you explain the observed CPU uptime?`
We can observe only a usage of 75% because the CPU is more on Idle with Thread sleep.
## Question 3
`If you run the static_scheduling_with_event program, what CPU usage do you observe? How can you explain the observed CPU uptime?`
We observe a light usage of 1% of CPU. The CPU is now sleeping all the time and doing small task only on event.
## Question 4
`When you run multiple tests for computing the response time of the reset event, what do you observe? Is there an improvement as compared to the static_scheduling::BikeSystem implementation?`
` - If you do not press long enough on the push button, the event may be missed and no reset happens.`
`Based on the program itself and on the task scheduling, explain these two behaviors. Explain also why such behaviors may be problematic.`
We notice, that we miss such less event when is event driven (or not at all). But with a static scheduling the response time is still long because the reset task is call with a certain period.