Shulou(Shulou.com)06/01 Report--

Today, the editor will share with you the relevant knowledge about the method of FreeRTOS real-time operating system kernel configuration. The content is detailed and the logic is clear. I believe most people still know too much about this, so share this article for your reference. I hope you can get something after reading this article. Let's take a look at it.

The FreeRTOS kernel is highly customizable and is customized using the configuration file FreeRTOSConfig.h. Every FreeRTOS application must include this header file, and the user tailors the custom FreeRTOS kernel according to the actual application. This configuration file is for the user program, not the kernel, so it is generally placed in the application directory, not in the RTOS kernel source directory.

In the downloaded FreeRTOS package, each demo routine has a FreeRTOSConfig.h file. The configuration files of some routines are older and may not contain all valid options. If an option is not specified in the configuration file, the RTOS kernel uses the default value. A typical FreeRTOSConfig.h configuration file is defined below, followed by a description of each parameter in it.

# ifndef FREERTOS_CONFIG_H#define FREERTOS_CONFIG_H/*Here is a good place to include header files that are required acrossyourapplication. * / # include "something.h" # define configUSE_PREEMPTION 1#define configUSE_PORT_OPTIMISED_TASK_SELECTION 0#define configUSE_TICKLESS_IDLE 0#define configCPU_CLOCK_HZ 60000000#define configTICK_RATE_HZ 250#define configMAX_PRIORITIES 5#define configMINIMAL_STACK_SIZE 128#define ConfigTOTAL_HEAP_SIZE 10240#define configMAX_TASK_NAME_LEN 16#define configUSE_16_BIT_TICKS 0#define configIDLE_SHOULD_YIELD 1#define configUSE_TASK_NOTIFICATIONS 1#define configUSE_MUTEXES 0#define configUSE_RECURSIVE_MUTEXES 0#define configUSE_COUNTING_SEMAPHORES 0#define configUSE_ALTERNATIVE_API 0 * Deprecated! * / # define configQUEUE_REGISTRY_SIZE 10#define configUSE_QUEUE_SETS 0#define configUSE_TIME_SLICING 0#define configUSE_NEWLIB_REENTRANT 0#define configENABLE_BACKWARD_COMPATIBILITY 0#define configNUM_THREAD_LOCAL_STORAGE_POINTERS 5/*Hook function related definitions. * / # define configUSE_IDLE_HOOK 0#define configUSE_TICK_HOOK 0#define configCHECK_FOR_STACK_OVERFLOW 0#define configUSE_MALLOC_FAILED_HOOK 0/*Run time and task stats gathering related definitions. * / # define configGENERATE_RUN_TIME_STATS 0#define configUSE_TRACE_FACILITY 0#define configUSE_STATS_FORMATTING_FUNCTIONS 0/*Co-routine related definitions. * / # define configUSE_CO_ROUTINES 0#define configMAX_CO_ROUTINE_PRIORITIES 1/*Software timer related definitions. * / # define configUSE_TIMERS 1#define configTIMER_TASK_PRIORITY 3#define configTIMER_QUEUE_LENGTH 10#define configTIMER_TASK_STACK_DEPTH configMINIMAL_STACK_SIZE/*Interrupt nesting behaviour configuration. * / # define configKERNEL_INTERRUPT_PRIORITY [dependent of processor] # define configMAX_SYSCALL_INTERRUPT_PRIORITY [dependent on processor and application] # define configMAX_API_CALL_INTERRUPT_PRIORITY [dependent on processor and application] / * Define to trap errors during development. * / # define configASSERT ((x)) if ((x) = = 0) vAssertCalled (_ _ FILE__, _ _ LINE__) / * FreeRTOS MPU specific definitions. * / # define configINCLUDE_APPLICATION_DEFINED_PRIVILEGED_FUNCTIONS 0/*Optional functions-most linkers will remove unused functions anyway. * / # define INCLUDE_vTaskPrioritySet 1#define INCLUDE_uxTaskPriorityGet 1#define INCLUDE_vTaskDelete 1#define INCLUDE_vTaskSuspend 1#define INCLUDE_xResumeFromISR 1#define INCLUDE_vTaskDelayUntil 1#define INCLUDE_vTaskDelay 1#define INCLUDE_xTaskGetSchedulerState 1#define INCLUDE_xTaskGetCurrentTaskHandle 1#define INCLUDE_uxTaskGetStackHighWaterMark 0#define INCLUDE_xTaskGetIdleTaskHandle 0#define INCLUDE_xTimerGetTimerDaemonTaskHandle 0#define INCLUDE_pcTaskGetTaskName 0#define INCLUDE_eTaskGetState 0#define INCLUDE_xEventGroupSetBitFromISR 1#define INCLUDE_xTimerPendFunctionCall 0Universe * Aheader file that defines trace macro can be included here. * / # end if/* FREERTOS_CONFIG_H*/1.configUSE_PREEMPTION

RTOS uses a preemptive scheduler for 1, and RTOS uses a collaborative scheduler (time slice) for 0.

Note: in the multi-task management mechanism, the operating system can be divided into two types: preemptive and collaborative. A collaborative operating system is a task that actively releases CPU and then switches to the next task. The timing of task switching depends entirely on the task you are running.

2.configUSE_PORT_OPTIMISED_TASK_SELECTION

Some hardware running FreeRTOS has two ways to choose the next task to perform: generic methods and hardware-specific methods (hereinafter referred to as "special methods").

General method:

ConfigUSE_PORT_OPTIMISED_TASK_SELECTION is set to 0 or the hardware does not support this special method.

It can be used on all hardware supported by FreeRTOS.

It is completely implemented in C, and its efficiency is slightly lower than that of special methods.

Do not impose a limit on the maximum number of available priorities

Special methods:

Not all hardware supports it.

ConfigUSE_PORT_OPTIMISED_TASK_SELECTION must be set to 1.

Rely on one or more architecture-specific assembly instructions (usually similar to the computational leading zero [CLZ] instruction).

It is more efficient than the general method.

It is generally mandatory to limit the maximum number of available priorities to 32.

3.configUSE_TICKLESS_IDLE

Set configUSE_TICKLESS_IDLE to 1 to enable low-power tickless mode and keep the system beat (tick) interrupt running for 0.

In general, FreeRTOS calls back the idle task hook function (which needs to be implemented by the designer), and sets the microprocessor to enter low-power mode in the idle task hook function to achieve the purpose of power saving. Because the system has to respond to the system beat interruption event, using this method will periodically exit and then enter the low-power state. If the system beat interrupt frequency is too fast, most of the power and CPU time will be consumed in the low power state of entry and exit.

FreeRTOS's tickless idle mode stops periodic system beat interruptions during idle cycles. Stopping the periodic system beat interruption can make the microcontroller in low power mode for a long time. The transplantation layer needs to configure an external wake-up interrupt to wake up the microcontroller from low-power mode when the wake-up event arrives. After the microcontroller wakes up, it will re-enable the system to interrupt the beat. Because the system beat counter stops after the microcontroller enters the low power consumption, but we need to know how many system beat interrupt cycles this time can be converted into, it requires an external clock source that is not affected by low power consumption, that is, it is also timing when the microprocessor is in low power mode. In this way, when the system beat is restarted, an adjustment value can be calculated according to this external timer and written into the RTOS system beat counter variable.

4.configUSE_IDLE_HOOK

Set to 1 to use free hooks (Idle Hook is similar to callback functions), and 0 ignores free hooks.

When the RTOS scheduler starts working, in order to ensure that at least one task is running, idle tasks are automatically created with the lowest priority (priority 0). For RTOS tasks that have been deleted, idle tasks can free up stack memory allocated to them. Therefore, in your application, you should pay attention to ensuring that idle tasks get a certain amount of processor time when using the vTaskDelete () function. In addition, idle tasks have no other special functions, so they can arbitrarily deprive the processor time of idle tasks.

Applications may also share the same priority as idle tasks.

The idle task hook is a function that is implemented by the user. RTOS specifies the name and parameters of the function, which is called during each idle task cycle.

To create an idle hook:

Set the configUSE_IDLE_HOOK in the FreeRTOSConfig.h file to 1

Define a function with the function name and parameters as follows:

Void vApplicationIdleHook (void)

This hook function cannot call API functions (such as vTaskDelay (), queues with blocking time, and semaphore functions) that cause idle task blocking, and the use of co-routines within the hook function is allowed.

It is common to use the idle hook function to set CPU into power-saving mode.

5.configUSE_MALLOC_FAILED_HOOK

Whenever a task, queue, or semaphore is created, the kernel uses a function called pvPortMalloc () to allocate memory from the heap. The official download package contains five simple memory allocation strategies, which are saved in the source files heap_1.c, heap_2.c, heap_3.c, heap_4.c, and heap_5.c. The macro configUSE _ MALLOC_FAILED_HOOK makes sense only if you use one of these five simple strategies.

If the malloc () failed hook function is defined and configured correctly, it will be called when the pvPortMalloc () function returns NULL. NULL is returned only if FreeRTOS finds that there is not enough heap memory in response to a memory allocation request.

If the macro configUSE _ MALLOC_FAILED_HOOK is set to 1, then a malloc () failed hook function must be defined, and if the macro configUSE _ MALLOC_FAILED_HOOK is set to 0reginal malloc () the failed hook function will not be called, even if it is already defined. The function name and prototype of the malloc () failed hook function must be as follows:

Void vApplicationMallocFailedHook (void); 6.configUSE_TICK_HOOK

Set to 1 to use the time slice hook (Tick Hook), 0 ignores the time slice hook.

Note: time slice hook function (Tick Hook Function)

Time slice interrupts can periodically call an application called a hook function (callback function). The time slice hook function can easily realize a timer function.

The time slice hook can be used only if configUSE_TICK_HOOK is set to 1 in FreeRTOSConfig.h. Once this value is set to 1, define the hook function with the function name and parameters as follows:

Void vApplicationTickHook (void)

The vApplicationTickHook () function is executed in the interrupt service program, so this function must be too short to use a lot of stacks, and can only call API functions that end in "FromISR" or "FROM_ISR".

There are routines that use the time slice hook function in the crhook.c file under the FreeRTOSVx.x.x\ FreeRTOS\ Demo\ Common\ Minimal folder.

7.configCPU_CLOCK_HZ

Write to the actual CPU kernel clock rate, that is, the frequency at which CPU instructions are executed, commonly referred to as Fcclk. This value is configured to correctly configure the system beat interrupt period.

8.configTICK_RATE_HZ

The frequency of beat interruptions in the RTOS system. That is, the number of interrupts in a second, and each interrupt RTOS will schedule tasks.

System beat interruptions are used to measure time, so the higher the measurement frequency means the higher the resolution time can be measured. However, a high system beat interrupt frequency also means that the RTOS kernel takes up more CPU time, thus reducing efficiency. RTOS demo routines all use the system beat interrupt frequency of 1000HZ, which is to test the RTOS kernel, which is higher than the actual use. (do not need such a high system beat interruption frequency in practical use)

Multiple tasks can share a priority, and the RTOS scheduler shares CPU time for tasks of the same priority, switching tasks when each RTOS system beat is interrupted. A high system beat interrupt frequency reduces the "time slice" duration assigned to each task.

9.configMAX_PRIORITIES

Configure the number of priorities valid for the application. Any number of tasks can share a priority, and using collaborators can give them priority individually. See configMAX_CO_ROUTINE_PRIORITIES.

In the RTOS kernel, each valid priority consumes a certain amount of RAM, so this value should not exceed the number of priorities actually required by your application.

Note: task priority

Each task is assigned a priority with a priority value ranging from 0 to (configMAX_PRIORITIES-1). The number of low priorities represents low priority tasks. The priority of the idle task is 0 (tskIDLE_PRIORITY), so it is the lowest priority task.

The FreeRTOS scheduler ensures that high-priority tasks in the ready state (Ready) or running state (Running) take priority over low-priority tasks that are also in the ready state. In other words, a running task is always a high priority task.

The same priority tasks in the ready state use the time slice scheduling mechanism to share processor time.

10.configMINIMAL_STACK_SIZE

Defines the stack size used by idle tasks. In general, this value should not be less than the value defined in the corresponding processor demonstration routine file FreeRTOSConfig.h.

Just like the stack size parameter of the xTaskCreate () function, the stack size is not in bytes but in words. For example, in a 32-bit architecture, a stack size of 100 means that the stack memory takes up 400 bytes of space.

11.configTOTAL_HEAP_SIZE

The total valid RAM size available to the RTOS kernel. This value is only possible if you use the memory allocation strategy that comes with the official download package. Whenever a task, queue, mutex, software timer, or semaphore is created, the RTOS kernel allocates RAM to it, where the RAM belongs to the memory area specified by configTOTAL_HEAP_SIZE. The following memory configuration will talk about the official memory allocation strategy in detail.

12.configMAX_TASK_NAME_LEN

When calling the task function, you need to set a string that describes the task information, and this macro is used to define the maximum length of the string. The length defined here includes the string Terminator'\ 0'.

13.configUSE_TRACE_FACILITY

Setting to 1 initiates visual trace debugging, which activates some additional structure members and functions.

14.configUSE_STATS_FORMATTING_FUNCTIONS (added in V7.5.0)

Setting the macro configUSE _ TRACE_FACILITY and configUSE_STATS_FORMATTING_FUNCTIONS to 1 compiles the vTaskList () and vTaskGetRunTimeStats () functions. If either of these two macros is set to 0, the above two functions will not be compiled.

15.configUSE_16_BIT_TICKS

Defines the variable type of the system beat counter, that is, whether the portTickType represents a 16-bit variable or a 32-bit variable.

Defining configUSE_16_BIT_TICKS as 1 means that portTickType represents 16-bit unsigned shaping, and defining configUSE_16_BIT_TICKS as 0 means that portTickType represents 32-bit unsigned shaping.

The use of 16-bit types can greatly improve the performance of 8-bit and 16-bit architecture microprocessors, but it also limits the maximum clock count to 65535 'Tick'. Therefore, if the Tick frequency is 250HZ (4MS interrupts once), the 16-bit counter is 262s for the maximum task delay or blocking time, while the 32-bit counter is 17179869 seconds.

16.configIDLE_SHOULD_YIELD

This parameter controls the behavior of the task in the idle priority. It works only if the following conditions are met.

Using preemptive kernel scheduling

User tasks use idle priority.

Multiple tasks that share the same priority through time slices should get the same processor time if the shared priority is greater than the idle priority and assuming that there are no higher priority tasks.

However, if the idle priority is shared, the situation will be slightly different. When configIDLE_SHOULD_YIELD is 1, when other user tasks that share the idle priority are ready, the idle task immediately gives up the CPU, and the user task runs, which ensures the fastest response to the user task. Being in this mode can also have adverse effects (depending on your program needs), as described below:

The figure depicts four tasks with idle priorities, tasks A, B, and C are user tasks, and task I is idle tasks. Context switching occurs periodically at T0, T1. T6 moment. When the user task runs, the idle task immediately gives up the CPU, but the idle task has consumed a certain amount of time in the current time slice. The result is that idle task I and user task A share a time slice. User task B and user task C therefore get more processor time than user task A.

Can be avoided in the following ways:

If appropriate, put individual tasks in the idle priority into the idle hook function

The priority of the user task created is higher than the idle priority.

Set IDLE_SHOULD_YIELD to 0

Setting configIDLE_SHOULD_YIELD to 0 prevents idle tasks from giving up CPU for user tasks until the time slice of the idle task ends. This ensures that all tasks in the idle priority are allocated the same amount of processor time, but at the expense of a higher percentage of processor time allocated to idle tasks.

17.configUSE_TASK_NOTIFICATIONS (added to V8.2.0)

Setting the macro configUSE _ TASK_NOTIFICATIONS to 1 (or not defining the macro configUSE _ TASK_NOTIFICATIONS) will enable the task notification function, and the related API function will also be compiled. Set the macro configUSE _ TASK_NOTIFICATIONS to 0 to turn off the task notification function, and the related API function will not be compiled. This feature is turned on by default. When enabled, an additional 8 bytes of RAM is added to each task.

This is a very useful feature, a bright spot.

Each RTOS task has a 32-bit notification value, RTOS task notification is equivalent to sending an event directly to the task, and the task that receives the notification can unblock the task (entering the blocking state due to waiting for task notification). Using task notifications is obviously more flexible than when you had to create queues, binary semaphores, count semaphores, or event groups, respectively. Even better, using task notifications can be 45% faster than using semaphores to unblock tasks (using the GCC compiler,-O2 optimization level).

18.configUSE_MUTEXES

A setting of 1 means to use mutexes, and a setting of 0 means ignoring mutexes. Readers should understand the difference between mutexes and binary semaphores in FreeRTOS.

With regard to mutexes and binary semaphores, simply say:

Mutually exclusive semaphores must be the same task application, the same task release, other task release invalid.

Binary semaphore, after a task is successfully applied, can be released by another task.

Mutually exclusive semaphores are a subset of binary semaphores

19--2119.configUSE_RECURSIVE_MUTEXES

Setting to 1 means to use a recursive mutex, and setting to 0 means not to use it.

20.configUSE_COUNTING_SEMAPHORES

Setting to 1 means to use the count semaphore, and setting to 0 means not to use it.

21.configUSE_ALTERNATIVE_API

Setting to 1 means to use the "alternative" queue function ('alternative' queue functions), and set to 0 to not use it. The replacement API is described in detail in the queue.h header file.

Note: the "substitute" queue function has been deprecated, do not use it in the new design!

22.configCHECK_FOR_STACK_OVERFLOW

Each task maintains its own stack space, and the memory needed by the task is automatically allocated when the task is created, and the amount of memory allocated is specified by a parameter of the task creation function (xTaskCreate ()). Stack overflow is the most common cause of unstable operation of devices, so FreeeRTOS provides two optional mechanisms to assist in detecting and correcting stack overflow. Configure the macro configCheck _ FOR_STACK_OVERFLOW to be different constants to use different stack overflow detection mechanisms.

Note that this option applies only to memory-mapped unsegmented microprocessor architectures. Also, before RTOS detects a stack overflow, some processors may generate fault or exception to reflect the deterioration of stack usage. If the macro configCheck _ FOR_STACK_OVERFLOW is not set to 0, the user must provide a stack overflow hook function whose function name and parameters must be as follows:

Void vApplicationStackOverflowHook (TaskHandle_t xTask, signed char * pcTaskName)

The parameters xTask and pcTaskName are the handle and name of the stack overflow task. Please note that if the overflow is very serious, these two parameter information may also be wrong! In this case, you can check the pxCurrentTCb variable directly.

It is recommended that you use stack overflow checking only during the development or test phase, because stack overflow detection increases context switching overhead.

After the task is switched out, the context of the task is saved to its own stack space, which is likely to reach the maximum (deepest) stack usage. At this point, the RTOS kernel detects whether the stack pointer still points to a valid stack space. If the stack pointer points outside the valid stack space, the stack overflow hook function is called.

This method is fast, but cannot detect all stack overflows (for example, stack overflows do not occur during context switching). Setting configCHECK_FOR_STACK_OVERFLOW to 1 uses this method.

When the stack is first created, populate its stack area with some known values (tags). When the task is switched, the RTOS kernel detects the last 16 bytes of the stack to ensure that the tag data is not overwritten. If any of the 16 bytes is changed, the stack overflow hook function is called.

This method is slower than the first method, but it is also quite fast. It can effectively catch stack overflow events (even if stack overflow does not occur during context switching), but in theory it cannot catch all stack overflows (for example, stack overflow values are the same as tag values, of course, the probability of this happening is minimal).

To use this method, you need to set configCHECK_FOR_STACK_OVERFLOW to 2. 0.

23.configQUEUE_REGISTRY_SIZE

Queue recording serves two purposes, both of which involve debugging the RTOS kernel:

It allows you to simply identify the queue using the text name of a queue in the debug GUI; it contains every record queue and semaphore location information needed by the debugger

Queue recording serves no purpose other than kernel debugging.

ConfigQUEUE_REGISTRY_SIZE defines the maximum number of queues and semaphores that can be recorded. If you want to use the RTOS kernel debugger to view queue and semaphore information, you must first register these queues and semaphores, and only registered queues and semaphores can be viewed using the RTOS kernel debugger. Check out the vQueueAddToRegistry () and vQueueUnregisterQueue () functions in the API reference manual for more information.

24--3624configUSE_QUEUE_SETS

Set to 1 to enable queue set function (can block and suspend to multiple queues and semaphores), and set to 0 to cancel queue set function.

25.configUSE_TIME_SLICING (added in V7.5.0)

By default (macro configUSE _ TIME_SLICING is not defined or macro configUSE _ TIME_SLICING is set to 1), FreeRTOS uses a time-slice-based priority preemptive scheduler. This means that the RTOS scheduler always runs the highest priority ready tasks, switching between multiple tasks of the same priority when each RTOS system beat is interrupted. If the macro configUSE _ TIME_SLICING is set to zero, the RTOS scheduler still runs the ready tasks with the highest priority, but when the RTOS system beat interruption occurs, there is no task switching between multiple tasks of the same priority.

26.configUSE_NEWLIB_REENTRANT (added in V7.5.0)

If the macro configUSE _ NEWLIB_REENTRANT is set to 1, each created task is assigned a newlib (an embedded C library) reent structure.

27.configENABLE_BACKWARD_COMPATIBILITY

The header file FreeRTOS.h contains a series of # define macro definitions that map the data type names of versions V8.0.0 and prior to V8.0.0. These macros ensure that the previous application code does not need to be modified when the RTOS kernel is upgraded to V8.0.0 or later. Setting the macro config enable _ BACKWARD_COMPATIBILITY to 0 in the FreeRTOSConfig.h file removes these macro definitions and requires the user to confirm that these names were not used by the application before the upgrade.

28.configNUM_THREAD_LOCAL_STORAGE_POINTERS

Sets the thread-local storage pointer array size for each task.

Thread-local storage allows applications to store some values in the control block of tasks, each task has its own independent storage space, and the macro configNUM _ THREAD_LOCAL_STORAGE_POINTERS specifies the size of the array of pointers stored locally by each task thread. The API function vTaskSetThreadLocalStoragePointer () is used to write values to the pointer array, and the API function pvTaskGetThreadLocalStoragePointer () is used to read values from the pointer array.

For example, many library functions contain a global variable called errno. Some library functions use errno to return library function error messages, and the application checks this global variable to determine which errors have occurred. In single-threaded programs, it is possible to define errno as a global variable, but in multithreaded applications, each thread (task) must have its own unique errno value, otherwise, one task may read the errno value of another task.

FreeRTOS provides a flexible mechanism that allows applications to use thread-local storage pointers to read and write thread-local storage. See the follow-up article "FreeRTOS Series 12-FreeRTOS Task Application function".

29.configGENERATE_RUN_TIME_STATS

Set the macro configGENERATE _ RUN_TIME_STATS to 1 to run the time statistics function. Once set to 1, the following two macros must be defined:

PortCONFIGURE_TIMER_FOR_RUN_TIME_STATS (): the user program needs to provide a benchmark clock function, which completes the initialization of the benchmark clock function, which is define to the macro configuration _ TIMER_FOR_RUN_TIME_STATS (). This is because run-time statistics require a benchmark timer with a higher resolution than the system beat interrupt frequency, otherwise, the statistics may not be accurate. The interrupt frequency of the reference timer is 10 times faster than that of the system beat. The faster the interrupt frequency of the benchmark timer, the more accurate the statistics, but the shorter the running time that can be counted (for example, the benchmark timer 10ms interrupts once, the 8-bit unsigned shaping variable can count to 2.55 seconds, but if it is interrupted once per second, the 8-bit unsigned shaping variable can count to 255 seconds).

PortGET_RUN_TIME_COUNTER_VALUE (): the user program needs to provide a function that returns the current "time" of the benchmark clock, which is define to the macro portGet _ RUN_TIME_COUNTER_VALUE ().

For example, suppose we configure a timer that interrupts every 500us. Simply increment the long shaping variable ulHighFrequencyTimerTicks in the timer interrupt service routine. So the definitions of the two macros mentioned above are as follows (you can add them in FreeRTOSConfig.h):

Extern volatile unsigned longulHighFrequencyTimerTicks; # define portCONFIGURE_TIMER_FOR_RUN_TIME_STATS () (ulHighFrequencyTimerTicks = 0UL) # define portGET_RUN_TIME_COUNTER_VALUE () ulHighFrequencyTimerTicks30.configUSE_CO_ROUTINES

Setting to 1 means to use a co-program, and 0 means that a co-program is not used. If you use a collaborator, you must include the croutine.c file in the project.

Note: Co-routines is mainly used in embedded systems with very limited resources (very few RAM) and is not usually used for 32-bit microprocessors.

In the current embedded hardware environment, the use of collaborative programs is not recommended. FreeRTOS developers have already stopped developing collaborative programs.

31.configMAX_CO_ROUTINE_PRIORITIES

The number of valid priorities for application collaborators (Co-routines), and any number of collaborators can share a priority. Using collaborators, you can assign task priorities separately. See configMAX_PRIORITIES.

32.configUSE_TIMERS

Set to 1 to use software timer, for 0 do not use software timer function. For a detailed description, see FreeRTOS software timers.

33.configTIMER_TASK_PRIORITY

Set the priority of the software timer service / daemon. For a detailed description, see FreeRTOS software timers.

34.configTIMER_QUEUE_LENGTH

Sets the length of the software timer command queue. For a detailed description, see FreeRTOS software timers.

35.configTIMER_TASK_STACK_DEPTH

Set the stack depth of the software timer service / daemon task, as described in FreeRTOS software timers.

36.configKERNEL_INTERRUPT_PRIORITY

ConfigMAX_SYSCALL_INTERRUPT_PRIORITY and configMAX_API_CALL_INTERRUPT_PRIORITY

This is where there are the most mistakes in transplanting and applying FreeRTOS, so you need to read it carefully.

Cortex-M3, PIC24, dsPIC, PIC32, SuperH and RX600 hardware devices need to set macro configKernel _ INTERRUPT_PRIORITY;PIC32, RX600 and Cortex-M hardware devices need to set macro configMax _ SYSCALL_INTERRUPT_PRIORITY.

ConfigMAX_SYSCALL_INTERRUPT_PRIORITY and configMAX_API_CALL_INTERRUPT_PRIORITY, these two macros are equivalent, the latter is the new name of the former, used to update the migration layer code.

Note that in the following description, only API functions ending in "FromISR" can be called in the interrupt service routine.

Only the hardware device of configKERNEL_INTERRUPT_PRIORITY needs to be set (that is, the macro configMax _ SYSCALL_INTERRUPT_PRIORITY will not be used): configKERNEL_INTERRUPT_PRIORITY is used to set the interrupt priority of the RTOS kernel itself. Interrupts that call the API function must run at this priority; interrupts that do not call the API function can run at a higher priority, so these interrupts are not delayed by RTOS kernel activity.

Both configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY need to set up hardware devices: configKERNEL_INTERRUPT_PRIORITY is used to set the interrupt priority of the RTOS kernel itself. Because RTOS kernel interrupts are not allowed to preempt interrupts used by users, this macro is generally defined as the lowest hardware priority. ConfigMAX_SYSCALL_INTERRUPT_PRIORITY is used to set the highest interrupt priority at which the FreeRTOS API function can be safely called in the interrupt service program. When the priority is less than or equal to the priority represented by this macro, the program can safely call the FreeRTOS API function in the interrupt service program; if the priority is greater than the priority represented by this macro, it means that FreeRTOS cannot prohibit the interrupt, and no API function can be called in this interrupt service program.

Complete interrupt nesting mode can be achieved by setting the priority level of configMAX_SYSCALL_INTERRUPT_PRIORITY over configKERNEL_INTERRUPT_PRIORITY. This means that the FreeRTOS kernel cannot completely disable interrupts, even in critical areas. In addition, it is beneficial to microprocessors with segmented kernel architecture. Note that when a new interrupt occurs, some microprocessor architectures disable interrupts (on hardware), which means that interrupts are inevitably prohibited for a short period of time from hardware response interrupts to FreeRTOS re-enabling interrupts.

Interrupts that do not call API can run at a higher priority than configMAX_SYSCALL_INTERRUPT_PRIORITY, and these levels of interrupts are not disabled by FreeRTOS, so they are not delayed by executing the RTOS kernel.

For example, suppose a microcontroller has eight interrupt priorities: 0 for the lowest priority and 7 for the highest priority (as opposed to the number and priority of Cortex-M3 and Cortex-M4 kernels, which will be covered in a later article). When the two configuration options are 4 and 0, the following figure describes the events that each priority can and cannot do:

ConfigMAX_SYSCALL_INTERRUPT_PRIORITY=4

ConfigKERNEL_INTERRUPT_PRIORITY=0

These configuration parameters allow very flexible interrupt handling:

Interrupt handling tasks can be assigned priority like other tasks in the system. These tasks are awakened by a corresponding interrupt. Interrupt service routines (ISR) should be as concise as possible-only for updating data and waking up high-priority tasks. After ISR exits, the awakened task runs directly, so interrupt processing (corresponding processing based on the data obtained by the interrupt) is continuous in time, just as ISR is doing the work. The advantage of this is that when the interrupt processing task is executed, all interrupts can be in the enabled state.

Interrupts, interrupt service routines (ISR) and interrupt handling tasks are three different things: when the interrupt comes, the interrupt service routine enters the interrupt service routine, the interrupt service routine does the necessary data collection (update), and then wakes up the high priority task. This high priority task is executed immediately after the end of the interrupt service routine. it may be another task or an interrupt processing task. if it is an interrupt processing task, it can be processed according to the data collected in the interrupt service routine.

The configMAX_SYSCALL_INTERRUPT_PRIORITY interface has a deeper meaning: interrupts with a priority between RTOS kernel interrupt priority (equal to configKERNEL_INTERRUPT_PRIORITY) and configMAX_SYSCALL_INTERRUPT_PRIORITY allow fully nested interrupt modes and allow API functions to be called. Interrupt priorities greater than configMAX_SYSCALL_INTERRUPT_PRIORITY will never be delayed by the execution of the RTOS kernel.

Priority interrupts that run larger than configMAX_SYSCALL_INTERRUPT_PRIORITY are not shielded by the RTOS kernel and are therefore not affected by RTOS kernel functions. This is mainly used in very high real-time requirements. Such as performing motor steering. However, the API function of FreeRTOS must not be called in the interrupt service routine of this type of interrupt.

In order to use this scheme, the application must comply with the following rule: any interrupt calling the FreeRTOS API function must be at the same priority as the RTOS kernel (set by the macro configKernel _ INTERRUPT_PRIORITY), or less than or equal to the priority defined by the macro configMax _ SYSCALL_INTERRUPT_PRIORITY.

37.configASSERT

Asserts that you can check whether the passed parameters are legal while debugging. The configASSERT (x) function is called at key points in the FreeRTOS kernel code, and an error is thrown if the parameter x is 0. This error is most likely caused by invalid arguments passed to the FreeRTOS API function. Defining configASSERT () can help you find errors when debugging, but defining configASSERT () can also increase the amount of application code and run time. It is recommended to use this assertion macro during the development phase.

For example, if we want to print out the file name and the number of lines of code where the illegal parameters are located, we can first define a function vAssertCalled, which has two parameters, receives the file name and the line where the macro is triggered, and then outputs it through the display screen or serial port. The code is as follows:

# define configASSERT ((x)) if ((x) = = 0) vAssertCalled (_ _ FILE__, _ _ LINE__)

Here _ _ FILE__ and _ _ LINE__ are predefined macros by most compilers, representing the file name (string format) and the number of lines (shaping) where the code is located, respectively.

Although this example looks simple, it is not satisfactory in terms of efficiency and implementation because of converting the integer _ _ LINE__ to a string and then displaying it. We can use the implementation of the C standard library assert, so that the function vAssertCalled only needs to receive a parameter in the form of a string (it is recommended to read the following code carefully and understand the techniques):

# define STR (x) VAL (x) # defineVAL (x) # x # define configASSERT (x) ((x)? (void) 0: xAssertCalld (_ _ FILE__ ":" STR (_ _ LINE__) "" # x "\ n"))

To explain a little bit, because the built-in macro _ _ LINE__ is integer rather than string, converting it to a string requires an extra processing layer. Macro STR and macro VAL are used to assist with this conversion. The macro STR is used to replace the shaping line number with the _ _ LINE__, macro VAL to serialize the shaping line number. Ignoring any of the macros STR and VAL, we only get the string "_ _ LINE__", which is not what we want.

Here, the ternary operator'?:'is used instead of the parameter judgment if statement, so that you can accept any parameter or expression, the code is more compact, and more importantly, the code is more optimized, because if the parameter is always true, unnecessary output statements can be removed during the compilation phase.

38.INCLUDE Parameters

Macros that start with "INCLUDE" allow users not to compile real-time kernel components (functions) that are not needed by applications, which ensures that RTOS takes up the least ROM and RAM in your embedded system.

Each macro appears in the following form:

INCLUDE_FunctionName

Here FunctionName represents an API function that you can control whether or not to compile. If you want to use this function, set the macro to 1, and if you don't want to use it, set the macro to 0. For example, for the API function vTaskDelete ():

# define INCLUDE_vTaskDelete 1

Indicates that you want to use vTaskDelete () to allow the compiler to compile the function

# define INCLUDE_vTaskDelete 0

Indicates that the compiler is prohibited from compiling the function.

These are all the contents of the article "how to configure the kernel of the FreeRTOS real-time operating system". Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.