http://www.freertos.org/a00110.html
边看边试着翻译了下，发现看懂是一回事，写成文字表达出来又是另一个层次了，何况还有很多看不懂的。
以后有机会，一点一点的补上去吧 < -> _ -> >
FreeRTOS 的配置是通过修改FreeRTOSConfig.h配置文件实现的。在基于FreeRTOS的应用程序的预处理程序包含的路径中必定有一个FreeRTOSConfig.h头文件。FreeRTOSConfig.h 使得RTOS内核与要实现的应用程序相匹配。 因此，其针对某个应用程序来讲是特定的，而不是针对RTOS，故其应放在应用程序文件目录下，而不是内核代码目录。
包含在下载的RTOS源代码中的每个实例应用程序中都有自己的FreeRTOSConfig.h文件。它们中有些相当久远而没有包含所有的可配置选项。在RTOS源程序文件中，那些去除的配置选项被设置为默认值。（Configuration options that are omitted are set to a default value within an RTOS source file.）
下面是一份FreeRTOSConfig.h文件的经典配置，每个选项下面都有注解。
#ifndef FREERTOS_CONFIG_H
#define FREERTOS_CONFIG_H
/* 如果你需要放置一些交叉应用的头文件在你的应用程序中，放在这里是个不错的地方
Here is a good place to include header files that are required across
your application. */
#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.
FreeRTOS 的MPU具体指定 */
#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 0
/* A header file that defines trace macro can be included here.
定义跟踪用的宏定义的头文件可以包含在这里（不明白什么意思） */
#endif /* FREERTOS_CONFIG_H */configUSE_PREEMPTION
1：RTOS为抢占式调度；（ preemptive RTOS scheduler）
0：RTOS为协作式调度。（ cooperative RTOS scheduler）
configUSE_PORT_OPTIMISED_TASK_SELECTION
一些FreeRTOS的移植会有两种可选择的方法去实现下一个任务的执行——一种为通用型的方式，另一种则是针对某个移植特定的方法。（Some FreeRTOS ports have two methods of selecting the next task to execute - a generic method, and a method that is specific to that port.）
通用的方式 ：
某种移植特定的方式：
configUSE_TICKLESS_IDLE
1: 使用低功耗无响应模式（ low power tickless mode）
0: 保持节拍中断始终有效
configUSE_IDLE_HOOK
1：使用空闲钩子
0：去除空闲钩子
configUSE_MALLOC_FAILED_HOOK
每次创建任务，队列或者信号量时，内核调用pvPortMalloc() 函数从堆（heap）中分配内存。在官方下载的FreeRTOS包中含有用于此目的关于内存分配方案（four sample memory allocation schemes ）的四个例子。这几个方案分别在heap_1.c, heap_2.c, heap_3.c, heap_4.c 和 heap_5.c 源文件里实现。configUSE_MALLOC_FAILED_HOOK仅当这三个例子方案中的一个被使用时，才有相关性。（好别扭，一会四一会三的，是不是官网有错误； configUSE_MALLOC_FAILED_HOOK is only relevant when one of these three sample schemes is being used.）。如果定义且对malloc（）失败后的钩子函数进行了配置，当pvPortMalloc()返回NULL时，将会调用malloc（）失败后的钩子函数。（The malloc() failed hook function is a hook (or callback) function that, if defined and configured, will be called if pvPortMalloc() ever returns NULL. （看不懂））。当FreeRTOS的堆内存不足以致不能成功分配出需要的内存时，返回NULL。
如果onfigUSE_MALLOC_FAILED_HOOK 被置为1，应用程序必须定义一个malloc()失败后的钩子函数（must define a malloc() failed hook function. ）。如果为0，malloc()失败后的钩子函数将不会被调用，即使已经有了定义。Malloc()失败钩子函数（Malloc() failed hook functions）必须有如下所示的名字跟声明：
void vApplicationMallocFailedHook( void );
configUSE_TICK_HOOK
1: 使能tick 钩子（tick hook）; 0: 禁用tick钩子
configCPU_CLOCK_HZ
驱动外围设备的内部时钟频率，单位为Hz，用来产生将会被执行的tick interrrupt，一般跟驱动内部CPU时钟的是同一个。为了正确地配置定时器外围设备，这个值是必需。（Enter the frequency in Hz at which the internal clock that driver the peripheral used to generate the tick interrupt will be executing - this is normally the same clock that drives the internal CPU clock. This value is required in order to correctly configure timer peripherals. ）
configTICK_RATE_HZ
RTOS tick（时间片）中断的频率。
RTOS tick interrupt 用于计算时间，因此越高的时间片（tick frequency）频率意味着可以计算的时间分辨率（resolution）越高。然而，tick frequency很高也同时意味着RTOS内核将占有更多的cpu时间，使得效率降低。所有的RTOS demo的tick频率值为1000Hz。这是为了测试RTOS的内核故其值设置的比一般实际要用到的大。
多个任务可以用同一个优先级。RTOS调度器通过在每个RTOS tick之间切换这些优先级相同的任务实现这些任务共享处理器时间。因此tick rate 频率越高，分给每个任务运行的时间片（time slice）越短。
configMAX_PRIORITIES
应用任务可用的优先级数。任何一个任务都可以处于同一个优先级。Co-routines（协同程序）的优先级是单独的，与任务优先级不同，（are prioritised separately ）- 参见（see） configMAX_CO_ROUTINE_PRIORITIES.
每个可用的等级都会占用RTOS内核的RAM，因此最好不要设定的大于在应用程序中要用到等级。
http://blog.csdn.net/liyuanbhu/article/details/7912170/
FreeRTOS 会为每个优先级建立一个链表，因此没多一个优先级都会增加些RAM
的开销。所以，要根据程序中需要多少种不同的优先级来设置这个参数。
configMINIMAL_STACK_SIZE
空闲任务使用的堆栈大小。
Generally this should not be reduced from the value set in the FreeRTOSConfig.h file provided with the demo application for the port you are using.
Like the stack size parameter to the xTaskCreate() function, the stack size is specified in words, not bytes. If each item placed on the stack is 32-bits, then a stack size of 100 means 400 bytes (each 32-bit stack item consuming 4 bytes).
configTOTAL_HEAP_SIZE
The total amount of RAM available to the RTOS kernel.
This value will only be used if your application makes use of one of the sample memory allocation schemes provided in the FreeRTOS source code download. See the memory configuration section for further details.
configMAX_TASK_NAME_LEN
The maximum permissible length of the descriptive name given to a task when the task is created. The length is specified in the number of characters including the NULL termination byte.
configUSE_TRACE_FACILITY
Set to 1 if you wish to include additional structure members and functions to assist with execution visualisation and tracing.
configUSE_STATS_FORMATTING_FUNCTIONS
Set configUSE_TRACE_FACILITY and configUSE_STATS_FORMATTING_FUNCTIONS to 1 to include the vTaskList() and vTaskGetRunTimeStats() functions in the build. Setting either to 0 will omit vTaskList() and vTaskGetRunTimeStates() from the build.
configUSE_16_BIT_TICKS
Time is measured in ‘ticks’ - which is the number of times the tick interrupt has executed since the RTOS kernel was started. The tick count is held in a variable of type TickType_t.
Defining configUSE_16_BIT_TICKS as 1 causes TickType_t to be defined (typedef’ed) as an unsigned 16bit type. Defining configUSE_16_BIT_TICKS as 0 causes TickType_t to be defined (typedef’ed) as an unsigned 32bit type.
Using a 16 bit type will greatly improve performance on 8 and 16 bit architectures, but limits the maximum specifiable time period to 65535 ‘ticks’. Therefore, assuming a tick frequency of 250Hz, the maximum time a task can delay or block when a 16bit counter is used is 262 seconds, compared to 17179869 seconds when using a 32bit counter.
configIDLE_SHOULD_YIELD
This parameter controls the behaviour of tasks at the idle priority. It only has an effect if:
The preemptive scheduler is being used.
The users application creates tasks that run at the idle priority.
Tasks that share the same priority will time slice. Assuming none of the tasks get preempted, it might be assumed that each task of at a given priority will be allocated an equal amount of processing time - and if the shared priority is above the idle priority then this is indeed the case.
When tasks share the idle priority the behaviour can be slightly different. When configIDLE_SHOULD_YIELD is set to 1 the idle task will yield immediately should any other task at the idle priority be ready to run. This ensures the minimum amount of time is spent in the idle task when application tasks are available for scheduling. This behaviour can however have undesirable effects (depending on the needs of your application) as depicted below:
This diagram shows the execution pattern of four tasks at the idle priority. Tasks A, B and C are application tasks. Task I is the idle task. A context switch occurs with regular period at times T0, T1, …, T6. When the idle task yields task A starts to execute - but the idle task has already taken up some of the current time slice. This results in task I and task A effectively sharing a time slice. The application tasks B and C therefore get more processing time than the application task A.
This situation can be avoided by:
Setting configIDLE_SHOULD_YIELD prevents the idle task from yielding processing time until the end of its time slice. This ensure all tasks at the idle priority are allocated an equal amount of processing time - but at the cost of a greater proportion of the total processing time being allocated to the idle task.
configUSE_TASK_NOTIFICATIONS
Setting configUSE_TASK_NOTIFICATIONS to 1 (or leaving configUSE_TASK_NOTIFICATIONS undefined) will include direct to task notification functionality and its associated API in the build.
Setting configUSE_TASK_NOTIFICATIONS to 0 will exclude direct to task notification functionality and its associated API from the build.
Each task consumes 8 additional bytes of RAM when direct to task notifications are included in the build.
configUSE_MUTEXES
Set to 1 to include mutex functionality in the build, or 0 to omit mutex functionality from the build. Readers should familiarise themselves with the differences between mutexes and binary semaphores in relation to the FreeRTOS functionality.
configUSE_RECURSIVE_MUTEXES
Set to 1 to include recursive mutex functionality in the build, or 0 to omit recursive mutex functionality from the build.
configUSE_COUNTING_SEMAPHORES
Set to 1 to include counting semaphore functionality in the build, or 0 to omit counting semaphore functionality from the build.
configUSE_ALTERNATIVE_API
Set to 1 to include the ‘alternative’ queue functions in the build, or 0 to omit the ‘alternative’ queue functions from the build. The alternative API is described within the queue.h header file. The alternative API is deprecated and should not be used in new designs.
configCHECK_FOR_STACK_OVERFLOW
The stack overflow detection page describes the use of this parameter.
configQUEUE_REGISTRY_SIZE
The queue registry has two purposes, both of which are associated with RTOS kernel aware debugging:
It allows a textual name to be associated with a queue for easy queue identification within a debugging GUI.
It contains the information required by a debugger to locate each registered queue and semaphore.
The queue registry has no purpose unless you are using a RTOS kernel aware debugger.
configQUEUE_REGISTRY_SIZE defines the maximum number of queues and semaphores that can be registered. Only those queues and semaphores that you want to view using a RTOS kernel aware debugger need be registered. See the API reference documentation for vQueueAddToRegistry() and vQueueUnregisterQueue() for more information.
configUSE_QUEUE_SETS
Set to 1 to include queue set functionality (the ability to block, or pend, on multiple queues and semaphores), or 0 to omit queue set functionality.
configUSE_TIME_SLICING
By default (if configUSE_TIME_SLICING is not defined, or if configUSE_TIME_SLICING is defined as 1) FreeRTOS uses prioritised preemptive scheduling with time slicing. That means the RTOS scheduler will always run the highest priority task that is in the Ready state, and will switch between tasks of equal priority on every RTOS tick interrupt. If configUSE_TIME_SLICING is set to 0 then the RTOS scheduler will still run the highest priority task that is in the Ready state, but will not switch between tasks of equal priority just because a tick interrupt has occurred.
configUSE_NEWLIB_REENTRANT
If configUSE_NEWLIB_REENTRANT is set to 1 then a newlib reent structure will be allocated for each created task.
Note Newlib support has been included by popular demand, but is not used by the FreeRTOS maintainers themselves. FreeRTOS is not responsible for resulting newlib operation. User must be familiar with newlib and must provide system-wide implementations of the necessary stubs. Be warned that (at the time of writing) the current newlib design implements a system-wide malloc() that must be provided with locks.
configENABLE_BACKWARD_COMPATIBILITY
The FreeRTOS.h header file includes a set of #define macros that map the names of data types used in versions of FreeRTOS prior to version 8.0.0 to the names used in FreeRTOS version 8.0.0. The macros allow application code to update the version of FreeRTOS they are built against from a pre 8.0.0 version to a post 8.0.0 version without modification. Setting configENABLE_BACKWARD_COMPATIBILITY to 0 in FreeRTOSConfig.h excludes the macors from the build, and in so doing allowing validation that no pre version 8.0.0 names are being used.
configNUM_THREAD_LOCAL_STORAGE_POINTERS
Sets the number of indexes in each task’s thread local storage array.
configGENERATE_RUN_TIME_STATS
The Run Time Stats page describes the use of this parameter.
configUSE_CO_ROUTINES
Set to 1 to include co-routine functionality in the build, or 0 to omit co-routine functionality from the build. To include co-routines croutine.c must be included in the project.
configMAX_CO_ROUTINE_PRIORITIES
The number of priorities available to the application co-routines. Any number of co-routines can share the same priority. Tasks are prioritised separately - see configMAX_PRIORITIES.
configUSE_TIMERS
Set to 1 to include software timer functionality, or 0 to omit software timer functionality. See the FreeRTOS software timers page for a full description.
configTIMER_TASK_PRIORITY
Sets the priority of the software timer service/daemon task. See the FreeRTOS software timers page for a full description.
configTIMER_QUEUE_LENGTH
Sets the length of the software timer command queue. See the FreeRTOS software timers page for a full description.
configTIMER_TASK_STACK_DEPTH
Sets the stack depth allocated to the software timer service/daemon task. See the FreeRTOS software timers page for a full description.
configKERNEL_INTERRUPT_PRIORITY
configMAX_SYSCALL_INTERRUPT_PRIORITY andconfigMAX_API_CALL_INTERRUPT_PRIORITY
Ports that contain a configKERNEL_INTERRUPT_PRIORITY setting include ARM Cortex-M3, PIC24, dsPIC, PIC32, SuperH and RX600. Ports that contain a configMAX_SYSCALL_INTERRUPT_PRIORITY setting include PIC32, RX600, ARM Cortex-A and ARM Cortex-M ports.
ARM Cortex-M3 and ARM Cortex-M4 users please take heed of the special note at the end of this section!
configMAX_API_CALL_INTERRUPT_PRIORITY is a new name for configMAX_SYSCALL_INTERRUPT_PRIORITY that is used by newer ports only. The two are equivalent.
configKERNEL_INTERRUPT_PRIORITY should be set to the lowest priority.
Note in the following discussion that only API functions that end in “FromISR” can be called from within an interrupt service routine.
For ports that only implement configKERNEL_INTERRUPT_PRIORITY
configKERNEL_INTERRUPT_PRIORITY sets the interrupt priority used by the RTOS kernel itself. Interrupts that call API functions must also execute at this priority. Interrupts that do not call API functions can execute at higher priorities and therefore never have their execution delayed by the RTOS kernel activity (within the limits of the hardware itself).
For ports that implement both configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY:
configKERNEL_INTERRUPT_PRIORITY sets the interrupt priority used by the RTOS kernel itself. configMAX_SYSCALL_INTERRUPT_PRIORITY sets the highest interrupt priority from which interrupt safe FreeRTOS API functions can be called.
A full interrupt nesting model is achieved by setting configMAX_SYSCALL_INTERRUPT_PRIORITY above (that is, at a higher priority level) than configKERNEL_INTERRUPT_PRIORITY. This means the FreeRTOS kernel does not completely disable interrupts, even inside critical sections. Further, this is achieved without the disadvantages of a segmented kernel architecture. Note however, certain microcontroller architectures will (in hardware) disable interrupts when a new interrupt is accepted - meaning interrupts are unavoidably disabled for the short period between the hardware accepting the interrupt, and the FreeRTOS code re-enabling interrupts.
Interrupts that do not call API functions can execute at priorities above configMAX_SYSCALL_INTERRUPT_PRIORITY and therefore never be delayed by the RTOS kernel execution.
For example, imagine a hypothetical microcontroller that has 8 interrupt priority levels - 0 being the lowest and 7 being the highest (see the special note for ARM Cortex-M3 users at the end of this section). The picture below describes what can and cannot be done at each priority level should the two configuration constants be set to 4 and 0 as shown:
Example interrupt priority configuration
These configuration parameters allow very flexible interrupt handling:
To utilize this scheme your application design must adhere to the following rule: Any interrupt that uses the FreeRTOS API must be set to the same priority as the RTOS kernel (as configured by the configKERNEL_INTERRUPT_PRIORITY macro), or at or below configMAX_SYSCALL_INTERRUPT_PRIORITY for ports that include this functionality.
A special note for ARM Cortex-M3 and ARM Cortex-M4 users: Please read the page dedicated to interrupt priority settings on ARM Cortex-M devices. As a minimum, remember that ARM Cortex-M3 cores use numerically low priority numbers to represent HIGH priority interrupts, which can seem counter-intuitive and is easy to forget! If you wish to assign an interrupt a low priority do NOT assign it a priority of 0 (or other low numeric value) as this can result in the interrupt actually having the highest priority in the system - and therefore potentially make your system crash if this priority is above configMAX_SYSCALL_INTERRUPT_PRIORITY.
The lowest priority on a ARM Cortex-M3 core is in fact 255 - however different ARM Cortex-M3 vendors implement a different number of priority bits and supply library functions that expect priorities to be specified in different ways. For example, on the STM32 the lowest priority you can specify in an ST driver library call is in fact 15 - and the highest priority you can specify is 0.
configASSERT
The semantics of the configASSERT() macro are the same as the standard C assert() macro. An assertion is triggered if the parameter passed into configASSERT() is zero.
configASSERT() is called throughout the FreeRTOS source files to check how the application is using FreeRTOS. It is highly recommended to develop FreeRTOS applications with configASSERT() defined.
The example definition (shown at the top of the file and replicated below) calls vAssertCalled(), passing in the file name and line number of the triggering configASSERT() call (FILE and LINE are standard macros provided by most compilers). This is just for demonstration as vAssertCalled() is not a FreeRTOS function, configASSERT() can be defined to take whatever action the application writer deems appropriate.
It is normal to define configASSERT() in such a way that it will prevent the application from executing any further. This if for two reasons; stopping the application at the point of the assertion allows the cause of the assertion to be debugged, and executing past a triggered assertion will probably result in a crash anyway.
Note defining configASSERT() will increase both the application code size and execution time. When the application is stable the additional overhead can be removed by simply commenting out the configASSERT() definition in FreeRTOSConfig
/* Define configASSERT() to call vAssertCalled() if the assertion fails. The assertion
has failed if the value of the parameter passed into configASSERT() equals zero. */
#define configASSERT( ( x ) ) if( ( x ) == 0 ) vAssertCalled( ___FILE__ , _LINE__ )running FreeRTOS under the control of a debugger, then configASSERT() can be defined to just disable interrupts and sit in a loop, as demonstrated below. That will have the effect of stopping the code on the line that failed the assert test - pausing the debugger will then immediately take you to the offending line so you can see why it failed.
/* Define configASSERT() to disable interrupts and sit in a loop. */
#define configASSERT( ( x ) ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }configINCLUDE_APPLICATION_DEFINED_PRIVILEGED_FUNCTIONS
configINCLUDE_APPLICATION_DEFINED_PRIVILEGED_FUNCTIONS is only used by FreeRTOS MPU.
If configINCLUDE_APPLICATION_DEFINED_PRIVILEGED_FUNCTIONS is set to 1 then the application writer must provide a header file called “application_defined_privileged_functions.h”, in which functions the application writer needs to execute in privileged mode can be implemented. Note that, despite having a .h extension, the header file should contain the implementation of the C functions, not just the functions’ prototypes.
Functions implemented in “application_defined_privileged_functions.h” must save and restore the processor’s privilege state using the prvRaisePrivilege() function and portRESET_PRIVILEGE() macro respectively. For example, if a library provided print function accesses RAM that is outside of the control of the application writer, and therefore cannot be allocated to a memory protected user mode task, then the print function can be encapsulated in a privileged function using the following code:
void MPU_debug_printf( const char *pcMessage )
{
/* State the privilege level of the processor when the function was called. */
BaseType_t xRunningPrivileged = prvRaisePrivilege();
/* Call the library function, which now has access to all RAM. */
debug_printf( pcMessage );
/* Reset the processor privilege level to its original value. */
portRESET_PRIVILEGE( xRunningPrivileged );
}This technique should only be use during development, and not deployment, as it circumvents the memory protection.
The macros starting ‘INCLUDE’ allow those components of the real time kernel not utilized by your application to be excluded from your build. This ensures the RTOS does not use any more ROM or RAM than necessary for your particular embedded application.
Each macro takes the form …
INCLUDE_FunctionName… where FunctionName indicates the API function (or set of functions) that can optionally be excluded. To include the API function set the macro to 1, to exclude the function set the macro to 0. For example, to include the vTaskDelete() API function use:
#define INCLUDE_vTaskDelete 1To exclude vTaskDelete() from your build use:
#define INCLUDE_vTaskDelete 0