Daemon task and priority

Hello,

From FreeRTOSConfig.h

#define configMAX_PRIORITIES                16
#define configTIMER_TASK_PRIORITY      3

The range of available priorities is 0 to (configMAX_PRIORITIES – 1)
Questions:

  1. Why don’t we say available priorities is 0 to confgMAX_PRIORITIES ?
  2. Since Daemon Task would handle the ISR work should it’s priority be the highest among the tasks?

Why don’t we say available priorities is 0 to confgMAX_PRIORITIES ?

Because ready list is an array of size confgMAX_PRIORITIES which is indexed by priorities (and hence priorities are from 0 to confgMAX_PRIORITIES - 1) : https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/tasks.c#L344

Since Daemon Task would handle the ISR work should it’s priority be the highest among the tasks?

I am not sure what do you mean by the ISR work but yes, timer task usually should be of the highest priority if the application requires that the commands sent to the timer service task and expired timers get processed immediately. You can read more about FreeRTOS software timer here: FreeRTOS - RTOS software timer functionality and features description

Thanks.

1 Like

As Gaurav says, configMAX_PRIORITIES is the maximum number of discrete priorities, which are numbered 0 to configMAX_PRIORITIES-1. This is a very common 0 based indexing phenomenon.

configTIMER_TASK_PRIORITY is typically set to configMAX_PRIORITIES-1, because as you say it might be used for pending a function from an ISR (but it also might not be). It is not forced to be that because some systems might have tasks that are more urgent than the timers and pended functions. I would find the value of 3 out of 16 to be rather unusual, and you would need to ask (if possible) the designer that setup that program that way.

1 Like

configMAX_PRIORITIES sets the total number of priorities in the system, and as the lowest priority is 0 rather than 1, the highest priority is (configMAX_PRIORITIES – 1).

Any constant that starts “config” is for you to set, so you can set configTIMER_TASK_PRIORITY to the value needed by your application, and it is very common to set this to the highest possible priority. There are some applications that don’t want it to be that high though. Some of the FreeRTOS tests are probably a good example, where some of the internal timing checks can fail if the measured time gets extended because it got interrupted by the execution of a software timer at a higher priority.