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 :

mbed add https://github.com/SergeAyer/DISCO_H747I.git

Add sensor libraries :

mbed add https://github.com/SergeAyer/advdembsof_library.git

Test sensor libraries :

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/*

On main.cpp include "static_scheduling/bike_system.hpp" and use :

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/*

On main.cpp include "static_scheduling/bike_system.hpp" and use :

static_scheduling::BikeSystem bikeSystem;
bikeSystem.startWithEventQueue();

Run static scheduling with event scheduling

On .mbedignore put at the end of the file

static_scheduling/*

On main.cpp include "static_scheduling_with_event/bike_system.hpp" and use :

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.

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