122 lines
3.9 KiB
Markdown
122 lines
3.9 KiB
Markdown
Yann Sierro - Rémi Heredero
|
|
|
|
AdvEmbSoft/HESSO-Master/2024
|
|
|
|
# BikeComputer
|
|
This is a project done in the course of AdvEmbSoft during the master's degree. It contains a program for spinning bikes.
|
|
|
|
# Configuration
|
|
## Libraries
|
|
Add disco libraries :
|
|
|
|
```terminal
|
|
mbed add https://github.com/SergeAyer/DISCO_H747I.git
|
|
```
|
|
Add sensor libraries :
|
|
|
|
```terminal
|
|
mbed add https://github.com/SergeAyer/advdembsof_library.git
|
|
```
|
|
|
|
Test sensor libraries :
|
|
```terminal
|
|
mbed test -m DISCO_H747I -t GCC_ARM -n advdembsof_library-tests-sensors-hdc1000 --compile --run
|
|
```
|
|
|
|
## Run static scheduling
|
|
On `.mbedignore` put at the end of the file
|
|
```
|
|
static_scheduling_with_event/*
|
|
multi_tasking/*
|
|
```
|
|
|
|
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 :
|
|
```
|
|
static_scheduling_with_event/*
|
|
multi_tasking/*
|
|
```
|
|
|
|
On main.cpp include `"static_scheduling/bike_system.hpp"` and use :
|
|
```cpp
|
|
static_scheduling::BikeSystem bikeSystem;
|
|
bikeSystem.startWithEventQueue();
|
|
```
|
|
|
|
## Run static scheduling with event scheduling
|
|
On `.mbedignore` put at the end of the file
|
|
```
|
|
static_scheduling/*
|
|
static_scheduling_with_event/*
|
|
```
|
|
|
|
On main.cpp include `"multi_tasking/bike_system.hpp"` and use :
|
|
```cpp
|
|
multi_tasking::BikeSystem bikeSystem;
|
|
bikeSystem.start();
|
|
```
|
|
|
|
## Run multi-tasking
|
|
On `.mbedignore` put at the end of the file
|
|
```
|
|
static_scheduling/*
|
|
multi_tasking/*
|
|
```
|
|
|
|
On main.cpp include `"static_scheduling_with_event/bike_system.hpp"` and use :
|
|
```cpp
|
|
static_scheduling_with_event::BikeSystem bikeSystem;
|
|
bikeSystem.start();
|
|
```
|
|
|
|
# Some questions
|
|
## 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.
|
|
|
|
## 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.
|
|
|
|
# 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
|