ADD answer question 1

README.md

@@ -84,6 +84,21 @@ 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.

multi_tasking/bike_system.cpp

@@ -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() {