功能配置

AC792 SDK 采用「编译期宏配置」体系：以 board_config.h（板级）、app_config.h（应用级）与模块级头文件（如 audio_cvp.h、uartPcmSender.h）中的 TCFG_* / CONFIG_* 预处理宏，在编译阶段裁剪蓝牙、音频、协议与调试功能，实现零运行时开销的固件定制。

Purpose and Scope

本文档说明 AC792N SDK（release/AC792N_SDK_V3）功能配置体系的工作原理与使用方法，包括：

配置宏的分层结构与加载顺序（board_config.h → app_config.h → 模块头文件）；
CONFIG_* 总开关与 TCFG_* 功能开关的语义（打印、栈检查、蓝牙/BLE、音频算法、数据导出等）；
第三方协议位掩码选择机制（THIRD_PARTY_PROTOCOLS_SEL）；
ENABLE_THIS_MOUDLE 模块使能模式与编译期 IO 冲突检查；
LIB_DEBUG / CONFIG_DEBUG_LIB 的发布版调试开关机制。

本页不涉及具体某个 demo 的完整外设驱动配置（如 LED、编码器、Flash 分区等），这些属于各自的板级/驱动配置页；也不展开 RCSP、LE Audio、涂鸦等具体协议实现——它们由 THIRD_PARTY_PROTOCOLS_SEL 选中后按各自的模块文档说明。各 demo 的差异化功能请参考对应 demo 页面。

Overview

AC792 是杰理（Jieli）面向 TWS 耳机、穿戴与音频设备的蓝牙 SoC 平台。其 SDK 采用编译期特性裁剪（compile-time feature toggling）的经典嵌入式做法：

工程师在头文件中通过 #define 定义或注释宏；
C 预处理器根据宏在 #ifdef / #if 分支中保留或剔除代码段；
编译器只链接被保留的代码，未使能功能（如某个第三方协议、某个音频算法库）完全不进入固件。

这种设计带来三个关键收益：

零运行时开销：所有功能开关在编译期决定，if (1) 与 if (0) 的分支在优化后不存在，不占用 RAM/Flash；
可裁剪性：不同量产机型只需改宏，即可产出不同功能组合的固件（例如开 BLE 关经典蓝牙、选 AEC 单麦/双麦/三麦算法）；
冲突前置：IO 复用、模块互斥等错误可以在编译期用 #error 直接暴露，而不是等硬件联调时才暴露。

核心配置项统一使用 TCFG_（Target ConFiG）前缀以区别于普通代码宏；调试开关使用 CONFIG_ 前缀；第三方协议选择使用一个 32 位位掩码宏 THIRD_PARTY_PROTOCOLS_SEL 单选。

Architecture

功能配置的完整链路从板级硬件配置出发，逐层汇入应用配置，最终被 SDK 库（蓝牙协议栈、音频算法、外设驱动）在编译时消费：

flowchart TD
    subgraph sg_Board["板级配置层"]
        BC["board_config.h<br/>硬件IO / 时钟 / Flash / 内存布局"]
    end

    subgraph sg_App["应用配置层"]
        AC["app_config.h<br/>功能总开关 CONFIG_*<br/>功能开关 TCFG_*<br/>协议选择 THIRD_PARTY_PROTOCOLS_SEL"]
    end

    subgraph sg_Module["模块配置层"]
        CVP["audio_cvp.h<br/>AEC / 单双三麦 / DMS_SEL"]
        PCM["uartPcmSender.h<br/>数据导出UART / 模块使能开关"]
    end

    subgraph sg_Lib["SDK 库（编译期裁剪）"]
        LIB["蓝牙协议栈 / 音频算法库 / 外设驱动"]
    end

    BC -->|"#include 引入"| AC
    AC -->|"TCFG_* 宏"| CVP
    AC -->|"TCFG_* 宏"| PCM
    AC -->|"CONFIG_BT_ENABLE 等"| LIB
    CVP -->|"裁剪后接口"| LIB
    PCM -->|"裁剪后接口"| LIB

各层职责：

板级配置层（board_config.h）：描述具体硬件平台——IO 引脚分配、时钟、Flash、内存布局等，是所有 demo app_config.h 的第一行 #include；
应用配置层（app_config.h）：面向产品功能的开关集合，是工程师日常修改最多的文件；demo_ble、demo_hello、demo_ui、wifi_bbm、wifi_camera、wifi_soundbox 等每个应用各有独立副本；
模块配置层：单个软件模块的私有配置头文件，消费上层 TCFG_* 宏做内部剪裁（如音频算法按麦克风数量选择算法库、UART PCM 导出按引脚宏配置串口）；
SDK 库：最终根据宏裁剪后的代码被编译进固件。

配置宏在编译期的消费流程如下：

flowchart TD
    Start["工程师编辑配置头文件<br/>(app_config.h / board_config.h)"] --> Guard{"宏是否已定义 / 求值?"}
    Guard -->|"是 (ENABLE_THIS_MOUDLE / 1)"| Branch["#ifdef / #if 分支保留代码"]
    Guard -->|"否 (注释或 0)"| Skip["对应代码段被剔除"]
    Branch --> Check{"IO 冲突 / 宏互斥?"}
    Check -->|"冲突"| Err["#error 编译期报错<br/>(如引脚复用)"]
    Err --> Start
    Check -->|"无冲突"| Compile["编译链接"]
    Skip --> Compile
    Compile --> Bin["固件镜像（按配置裁剪）"]

每个应用的 app_config.h 第一行都会 #include "board_config.h"，板级文件定义硬件相关的 IO 与资源参数。例如 demo_ble、wifi_bbm、wifi_camera、wifi_soundbox 的 app_config.h 第 15 行左右均存在该引用（如 wifi_bbm/app_config.h）。它回答的问题是「这块板子长什么样」：LED 引脚、按键、UART 调试口、Flash 型号、内存布局等。同一应用代码更换硬件平台时通常只改这一层。

2. `app_config.h` — 应用功能开关（核心配置入口）

以 demo_ble 为例，文件顶部即应用级总开关（见 demo_ble/app_config.h）：

#define CONFIG_DEBUG_ENABLE                             //打印开关

#define CONFIG_RTOS_STACK_CHECK_ENABLE                  //是否启用定时检查任务栈
// #define CONFIG_MEM_LEAK_CHECK_ENABLE                 //是否启用内存泄漏检查(需要包含mem_leak_test.h头文件)

设计要点：

CONFIG_DEBUG_ENABLE 这类定义即启用的开关，靠 #ifdef 判断，不需要赋值；
CONFIG_MEM_LEAK_CHECK_ENABLE 默认被注释（关闭），且注释明确提示使用前提「需要包含 mem_leak_test.h 头文件」——说明部分调试开关依赖额外的头文件/模块，开启前需先确认依赖存在；
CONFIG_RTOS_STACK_CHECK_ENABLE 启用后系统会定时检查任务栈，是开发期排查栈溢出的利器，量产固件通常关闭以省去定时器开销。

3. BT/BLE 功能配置段

app_config.h 中的 #ifdef CONFIG_BT_ENABLE 段整体包住蓝牙相关配置（见 demo_ble/app_config.h）：

#ifdef CONFIG_BT_ENABLE

#define TCFG_BT_MODE                            BT_NORMAL   //BT_BQB

#define TCFG_USER_BLE_ENABLE                    1   //BLE功能使能
#define TCFG_USER_BT_CLASSIC_ENABLE             0   //经典蓝牙功能
#define TCFG_POWER_ON_ENABLE_BLE                0   //开机自动打开BLE

#define TCFG_TRANS_MULTI_BLE_SLAVE_NUMS         1
#define TCFG_TRANS_MULTI_BLE_MASTER_NUMS        2

#endif

关键语义：

CONFIG_BT_ENABLE 是蓝牙功能总开关：未定义时整段配置被预处理器剔除，BLE/经典蓝牙/协议全部不编译，适合纯音频外设应用；
TCFG_BT_MODE 取值 BT_NORMAL（注释提示可换 BT_BQB）——用于切换量产模式与 BQB 认证模式；
TCFG_USER_BLE_ENABLE / TCFG_USER_BT_CLASSIC_ENABLE 是 0/1 二值开关，demo_ble 默认 只开 BLE、关经典蓝牙；
TCFG_POWER_ON_ENABLE_BLE 控制开机后是否立即自动打开 BLE 广播，0 表示需由应用主动触发；
TCFG_TRANS_MULTI_BLE_SLAVE_NUMS / TCFG_TRANS_MULTI_BLE_MASTER_NUMS 配置多连接场景下的从机/主机连接数量，直接影响协议栈连接资源（RAM）的分配。

4. 第三方协议位掩码选择（`THIRD_PARTY_PROTOCOLS_SEL`）

SDK 把十余种第三方协议/特性映射到 32 位位掩码的各位，通过单一宏 THIRD_PARTY_PROTOCOLS_SEL 选择（见 demo_ble/app_config.h）：

#define RCSP_MODE_EN                            (1 << 0)
#define TRANS_DATA_EN                           (1 << 1)
#define LL_SYNC_EN                              (1 << 2)
#define TUYA_DEMO_EN                            (1 << 3)
#define ANCS_CLIENT_EN                          (1 << 4)
#define GFPS_EN                                 (1 << 5)
#define REALME_EN                               (1 << 6)
#define TME_EN                                  (1 << 7)
#define DMA_EN                                  (1 << 8)
#define GMA_EN                                  (1 << 9)
#define MMA_EN                                  (1 << 10)
#define FMNA_EN                                 (1 << 11)
#define SWIFT_PAIR_EN                           (1 << 12)
#define LE_AUDIO_CIS_RX_EN                      (1 << 13)
#define LE_AUDIO_CIS_TX_EN                      (1 << 14)
#define LE_AUDIO_BIS_RX_EN                      (1 << 15)
#define LE_AUDIO_BIS_TX_EN                      (1 << 16)
#define HONOR_EN                                (1 << 17)
#define ONLINE_DEBUG_EN                         (1 << 18)
#define CUSTOM_DEMO_EN                          (1 << 19)   // 第三方协议的demo，用于示例客户开发自定义协议
#define MULTI_BOX_ADV_EN                        (1 << 20)
#define MIJIA_EN                                (1 << 21)
#define CLIENT_EN                               (1 << 27)
#define DUEROS_EN                               (1 << 28)
#define NET_CFG_EN                              (1 << 29)
#define LE_HOGP_EN                              (1 << 30)
#define ALIPAY_EN                               (1 << 31)

#define THIRD_PARTY_PROTOCOLS_SEL               CUSTOM_DEMO_EN

该机制的工程意图：

位掩码 vs 独立宏：把协议开关集中在 32 位内，便于整体管理、序列化（可存入 Flash 配置）与统一判断；协议模块内部用 THIRD_PARTY_PROTOCOLS_SEL & XXX_EN 判断是否编译自己的逻辑；
单选约定：THIRD_PARTY_PROTOCOLS_SEL 一次只能赋一个 XXX_EN，从协议栈顶层看是「当前启用哪套第三方协议」的枚举语义，避免多协议同时使能导致的服务冲突；
扩展点：CUSTOM_DEMO_EN（bit 19）被明确注释为「第三方协议的 demo，用于示例客户开发自定义协议」——客户新协议只需占用一个新位并让 THIRD_PARTY_PROTOCOLS_SEL 指向它，即可挂进现有框架；
低位（bit 0–21）与高位（bit 27–31）之间的空位（22–26）保留给后续新协议，无需改变既有值，保持向后兼容。

5. `ENABLE_THIS_MOUDLE` — 模块使能开关模式

SDK 对可裁剪模块采用「TCFG_XXX_ENABLE == ENABLE_THIS_MOUDLE」的约定：ENABLE_THIS_MOUDLE 是一个全局约定的「使能」值，模块是否编译由该比较表达式决定。典型例子是调试串口与 PCM 数据导出共用引脚时的冲突检查（见 uartPcmSender.h）：

// #if ((TCFG_DEBUG_UART_ENABLE == ENABLE_THIS_MOUDLE) && (PCM_UART1_TX_PORT == TCFG_DEBUG_UART_TX_PIN))
// //IO口配置冲突，请检查修改
// #error "PCM_UART1_TX_PORT conflict with TCFG_DEBUG_UART_TX_PIN"

设计要点：

统一使能值：ENABLE_THIS_MOUDLE 让所有模块的「开」语义一致（而不是各自定义 1/TRUE/ON），降低不同模块配置约定不一致的出错率；
编译期互斥检查：当调试串口模块使能、且其 TX 引脚与 PCM 数据导出的 TX 引脚相同时，#error 会在编译期直接中断并给出中文提示「IO口配置冲突，请检查修改」——把硬件复用错误提前到构建阶段，这是嵌入式配置体系中典型的防呆设计；
同一模式也出现在音频模块：audio_cvp.h 中 AEC_READ_CONFIG（置 1）与 AEC_DEBUG_ONLINE（置 0）构成调试开关对，线上版本保持 AEC_DEBUG_ONLINE = 0 以关闭在线调试。

6. `LIB_DEBUG` 与 `CONFIG_DEBUG_LIB` — 库调试开关

SDK 库内部的调试打印由 LIB_DEBUG 位标志控制，app_config.h 在文件末尾统一收口（见 demo_ble/app_config.h）：

#ifdef CONFIG_RELEASE_ENABLE
#define LIB_DEBUG    0
#else
#define LIB_DEBUG    1
#endif
#define CONFIG_DEBUG_LIB(x)         (x & LIB_DEBUG)

CONFIG_RELEASE_ENABLE 定义时（发布版）LIB_DEBUG 归零，库内所有 CONFIG_DEBUG_LIB(x) 判断恒为假，调试代码被优化掉；
非发布版 LIB_DEBUG = 1，各库按自己的位标志 x 选择性打印，CONFIG_DEBUG_LIB(x) 本质是「是否发布版」与「库内功能位」的与运算；
个别应用（如 wifi_camera/app_config.h）在启用 TCFG_DEBUG_DLOG_ENABLE（dlog 串口打印）时会 #undef LIB_DEBUG 后强制重定义为 1，并重定义 CONFIG_DEBUG_LIB——演示了「应用层可以覆盖库默认调试级别」的扩展手法：

#if (defined(LIB_DEBUG) && TCFG_DEBUG_DLOG_ENABLE)
#undef LIB_DEBUG
#define LIB_DEBUG    1
#undef CONFIG_DEBUG_LIB
#define CONFIG_DEBUG_LIB(x)         (x & LIB_DEBUG)
#endif

7. 音频算法配置（`audio_cvp.h`）

音频/通话（CVP，Communication Voice Processing）模块按麦克风数量和算法档位选择实现，全部通过 TCFG_* 宏在编译期决定（见 audio_cvp.h）：

#if TCFG_AUDIO_TRIPLE_MIC_ENABLE
#include "cvp_tms.h"
#elif TCFG_AUDIO_DUAL_MIC_ENABLE
#include "cvp_dms.h"
#endif

#if (TCFG_AUDIO_DMS_SEL == DMS_NORMAL)
#define aec_open		aec_dms_init
#elif (TCFG_AUDIO_DMS_SEL == DMS_FLEXIBLE)
#define aec_open		aec_dms_flexible_init
#elif (TCFG_AUDIO_DMS_SEL == DMS_HYBRID)
#define aec_open		aec_dms_hybrid_init
#elif (TCFG_AUDIO_DMS_SEL == DMS_AWN)
#define aec_open		aec_dms_awn_init
#endif

TCFG_AUDIO_TRIPLE_MIC_ENABLE / TCFG_AUDIO_DUAL_MIC_ENABLE 互斥地决定包含三麦（cvp_tms.h）还是双麦（cvp_dms.h）算法库——头文件级剪裁，未选的算法整个不参与编译，直接节省 Flash；
TCFG_AUDIO_DMS_SEL 是枚举档位选择（DMS_NORMAL / DMS_FLEXIBLE / DMS_HYBRID / DMS_AWN），通过 #define aec_open ... 把统一的调用名映射到不同的算法实现——这是「编译期多态」：上层代码只调用 aec_open()，具体指向哪个算法由配置宏决定；
同头文件还定义了单麦使能位 TDE_EN（BIT(5)，延时估计模块）与 MFDT_EN（BIT(6)），并注明约束：「仅单麦使用，TDE_EN 和 TDEYE_EN 只有在 TCFG_AUDIO_SMS_SEL = SMS_TDE 有效」——即功能位与档位宏存在依赖关系，配置错误时不会编译报错，但功能不生效，这是宏体系里需要靠文档约束的一类边界。

8. 数据导出配置（`uartPcmSender.h`）

UART PCM 数据导出（用于抓取音频 PCM 流做调试/算法联调）完全由上层宏驱动，模块内再作合法性检查（见 uartPcmSender.h）：

// #ifdef TCFG_DATA_EXPORT_UART_TX_PORT
// #define PCM_UART1_TX_PORT			TCFG_DATA_EXPORT_UART_TX_PORT	[>数据导出发送IO<]
...
// #ifdef TCFG_DATA_EXPORT_UART_BAUDRATE
// #define PCM_UART1_BAUDRATE			TCFG_DATA_EXPORT_UART_BAUDRATE

TCFG_DATA_EXPORT_UART_TX_PORT / TCFG_DATA_EXPORT_UART_BAUDRATE 由应用层（board_config.h / app_config.h）定义，模块把其映射为内部实现宏 PCM_UART1_TX_PORT / PCM_UART1_BAUDRATE；
该文件全篇为注释态示例代码，配合「数据导出波特率,不用修改，和接收端设置一直」的注释，说明它是一份配置模板：需要该功能时取消注释并按目标 IO 填入；
与第 5 节的 #error 检查配合，可确保导出引脚不与调试串口冲突——数据导出和调试日志往往都想用同一空闲 UART，编译期检查从源头避免「同一引脚两用」的硬件故障。

Core Flow — 配置的端到端生效过程

一次功能配置修改从编辑头文件到固件生效，经历了严格的编译期流水线：

sequenceDiagram
    participant Dev as 开发者
    participant H as 配置头文件<br/>(board_config.h / app_config.h)
    participant PP as C 预处理器
    participant SDK as SDK 库 / 模块头文件
    participant L as 编译链接 / 固件

    Dev->>H: 修改 / 新增 TCFG_*、CONFIG_* 宏
    H->>PP: #include 展开 (board_config → app_config → 模块)
    PP->>SDK: 提供宏定义状态 (定义值 / 是否定义)
    SDK->>PP: #ifdef / #if 分支求值
    alt 宏未使能
        PP-->>L: 剔除对应代码段 (不编译)
    else 宏使能且无冲突
        PP->>L: 保留裁剪后的代码
    end
    PP-->>Dev: 冲突时 #error 中断编译
    L-->>Dev: 输出按配置裁剪的固件镜像

实际调试时的推荐验证顺序：

确认宏归属层：硬件相关（IO、时钟）改 board_config.h，功能相关（协议、调试、音频）改 app_config.h；
确认依赖前置：如 CONFIG_MEM_LEAK_CHECK_ENABLE 需先包含 mem_leak_test.h；TDE_EN 需 TCFG_AUDIO_SMS_SEL = SMS_TDE；
确认互斥/冲突：如三麦与双麦互斥、PCM 导出引脚与调试串口引脚不得相同——冲突由 #error 在编译期报出；
确认发布版差异：CONFIG_RELEASE_ENABLE 会把 LIB_DEBUG 归零，某些只在调试态可见的功能（如 dlog 打印）在发布版会被自动裁剪。

Usage Examples

基础用法：裁剪出一个「仅 BLE」的固件

demo_ble 默认即演示该组合——关闭经典蓝牙、开启 BLE（见 demo_ble/app_config.h）：

#ifdef CONFIG_BT_ENABLE

#define TCFG_BT_MODE                            BT_NORMAL   //BT_BQB

#define TCFG_USER_BLE_ENABLE                    1   //BLE功能使能
#define TCFG_USER_BT_CLASSIC_ENABLE             0   //经典蓝牙功能
#define TCFG_POWER_ON_ENABLE_BLE                0   //开机自动打开BLE

#define TCFG_TRANS_MULTI_BLE_SLAVE_NUMS         1
#define TCFG_TRANS_MULTI_BLE_MASTER_NUMS        2

#endif

若产品需要经典蓝牙（如普通蓝牙音箱），只需把 TCFG_USER_BT_CLASSIC_ENABLE 改为 1；若产品完全不需要蓝牙（纯语音播放器），注释掉 #define CONFIG_BT_ENABLE 即可让整段配置与对应协议栈代码不参与编译。

进阶用法：切换第三方协议

将 THIRD_PARTY_PROTOCOLS_SEL 从默认的 CUSTOM_DEMO_EN 改为目标协议，例如接入涂鸦（TUYA）智能生态（位定义见 demo_ble/app_config.h）：

#define THIRD_PARTY_PROTOCOLS_SEL               TUYA_DEMO_EN

选中后，协议栈内形如 #if (THIRD_PARTY_PROTOCOLS_SEL & TUYA_DEMO_EN) 的代码分支才会编译，未选中的 RCSP、GFPS、Swift Pair、LE Audio 等实现全部被裁剪，固件体积与启动时间随之下降。

进阶用法：启用 dlog 调试并强制库打印

需要串口 dlog 时，先定义 TCFG_DEBUG_DLOG_ENABLE 与打印引脚 TCFG_DEBUG_DLOG_UART_TX_PIN，并允许应用覆盖库的 LIB_DEBUG（见 wifi_camera/app_config.h）：

#if (defined(LIB_DEBUG) && TCFG_DEBUG_DLOG_ENABLE)
#undef LIB_DEBUG
#define LIB_DEBUG    1
#undef CONFIG_DEBUG_LIB
#define CONFIG_DEBUG_LIB(x)         (x & LIB_DEBUG)
#endif

该模式说明：即便库在发布版把 LIB_DEBUG 归零，应用仍可在启用 dlog 时用 #undef + 重定义强制恢复库内调试打印，便于现场联调。

进阶用法：选择双麦降噪算法档位

产品为双麦时，按算法需求设置 TCFG_AUDIO_DUAL_MIC_ENABLE 与 TCFG_AUDIO_DMS_SEL，上层统一调用 aec_open() 即可（映射见 audio_cvp.h）：

#if (TCFG_AUDIO_DMS_SEL == DMS_NORMAL)
#define aec_open		aec_dms_init
#elif (TCFG_AUDIO_DMS_SEL == DMS_FLEXIBLE)
#define aec_open		aec_dms_flexible_init
#elif (TCFG_AUDIO_DMS_SEL == DMS_HYBRID)
#define aec_open		aec_dms_hybrid_init
#elif (TCFG_AUDIO_DMS_SEL == DMS_AWN)
#define aec_open		aec_dms_awn_init
#endif

更换算法档位只需改 TCFG_AUDIO_DMS_SEL 一个宏，调用方代码完全不变——这是「编译期多态」带来的可维护性收益。

Configuration Options

应用级总开关（`CONFIG_*`，demo_ble 默认值）

宏	类型	默认	说明
`CONFIG_DEBUG_ENABLE`	定义即启用	启用	打印开关，注释则关闭全部打印
`CONFIG_RTOS_STACK_CHECK_ENABLE`	定义即启用	启用	定时检查任务栈，开发期排查栈溢出
`CONFIG_MEM_LEAK_CHECK_ENABLE`	定义即启用	关闭（被注释）	内存泄漏检查，需包含 `mem_leak_test.h`
`CONFIG_BT_ENABLE`	定义即启用	启用	蓝牙（BLE+经典）功能总开关
`CONFIG_RELEASE_ENABLE`	定义即启用	关闭	发布版模式，使 `LIB_DEBUG = 0`

BT/BLE 功能开关（`TCFG_*`，demo_ble 默认值）

宏	类型	默认	说明
`TCFG_BT_MODE`	枚举	`BT_NORMAL`	蓝牙工作模式，BQB 认证时改 `BT_BQB`
`TCFG_USER_BLE_ENABLE`	0/1	1	BLE 功能使能
`TCFG_USER_BT_CLASSIC_ENABLE`	0/1	0	经典蓝牙功能使能
`TCFG_POWER_ON_ENABLE_BLE`	0/1	0	开机自动打开 BLE
`TCFG_TRANS_MULTI_BLE_SLAVE_NUMS`	整数	1	多连接从机数量
`TCFG_TRANS_MULTI_BLE_MASTER_NUMS`	整数	2	多连接主机数量

第三方协议位掩码（`THIRD_PARTY_PROTOCOLS_SEL` 可取值）

宏	位值	协议/特性
`RCSP_MODE_EN`	`1<<0`	RCSP 模式
`TRANS_DATA_EN`	`1<<1`	数据传输
`LL_SYNC_EN`	`1<<2`	LL 同步
`TUYA_DEMO_EN`	`1<<3`	涂鸦智能
`ANCS_CLIENT_EN`	`1<<4`	ANCS 客户端（iOS 通知）
`GFPS_EN`	`1<<5`	Google Fast Pair
`REALME_EN`	`1<<6`	realme 协议
`TME_EN`	`1<<7`	TME 协议
`DMA_EN`	`1<<8`	DMA 协议
`GMA_EN`	`1<<9`	GMA 协议
`MMA_EN`	`1<<10`	MMA 协议
`FMNA_EN`	`1<<11`	FMNA 协议
`SWIFT_PAIR_EN`	`1<<12`	微软 Swift Pair
`LE_AUDIO_CIS_RX_EN`	`1<<13`	LE Audio CIS 接收
`LE_AUDIO_CIS_TX_EN`	`1<<14`	LE Audio CIS 发送
`LE_AUDIO_BIS_RX_EN`	`1<<15`	LE Audio BIS 接收
`LE_AUDIO_BIS_TX_EN`	`1<<16`	LE Audio BIS 发送
`HONOR_EN`	`1<<17`	荣耀协议
`ONLINE_DEBUG_EN`	`1<<18`	在线调试
`CUSTOM_DEMO_EN`	`1<<19`	自定义协议 demo（默认）
`MULTI_BOX_ADV_EN`	`1<<20`	多箱广播
`MIJIA_EN`	`1<<21`	米家
`CLIENT_EN`	`1<<27`	客户端协议
`DUEROS_EN`	`1<<28`	小度（DuerOS）
`NET_CFG_EN`	`1<<29`	网络配网
`LE_HOGP_EN`	`1<<30`	LE HOGP
`ALIPAY_EN`	`1<<31`	支付宝

音频算法配置（CVP 模块）

宏	说明
`TCFG_AUDIO_TRIPLE_MIC_ENABLE`	三麦使能，包含 `cvp_tms.h`
`TCFG_AUDIO_DUAL_MIC_ENABLE`	双麦使能，包含 `cvp_dms.h`
`TCFG_AUDIO_DMS_SEL`	DMS 档位：`DMS_NORMAL` / `DMS_FLEXIBLE` / `DMS_HYBRID` / `DMS_AWN`
`TCFG_AUDIO_SMS_SEL`	SMS 档位，`SMS_TDE` 时 `TDE_EN` 才有效
`AEC_READ_CONFIG` / `AEC_DEBUG_ONLINE`	AEC 配置读取 / 在线调试开关（线上置 0）

串口/数据导出配置

宏	说明
`TCFG_DEBUG_UART_ENABLE`	调试串口使能（`== ENABLE_THIS_MOUDLE` 才生效）
`TCFG_DEBUG_UART_TX_PIN`	调试串口 TX 引脚
`TCFG_DEBUG_DLOG_ENABLE` / `TCFG_DEBUG_DLOG_UART_TX_PIN`	dlog 打印开关及其引脚
`TCFG_DATA_EXPORT_UART_TX_PORT`	PCM 数据导出发送 IO
`TCFG_DATA_EXPORT_UART_BAUDRATE`	PCM 数据导出波特率（需与接收端一致）

Failure Modes、边界情况与并发

IO 引脚冲突（编译期捕获）：当调试串口与 PCM 数据导出的 TX 引脚相同且两模块均使能时，uartPcmSender.h 中的 #error 直接终止编译，提示「IO口配置冲突，请检查修改」。该机制把硬件复用错误前置到构建阶段，避免烧录后才发现功能异常。

宏依赖未被满足（静默失效）：部分功能位与档位宏存在隐式依赖，例如 TDE_EN（延时估计）仅在 TCFG_AUDIO_SMS_SEL = SMS_TDE 时有效；CONFIG_MEM_LEAK_CHECK_ENABLE 需要先包含 mem_leak_test.h。这类配置错误不会编译报错，只会表现为功能不生效——排查时应先核对依赖前置条件。

互斥配置：三麦（TCFG_AUDIO_TRIPLE_MIC_ENABLE）与双麦（TCFG_AUDIO_DUAL_MIC_ENABLE）在 audio_cvp.h 中以 #if / #elif 链互斥处理，同开时只有三麦分支生效；第三方协议 THIRD_PARTY_PROTOCOLS_SEL 同样约定单选，避免协议服务冲突。

发布版裁剪：CONFIG_RELEASE_ENABLE 使 LIB_DEBUG = 0 后，库内所有 CONFIG_DEBUG_LIB(x) 分支恒假，调试打印被优化器剔除；若在发布版依赖 dlog 输出排查问题，需要按 wifi_camera 的 #undef + 重定义模式显式强制开启。

并发性：功能配置是纯编译期机制，无运行时读写、无锁、无并发问题；运行时安全由被选中的代码自身保证。需要留意的只是「不同宏组合之间的兼容性矩阵」，建议在量产前对目标组合做一次全量编译 + 冒烟测试。

性能与运维要点

零运行时开销：所有裁剪在预处理/编译期完成，未使能功能的代码不进入固件，不占 Flash、不占 RAM、不增加启动时间；
固件体积控制：第三方协议与音频算法是体积大头，按产品实际需求关闭不需要的 THIRD_PARTY_PROTOCOLS_SEL 位、保持单麦/双麦/三麦仅选其一，可显著减小镜像；
调试期建议：开发阶段开启 CONFIG_RTOS_STACK_CHECK_ENABLE 与 LIB_DEBUG，量产前定义 CONFIG_RELEASE_ENABLE 并关闭调试类开关，避免打印语句拖慢实时音频路径；
多机种维护：同一 SDK 代码支撑多款机型时，各机型只需维护独立的 board_config.h + app_config.h 副本（SDK 内 demo_ble、demo_hello、demo_ui、wifi_bbm、wifi_camera、wifi_soundbox 即为此模式的实例），应用代码共享。

扩展点

自定义第三方协议：CUSTOM_DEMO_EN（bit 19）专为客户协议预留，新协议按位掩码体系挂入 THIRD_PARTY_PROTOCOLS_SEL 即可复用现有框架；
新增功能宏的规范：遵循「TCFG_ 前缀 + ENABLE_THIS_MOUDLE 使能值 + 编译期 #error 冲突检查 + 依赖注释」四件套，新模块即可无缝融入本配置体系；
调试级别覆盖：应用层可通过 #undef LIB_DEBUG + 重定义 CONFIG_DEBUG_LIB 覆盖库默认调试级别（见 wifi_camera 的 dlog 模式）。

demo_ble 应用配置（app_config.h）
wifi_camera 应用配置（含 dlog 覆盖示例）
wifi_bbm 应用配置（LIB_DEBUG 模式）
CVP 音频算法配置（audio_cvp.h）
UART PCM 数据导出配置（uartPcmSender.h）
各 demo 的差异化功能说明见对应 demo 页面（demo_ble / demo_hello / demo_ui / wifi_bbm / wifi_camera / wifi_soundbox）