Description

The current FSM implementation defines all the threads at the start, but only starts them when needed. This means that the priority is fixed from the start.

We want to see whether it’s possible (and if it’s good practice) to define threads as needed with a variable priority)

https://github.com/utat-ss/FINCH-CommandDataHandling/blob/main/1_FreeRTOS_FSM/Basic_FSM_Design/nucleo-h743zi2-FreeRTOS-v3/Core/Src/main.c

Implementation

A demo for dynamic priority has been implemented (based on the Basic FSM Design).

GitHub Link: https://github.com/utat-ss/FINCH-CommandDataHandling/tree/main/1_FreeRTOS_FSM/Dynamic_Thread_Priority_FSM_Design

There are 5 threads (excluding CommandHandler, CommandIdle, ThreadTerminator) in this FSM, namely Task 1a, 1b, 2, 3, 4. (Tasks are initialized by pressing the corresponding number keys)

Task 1a and Task 1b are passive threads that run forever (split from Task 1 in Basic FSM Design), initialized with the same priority (so the scheduler time slices between them). Their priority can be changed when Task 4 is being run.

Task 2 and Task 3 are follow through threads (inherited from Basic FSM Design). When complete, will reset the priority of Task 1a and 1b back to normal

Task 4 is a passive thread (newly added to FSM). When run, it checks if Task 1a and Task 1b have the same priority, and if so, increases the priority of Task 1a. Otherwise, it swaps the priorities of Task 1a and 1b so that the other task has the higher priority. The Task 1 with higher priority will preempt the other Task 1 and prevent it from running.

Expected Behaviour:

Initially, Task 1a and Task 1b are initialized with the same priority. (Press 1 on keyboard to run both tasks, the terminal will display which task is running)

When Task 4 run (by pressing 4 on keyboard), Task 1a’s priority is set to a higher value and will always preempt Task 1b. Only Task 1a will be running.

When Task 4 runs again, Task 1a and Task 1b switch priority. Task 1b will preempt Task 1a and only Task 1b will be running.