ADD answer question 1

This commit is contained in:
fastium 2024-12-31 14:41:16 +01:00
parent f64b8bdd9a
commit 957860b2ff
2 changed files with 25 additions and 10 deletions

View File

@ -23,25 +23,25 @@ Test sensor libraries :
mbed test -m DISCO_H747I -t GCC_ARM -n advdembsof_library-tests-sensors-hdc1000 --compile --run
```
## Run static scheduling
## Run static scheduling
On `.mbedignore` put at the end of the file
```
static_scheduling_with_event/*
```
On main.cpp include `"static_scheduling/bike_system.hpp"` and use :
On main.cpp include `"static_scheduling/bike_system.hpp"` and use :
```cpp
static_scheduling::BikeSystem bikeSystem;
bikeSystem.start();
```
## Run static scheduling with event queue
On `.mbedignore` put at the end of the file :
On `.mbedignore` put at the end of the file :
```
static_scheduling_with_event/*
```
On main.cpp include `"static_scheduling/bike_system.hpp"` and use :
On main.cpp include `"static_scheduling/bike_system.hpp"` and use :
```cpp
static_scheduling::BikeSystem bikeSystem;
bikeSystem.startWithEventQueue();
@ -53,7 +53,7 @@ On `.mbedignore` put at the end of the file
static_scheduling/*
```
On main.cpp include `"static_scheduling_with_event/bike_system.hpp"` and use :
On main.cpp include `"static_scheduling_with_event/bike_system.hpp"` and use :
```cpp
static_scheduling_with_event::BikeSystem bikeSystem;
bikeSystem.start();
@ -63,7 +63,7 @@ bikeSystem.start();
## 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.
We observe a 100% usage because on each CPU cycle it compare if time is done.
## 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?`
@ -73,7 +73,7 @@ We can observe only a usage of 75% because the CPU is more on Idle with Thread s
## 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.
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?`
@ -84,7 +84,22 @@ We observe a light usage of 1% of CPU. The CPU is now sleeping all the time and
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.
# Multi-tasking
## Question 1
We have computed the elapsed time between the event is sent by the interruption until it is executed :
|Rtos priority |time |
|---|---|
|osPriorityBelowNormal |13 usecs |
|osPriorityNormal |13 usecs |
|osPriorityAboveNormal |13 usecs |
To abtain these values, we have to consider that there is a isr thread. He dispatchs all the events from the gear device and the reset device. The rest is processed by the main thread.
Main of the time, it meares these values. But sometimes, higher values can appear. These values doesn't change because there isn't often more than one event in the queue.
# Issues
When compile with GCC, the full loop of static scheduling is 2 to 3 ms faster than expected.
This problem doesn't occur if we compile with ARMC6.
As the acceptable delta is 2ms and the teacher test is done with GCC, we modify the delta on the test to be 3ms
As the acceptable delta is 2ms and the teacher test is done with GCC, we modify the delta on the test to be 3ms

View File

@ -66,7 +66,7 @@ BikeSystem::BikeSystem()
_resetDevice(callback(this, &BikeSystem::onReset)),
_speedometer(_timer),
_cpuLogger(_timer),
_isrEventThread(osPriorityNormal, OS_STACK_SIZE, nullptr, "ISR_Event") {}
_isrEventThread(osPriorityAboveNormal, OS_STACK_SIZE, nullptr, "ISR_Event") {}
void BikeSystem::start() {
tr_info("Starting Super-Loop with event handling");
@ -144,7 +144,7 @@ void BikeSystem::init() {
}
// enable/disable task logging
_taskLogger.enable(true);
_taskLogger.enable(false);
}
void BikeSystem::gearUpTask() {