2.27 configUSE_QUEUE_SETS
设置成1使能队列集功能（可以阻塞、挂起到多个队列和信号量），设置成0取消队列集功能。
2.28 configUSE_TIME_SLICING
默认情况下（宏configUSE_TIME_SLICING未定义或者宏configUSE_TIME_SLICING设置为1），FreeRTOS使用基于时间片的优先级抢占式调度器。这意味着RTOS调度器总是运行处于最高优先级的就绪任务，在每个RTOS 系统节拍中断时在相同优先级的多个任务间进行任务切换。如果宏configUSE_TIME_SLICING设置为0，RTOS调度器仍然总是运行处于最高优先级的就绪任务，但是当RTOS 系统节拍中断发生时，相同优先级的多个任务之间不再进行任务切换。
2.29 configUSE_NEWLIB_REENTRANT
如果configUSE_NEWLIB_REENTRANT设置为1，那么将为每个创建的任务分配一个newlib结构。注意Newlib支持已经被广泛的需求所包含，但是FreeRTOS维护者自己并没有使用它。FreeRTOS不负责产生的newlib操作。用户必须熟悉newlib，并且必须提供必要存根的系统范围实现。请注意(在撰写本文时)当前的newlib设计实现了一个系统范围的malloc()，必须为其提供锁。
2.30 configENABLE_BACKWARD_COMPATIBILITY
头文件FreeRTOS.h包含一系列#define宏定义，用来映射版本V8.0.0和V8.0.0之前版本的数据类型名字。这些宏可以确保RTOS内核升级到V8.0.0或以上版本时，之前的应用代码不用做任何修改。在FreeRTOSConfig.h文件中设置宏configENABLE_BACKWARD_COMPATIBILITY为0会去掉这些宏定义，并且需要用户确认升级之前的应用没有用到这些名字。
2.31 configNUM_THREAD_LOCAL_STORAGE_POINTERS
设置每个任务的线程本地存储指针数组大小。
后面会介绍。
2.32 configUSE_MINI_LIST_ITEM
MiniListItem_t用于FreeRTOS列表中的开始和结束标记节点，ListItem_t用于FreeRTOS列表中的所有其他节点。当configUSE_MINI_LIST_ITEM设置为0时，minilisttem_t和ListItem_t都是相同的。当configUSE_MINI_LIST_ITEM设置为1时，minilisttem_t包含的字段比ListItem_t少3个，这节省了一些RAM，但代价是违反了一些编译器用于优化的严格别名规则。如果未定义，configUSE_MINI_LIST_ITEM默认为1，以便向后兼容。
2.33 configSTACK_DEPTH_TYPE
设置用于在调用xTaskCreate()时指定堆栈深度的类型，以及使用堆栈大小的各种其他位置(例如，当返回堆栈高水位标记时)。旧版本的FreeRTOS使用UBaseType_t类型的变量指定堆栈大小，但发现这在8位微控制器上限制太大。configSTACK_DEPTH_TYPE允许应用程序开发人员指定要使用的类型，从而消除了这种限制。
2.34 configMESSAGE_BUFFER_LENGTH_TYPE
FreeRTOS消息缓冲区使用configMESSAGE_BUFFER_LENGTH_TYPE类型的变量来存储每个消息的长度。如果configMESSAGE_BUFFER_LENGTH_TYPE没有定义，那么它将默认为size_t。如果存储在消息缓冲区中的消息永远不会超过255字节，那么定义configMESSAGE_BUFFER_LENGTH_TYPE为uint8_t将在32位微控制器上为每条消息节省3字节。同样，如果存储在消息缓冲区中的消息永远不会超过65535字节，那么定义configMESSAGE_BUFFER_LENGTH_TYPE为uint16_t将在32位微控制器上为每条消息节省2字节。
2.35 configSUPPORT_STATIC_ALLOCATION
如果configSUPPORT_STATIC_ALLOCATION设置为1，则可以使用应用程序编写人员提供的RAM创建RTOS对象。如果configSUPPORT_STATIC_ALLOCATION设置为0，那么RTOS对象只能使用从FreeRTOS堆分配的RAM创建。如果configSUPPORT_STATIC_ALLOCATION未定义，它将默认为0。如果configSUPPORT_STATIC_ALLOCATION设置为1，那么应用程序编写器还必须提供两个回调函数:vApplicationGetIdleTaskMemory()为RTOS空闲任务提供内存，以及(如果configUSE_TIMERS设置为1)vApplicationGetTimerTaskMemory()为RTOS守护进程/定时器服务任务提供内存。示例如下。
1/* configSUPPORT_STATIC_ALLOCATION is set to 1, so the application must provide an 2implementation of vApplicationGetIdleTaskMemory() to provide the memory that is 3used by the Idle task. */ 4void vApplicationGetIdleTaskMemory( StaticTask_t **ppxIdleTaskTCBBuffer, 5StackType_t **ppxIdleTaskStackBuffer, 6uint32_t *pulIdleTaskStackSize ) 7{ 8/* If the buffers to be provided to the Idle task are declared inside this 9function then they must be declared static - otherwise they will be allocated on 10the stack and so not exists after this function exits. */ 11static StaticTask_t xIdleTaskTCB; 12static StackType_t uxIdleTaskStack[ configMINIMAL_STACK_SIZE ]; 13 14/* Pass out a pointer to the StaticTask_t structure in which the Idle task's 15state will be stored. */ 16*ppxIdleTaskTCBBuffer = &xIdleTaskTCB; 17 18/* Pass out the array that will be used as the Idle task's stack. */ 19*ppxIdleTaskStackBuffer = uxIdleTaskStack; 20 21/* Pass out the size of the array pointed to by *ppxIdleTaskStackBuffer. 22Note that, as the array is necessarily of type StackType_t, 23configMINIMAL_STACK_SIZE is specified in words, not bytes. */ 24*pulIdleTaskStackSize = configMINIMAL_STACK_SIZE; 25} 26/*-----------------------------------------------------------*/ 27 28/* configSUPPORT_STATIC_ALLOCATION and configUSE_TIMERS are both set to 1, so the 29application must provide an implementation of vApplicationGetTimerTaskMemory() 30to provide the memory that is used by the Timer service task. */ 31void vApplicationGetTimerTaskMemory( StaticTask_t **ppxTimerTaskTCBBuffer, 32StackType_t **ppxTimerTaskStackBuffer, 33uint32_t *pulTimerTaskStackSize ) 34{ 35/* If the buffers to be provided to the Timer task are declared inside this 36function then they must be declared static - otherwise they will be allocated on 37the stack and so not exists after this function exits. */ 38static StaticTask_t xTimerTaskTCB; 39static StackType_t uxTimerTaskStack[ configTIMER_TASK_STACK_DEPTH ]; 40 41/* Pass out a pointer to the StaticTask_t structure in which the Timer 42task's state will be stored. */ 43*ppxTimerTaskTCBBuffer = &xTimerTaskTCB; 44 45/* Pass out the array that will be used as the Timer task's stack. */ 46*ppxTimerTaskStackBuffer = uxTimerTaskStack; 47 48/* Pass out the size of the array pointed to by *ppxTimerTaskStackBuffer. 49Note that, as the array is necessarily of type StackType_t, 50configTIMER_TASK_STACK_DEPTH is specified in words, not bytes. */ 51*pulTimerTaskStackSize = configTIMER_TASK_STACK_DEPTH; 52} 53 54Examples of the callback functions that must be provided by the application to 55 56supply the RAM used by the Idle and Timer Service tasks if configSUPPORT_STATIC_ALLOCATION 57 58is set to 1.
2.36 configSUPPORT_DYNAMIC_ALLOCATION
如果configSUPPORT_DYNAMIC_ALLOCATION设置为1，那么可以使用从FreeRTOS堆中自动分配的RAM创建RTOS对象。如果configSUPPORT_DYNAMIC_ALLOCATION设置为0，那么RTOS对象只能使用应用程序编写者提供的RAM创建。如果configSUPPORT_DYNAMIC_ALLOCATION未定义，它将默认为1。
2.37 configTOTAL_HEAP_SIZE
FreeRTOS堆中可用的RAM总量。当configSUPPORT_DYNAMIC_ALLOCATION被设置为1。会启用堆得设置，当然前提是必须使用FreeRTOS库中那5个内存分配之一中的一个。
2.38 configAPPLICATION_ALLOCATED_HEAP
默认情况下，FreeRTOS堆由FreeRTOS声明，并由链接器放置在内存中。将configAPPLICATION_ALLOCATED_HEAP设置为1允许由应用程序编写器声明堆，这允许应用程序编写器将堆放置在内存中的任何位置。如果heap_1.c, heap_2.c或heap_4.c被使用，并且configAPPLICATION_ALLOCATED_HEAP被设置为1，那么应用程序作者必须提供一个精确的uint8_t数组，其名称和尺寸如下所示。该数组将被用作FreeRTOS堆。
uint8_t ucHeap[ configTOTAL_HEAP_SIZE ];
2.39 configSTACK_ALLOCATION_FROM_SEPARATE_HEAP
如果configSTACK_ALLOCATION_FROM_SEPARATE_HEAP设置为1，则使用xTaskCreate或xTaskCreateRestricted API创建的任何任务的堆栈将使用pvPortMallocStack分配，并使用vPortFreeStack函数释放。用户需要提供pvPortMallocStack和vPortFreeStack函数的线程安全实现。这使得用户可以从一个单独的内存区域(可能是另一个不同于FreeRTOS堆的堆)为任务分配堆栈。如果configSTACK_ALLOCATION_FROM_SEPARATE_HEAP未定义，它将默认为0。pvPortMallocStack和vPortFreeStack函数的实现示例如下:
1void * pvPortMallocStack( size_t xWantedSize ) 2{ 3/* Allocate a memory block of size xWantedSize. The function used for 4* allocating memory must be thread safe. */ 5return MyThreadSafeMalloc( xWantedSize ); 6} 7 8void vPortFreeStack( void * pv ) 9{ 10/* Free the memory previously allocated using pvPortMallocStack. The 11* function used for freeing the memory must be thread safe. */ 12MyThreadSafeFree( pv ); 13}
2.40 configGENERATE_RUN_TIME_STATS
1- 设置宏configGENERATE_RUN_TIME_STATS为1使能运行时间统计功能。一旦设置为1，则下面两个宏必须被定义：
portCONFIGURE_TIMER_FOR_RUN_TIME_STATS()：用户程序需要提供一个基准时钟函数，函数完成初始化基准时钟功能，这个函数要被define到宏portCONFIGURE_TIMER_FOR_RUN_TIME_STATS()上。这是因为运行时间统计需要一个比系统节拍中断频率还要高分辨率的基准定时器，否则，统计可能不精确。基准定时器中断频率要比统节拍中断快10~100倍。基准定时器中断频率越快，统计越精准，但能统计的运行时间也越短（比如，基准定时器10ms中断一次，8位无符号整形变量可以计到2.55秒，但如果是1秒中断一次，8位无符号整形变量可以统计到255秒）。
2-portGET_RUN_TIME_COUNTER_VALUE()：用户程序需要提供一个返回基准时钟当前“时间”的函数，这个函数要被define到宏portGET_RUN_TIME_COUNTER_VALUE()上。
2.41 configUSE_CO_ROUTINES
设置成1表示使用协程，0表示不使用协程。如果使用协程，必须在工程中包含croutine.c文件。
注：协程（Co-routines）主要用于资源发非常受限的嵌入式系统（RAM非常少），通常不会用于32位微处理器。
在当前嵌入式硬件环境下，不建议使用协程，FreeRTOS的开发者早已经停止开发协程。
2.42 configMAX_CO_ROUTINE_PRIORITIES
应用程序协程（Co-routines）的有效优先级数目，任何数目的协程都可以共享一个优先级。使用协程可以单独的分配给任务优先级。见configMAX_PRIORITIES。
2.43 configUSE_TIMERS
设置成1使用软件定时器，为0不使用软件定时器功能。详细描述见FreeRTOS software timers 。
2.44 configTIMER_TASK_PRIORITY
设置软件定时器服务/守护进程的优先级。详细描述见FreeRTOS software timers 。
2.45 configTIMER_QUEUE_LENGTH
设置软件定时器命令队列的长度。详细描述见FreeRTOS software timers。
2.46 configTIMER_TASK_STACK_DEPTH
设置分配给软件定时器服务/守护进程任务的堆栈深度。
请参阅FreeRTOS软件定时器页面以获得完整的说明
2.47 configKERNEL_INTERRUPT_PRIORITY、configMAX_SYSCALL_INTERRUPT_PRIORITY 、configMAX_API_CALL_INTERRUPT_PRIORITY
Cortex-M3、PIC24、dsPIC、PIC32、SuperH和RX600硬件设备需要设置宏configKERNEL_INTERRUPT_PRIORITY；PIC32、RX600和Cortex-M硬件设备需要设置宏configMAX_SYSCALL_INTERRUPT_PRIORITY。
configMAX_SYSCALL_INTERRUPT_PRIORITY和configMAX_API_CALL_INTERRUPT_PRIORITY，这两个宏是等价的，后者是前者的新名字，用于更新的移植层代码。
注意下面的描述中，在中断服务例程中仅可以调用以“FromISR”结尾的API函数。
仅需要设置configKERNEL_INTERRUPT_PRIORITY的硬件设备（也就是宏configMAX_SYSCALL_INTERRUPT_PRIORITY不会用到）：configKERNEL_INTERRUPT_PRIORITY用来设置RTOS内核自己的中断优先级。调用API函数的中断必须运行在这个优先级；不调用API函数的中断，可以运行在更高的优先级，所以这些中断不会被因RTOS内核活动而延时。
configKERNEL_INTERRUPT_PRIORITY和configMAX_SYSCALL_INTERRUPT_PRIORITY都需要设置的硬件设备：configKERNEL_INTERRUPT_PRIORITY用来设置RTOS内核自己的中断优先级。因为RTOS内核中断不允许抢占用户使用的中断，因此这个宏一般定义为硬件最低优先级。configMAX_SYSCALL_INTERRUPT_PRIORITY用来设置可以在中断服务程序中安全调用FreeRTOS API函数的最高中断优先级。优先级小于等于这个宏所代表的优先级时，程序可以在中断服务程序中安全的调用FreeRTOS API函数；如果优先级大于这个宏所代表的优先级，表示FreeRTOS无法禁止这个中断，在这个中断服务程序中绝不可以调用任何API函数。
通过设置configMAX_SYSCALL_INTERRUPT_PRIORITY的优先级级别高于configKERNEL_INTERRUPT_PRIORITY可以实现完整的中断嵌套模式。这意味着FreeRTOS内核不能完全禁止中断，即使在临界区。此外，这对于分段内核架构的微处理器是有利的。请注意，当一个新中断发生后，某些微处理器架构会（在硬件上）禁止中断，这意味着从硬件响应中断到FreeRTOS重新使能中断之间的这段短时间内，中断是不可避免的被禁止的。
不调用API的中断可以运行在比configMAX_SYSCALL_INTERRUPT_PRIORITY高的优先级，这些级别的中断不会被FreeRTOS禁止，因此不会因为执行RTOS内核而被延时。
例如：假如一个微控制器有8个中断优先级别：0表示最低优先级，7表示最高优先级（Cortex-M3和Cortex-M4内核优先数和优先级别正好与之相反，后续文章会专门介绍它们）。当两个配置选项分别为4和0时，下图描述了每一个优先级别可以和不可做的事件：
这些配置参数允许非常灵活的中断处理：
在系统中可以像其它任务一样为中断处理任务分配优先级。这些任务通过一个相应中断唤醒。中断服务例程（ISR）内容应尽可能的精简---仅用于更新数据然后唤醒高优先级任务。ISR退出后，直接运行被唤醒的任务，因此中断处理（根据中断获取的数据来进行的相应处理）在时间上是连续的，就像ISR在完成这些工作。这样做的好处是当中断处理任务执行时，所有中断都可以处在使能状态。
中断、中断服务例程（ISR）和中断处理任务是三码事：当中断来临时会进入中断服务例程，中断服务例程做必要的数据收集（更新），之后唤醒高优先级任务。这个高优先级任务在中断服务例程结束后立即执行，它可能是其它任务也可能是中断处理任务，如果是中断处理任务，那么就可以根据中断服务例程中收集的数据做相应处理。
configMAX_SYSCALL_INTERRUPT_PRIORITY接口有着更深一层的意义：在优先级介于RTOS内核中断优先级（等于configKERNEL_INTERRUPT_PRIORITY）和configMAX_SYSCALL_INTERRUPT_PRIORITY之间的中断允许全嵌套中断模式并允许调用API函数。大于configMAX_SYSCALL_INTERRUPT_PRIORITY的中断优先级绝不会因为执行RTOS内核而延时。
运行在大于configMAX_SYSCALL_INTERRUPT_PRIORITY的优先级中断是不会被RTOS内核所屏蔽的，因此也不受RTOS内核功能影响。这主要用于非常高的实时需求中。比如执行电机转向。但是，这类中断的中断服务例程中绝不可以调用FreeRTOS的API函数。
为了使用这个方案，应用程序要必须符合以下规则：调用FreeRTOS API函数的任何中断，都必须和RTOS内核处于同一优先级（由宏configKERNEL_INTERRUPT_PRIORITY设置），或者小于等于宏configMAX_SYSCALL_INTERRUPT_PRIORITY定义的优先级。
2.48 configASSERT
configASSERT()宏的语义与标准的C assert()宏相同。如果传递给configASSERT()的参数为零，则会触发断言。configASSERT()在整个FreeRTOS源文件中被调用，以检查应用程序如何使用FreeRTOS。强烈建议在开发FreeRTOS应用程序时定义configASSERT()。示例定义(显示在文件顶部并在下面复制)调用vAssertCalled()，传入触发configASSERT()调用的文件名和行号(
FILE
和
LINE
是大多数编译器提供的标准宏)。这只是为了演示，因为vAssertCalled()不是一个FreeRTOS函数，可以定义configASSERT()来执行应用程序作者认为合适的任何操作。通常以这样一种方式定义configASSERT()，它将阻止应用程序进一步执行。这有两个原因;在断言点停止应用程序允许对断言的原因进行调试，并且在触发断言之后执行可能会导致崩溃。注意，定义configASSERT()将增加应用程序代码大小和执行时间。当应用程序稳定时，可以通过注释掉FreeRTOSConfig.h中的configASSERT()定义来消除额外的开销。
/* 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__ )
如果在调试器的控制下运行FreeRTOS，则可以将configASSERT()定义为仅禁用中断并处于循环中，如下所示。这将有停止在断言测试失败的行上的代码的效果-暂停调试器将立即带您到有问题的行，以便您可以看到它失败的原因。
/* Define configASSERT() to disable interrupts and sit in a loop. */
#define configASSERT ( x ) if( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for( ;; ); }
2.49 configINCLUDE_APPLICATION_DEFINED_PRIVILEGED_FUNCTIONS
只被FreeRTOSMPU使用。如果configINCLUDE_APPLICATION_DEFINED_PRIVILEGED_FUNCTIONS设置为1，那么应用程序编写器必须提供一个名为“application_defined_privileged_functions.h”的头文件，在这个头文件中，应用程序编写器需要在特权模式下执行的函数可以实现。注意，尽管头文件的扩展名是.h，但它应该包含C函数的实现，而不仅仅是函数的原型。在"application_defined_privileged_functions.h"中实现的函数必须分别使用prvRaisePrivilege()函数和portRESET_PRIVILEGE()宏保存和恢复处理器的特权状态。例如，如果提供打印函数的库访问的RAM不在应用程序编写人员的控制范围内，因此不能分配给受内存保护的用户模式任务，则可以使用以下代码将打印函数封装在特权函数中:
1void MPU_debug_printf( const char *pcMessage ) 2{ 3/* State the privilege level of the processor when the function was called. */ 4BaseType_t xRunningPrivileged = prvRaisePrivilege(); 5 6/* Call the library function, which now has access to all RAM. */ 7debug_printf( pcMessage ); 8 9/* Reset the processor privilege level to its original value. */ 10portRESET_PRIVILEGE( xRunningPrivileged ); 11}
2.50 configTOTAL_MPU_REGIONS
用于ARM Cortex-M4微控制器的FreeRTOS MPU(内存保护单元)端口支持16个MPU区域的设备。对于有16个MPU区域的设备，将“configTOTAL_MPU_REGIONS”设置为“16”。如果未定义，则默认为8。
2.51 configTEX_S_C_B_FLASH
TEX, Shareable (S)， Cacheable (C)和buffable (B)位定义了内存类型，必要时还定义了MPU区域的可缓存和可共享属性。configTEX_S_C_B_FLASH允许应用程序编写者重写用于MPU区域覆盖Flash的for TEX，共享(S)，可缓存(C)和可缓冲(B)位的默认值。如果未定义，它默认为0x07UL，这意味着TEX=000, S=1, C=1, B=1。
2.52 configTEX_S_C_B_SRAM
TEX, Shareable (S)， Cacheable (C)和buffable (B)位定义了内存类型，必要时还定义了MPU区域的可缓存和可共享属性。configTEX_S_C_B_SRAM允许应用程序编写人员覆盖覆盖RAM的MPU区域的for TEX，可共享(S)，可缓存(C)和可缓冲(B)位的默认值。如果未定义，它默认为0x07UL，这意味着TEX=000, S=1, C=1, B=1。
2.53 configENFORCE_SYSTEM_CALLS_FROM_KERNEL_ONLY
configenfort_system_calls_from_kernel_only可以定义为1，以防止任何来自内核代码外部的特权升级(当进入中断时由硬件本身执行的升级除外)。当FreeRTOSConfig.h中的configENFORCE_SYSTEM_CALLS_FROM_KERNEL_ONLY设置为1时，需要从链接器脚本中导出变量
syscalls_flash_start
和
syscalls_flash_end
，分别表示系统调用内存的起始地址和结束地址。为了获得最大的安全性，建议将其定义为1。
2.54 configALLOW_UNPRIVILEGED_CRITICAL_SECTIONS
ARMv7-M MPU端口(ARM Cortex-M3/4/7)。设置为0以防止非特权应用程序任务使用taskENTER_CRITICAL()宏创建临界区。将该常量设置为1，或不定义，以允许特权任务和非特权任务创建临界区。注意:建议将此常量定义为0以获得最大的安全性;因此，如果常量未定义，则会输出编译器警告。
2.55 configENABLE_ERRATA_837070_WORKAROUND
仅支持Cortex-M4d的MPU。
当使用Cortex-M7 r0p0/r0p1内核上的Cortex-M4 MPU端口时，将configENABLE_ERRATA_837070_WORKAROUND设置为1，以确保ARM errata 837070所需的workaround处于激活状态。
2.56 configHEAP_CLEAR_MEMORY_ON_FREE
如果设置为1，则使用pvPortMalloc()分配的内存块将在使用vPortFree()释放时被清除。如果未定义，为了向后兼容性，configHEAP_CLEAR_MEMORY_ON_FREE默认为0。为了更好的安全性，我们建议将configHEAP_CLEAR_MEMORY_ON_FREE设置为1。
2.57 secureconfigMAX_SECURE_CONTEXTS
仅限ARMv8-M安全侧端口。从ARMv8-M MCU的非安全端(ARM Cortex-M23, Cortex-M33和Cortex-M55)调用安全函数的任务有两个上下文——一个在非安全端，一个在安全端。在FreeRTOS v10.4.5之前，ARMv8-M安全端端口在运行时分配了引用安全端上下文的结构。从FreeRTOS V10.4.5开始，结构是在编译时静态分配的。secureconfigMAX_SECURE_CONTEXTS设置静态分配的安全上下文的数量。如果未定义，secureconfigMAX_SECURE_CONTEXTS默认为8。仅在ARMv8-M微控制器的非安全端使用FreeRTOS代码的应用程序，例如在安全端运行第三方代码的应用程序，不需要此常量。
2.58 INCLUDE Parameters
以'INCLUDE'开头的宏允许将应用程序未使用的实时内核组件从构建中排除。这确保RTOS不会使用超出特定嵌入式应用程序所需的ROM或RAM。
每个宏以这样的形式出现：
INCLUDE_FunctionName
在这里FunctionName表示一个你可以控制是否编译的API函数。如果你想使用该函数，就将这个宏设置成1，如果不想使用，就将这个宏设置成0。比如，对于API函数vTaskDelete()：
#define INCLUDE_vTaskDelete 1
表示希望使用vTaskDelete()，允许编译器编译该函数
#define INCLUDE_vTaskDelete 0
