[freeRTOS Development Notes] pay attention to the priority value passed in when creating a task

1 Preface

Recently, bloggers are doing some projects to adapt freeRTOS. In short, they are migrating from other RTOS platforms to freeRTOS platform.
Since the previous codes are available, based on experience, we think that we only need to re encapsulate the interface of OSAL, and the upper logic should not be a problem in theory; But what we didn't expect is that we encountered some problems that we didn't consider before during the adaptation of OSAL layer.

2 problems encountered

This problem is mainly reflected in the interface call of creating tasks. The interface prototype of freeRTOS is:

BaseType_t xTaskCreate( TaskFunction_t pxTaskCode,
                            const char * const pcName,     /*lint !e971 Unqualified char types are allowed for strings and single characters only. */
                            const configSTACK_DEPTH_TYPE usStackDepth,
                            void * const pvParameters,
                            UBaseType_t uxPriority,
                            TaskHandle_t * const pxCreatedTask ) PRIVILEGED_FUNCTION;

Let's focus on the fifth parameter uxPriority, which specifies the priority of the task.
We all know that freeRTOS is scheduled based on task priority. The task priority specified when creating a task directly affects the real-time response of the task.
Earlier, we used AliOS, and the function component code also used AliOS's API for creating tasks:

/**
 * Create a task.
 *
 * @param[in]  task        handle.
 * @param[in]  name        task name.
 * @param[in]  fn          task function.
 * @param[in]  arg         argument of the function..
 * @param[in]  stack_buf   stack-buf: if stack_buf==NULL, provided by kernel.
 * @param[in]  stack_size  stack-size in bytes.
 * @param[in]  prio        priority value, the max is RHINO_CONFIG_USER_PRI_MAX(default 60).
 *
 * @return  0: success, otherwise: fail.
 */
int aos_task_new_ext(aos_task_t *task, const char *name, void (*fn)(void *),
                     void *arg, int stack_size, int prio);

In this way, there is a problem with the value of priority when converting the OS layer interface.
For example, the interface of AliOS passes in prio=60; Then 60 the incoming freeRTOS will have a problem. As a result, the newly created task can be scheduled, but the interface for creating the task cannot be returned.
The fundamental reason here is the priority definition of freeRTOS. The smaller the value, the lower the priority; Conversely, the higher the priority.

3 how to solve it

The solution is relatively simple, but it will be cumbersome.
We need to re evaluate the priority values of all created tasks and incoming tasks to determine whether each task is high priority or low priority.
For example, changing the above prio = 60 (low priority) to prio=0 or 1 can solve the problem.

4. Experience summary

For the abnormal priority value definition of freeRTOS, I summarized the definitions of other common RTOS and made a comparison to deepen understanding and memory:

RTOS name	Priority value range	Definition of priority value
freeRTOS	0 - (configMAX_PRIORITIES-1)	The lower the value, the lower the priority
AliOS	0 - 61	The lower the value, the higher the priority
uCOS	0 - OS_LOWEST_PRIO	The lower the value, the higher the priority
RT-Thread	0 - 255	The lower the value, the higher the priority
threadx	0 - (TX_MAX_PRIORITIES-1)	The lower the value, the higher the priority
huawei lite os	0 - 31	The lower the value, the higher the priority
Oneos	0 - (OS_TASK_PRIORITY_MAX-1)	The lower the value, the higher the priority
tencent tiny os	0 - (TOS_CFG_TASK_PRIO_MAX-1)	The lower the value, the lower the priority

Seeing this, we must sigh that there is only one file of freeRTOS. The smaller the value, the lower the priority!
I would like to remind you that if you migrate from other RTOS platforms to freeRTOS platform, you should pay special attention to the problem of lower priority value, otherwise it may lead to inexplicable problems.