尧图网站建设 
ESP-IDF 中蓝牙 SIG 认证状态详解各芯片 BLE Controller 与 Host 的合格设计编号与核心规格版本【免费下载链接】esp-idfEspressif IoT Development Framework. Official development framework for Espressif SoCs.项目地址: https://gitcode.com/GitHub_Trending/es/esp-idf本文以 ESP-IDF 官方文档docs/en/api-guides/ble/ble-qualification.rst为主体完整呈现 Espressif 蓝牙低功耗BLE协议栈在蓝牙 SIG 认证体系下的最新认证状态包括各芯片ESP32、ESP32-S3、ESP32-C2/C3/C5/C6/C61、ESP32-H2 等的 Controller 合格设计编号Design Number / QDID与通过的 Core Specification 版本以及 ESP-Bluedroid 与 ESP-NimBLE 两大 Host 的认证版本。读完本文你能够在产品认证与选型阶段快速核对某个芯片Host 组合对应的 SIG 认证编号理解 2024 年 7 月起 QDID 向 Design Number 的编号体系变更并弄清楚通过某版本认证与支持该版本全部特性之间的关键区别同时结合 ESP-IDF 仓库中components/bt组件的源码结构验证认证对象与实际代码交付形态预编译 Controller 库、两套 Host 实现的对应关系。一、为什么需要单独看待Controller 认证与Host 认证蓝牙 SIG 认证在技术架构上区分两个层次Controller控制器负责 PHY、基带、链路层、HCI 等硬件侧协议和Host主机协议栈负责 L2CAP、GATT/ATT、SMP、GAP 及各类 profile。一个完整的 BLE 产品认证需要 Controller 与 Host 各自通过认证再以产品形式在 SIG 数据库中登记。ESP-IDF 的 BLE 协议栈正是按这一分层组织的这一点在官方架构文档 BLE Overview 中有明确描述最底层是 ESP Bluetooth ControllerPHY、Baseband、Link Controller、Link Manager、Device Manager、HCI其上是两个可选择的 Host ——ESP-Bluedroid由 Android Bluedroid 栈修改而来双模芯片上同时支持经典蓝牙与ESP-NimBLE基于 Apache Mynewt 的 NimBLE Host 移植仅支持 BLE、占用更少的堆和 Flash。在 ESP-IDF 仓库中这些认证对象对应如下代码结构Controller位于 components/bt/controller/按芯片目录组织esp32/、esp32c2/、esp32c3/、esp32c5/、esp32c6/、esp32h2/等并以预编译库形式交付如lib_esp32/、lib_esp32c3_family/、lib_esp32c5/、lib_esp32c6/、lib_esp32h2/、lib_esp32s31/等。SIG 认证的正是这些 Controller 库。Host位于 components/bt/host/bluedroid/ 与 components/bt/host/nimble/即认证表中的 ESP-Bluedroid 与 ESP-NimBLE。顶层构建入口components/bt/CMakeLists.txt 分别加载 Controller 子目录与两套 Host 子目录components/bt/Kconfig 通过BT_HOST选项让用户在Bluedroid - Dual-mode与NimBLE - BLE only之间选择这正是认证表中两个 Host 的落地开关。注意模块module级别的认证不在此表范围内。若你使用的是 Espressif 成品模组如 ESP32-S3-WROOM 等模组上的认证需要另行在 Bluetooth SIG 官方的 SIG Qualification Workspace 中查询模组的认证记录。二、Controller 认证状态总表原文档核心内容下表完整继承自 ble-qualification.rst列出各芯片上 Espressif 蓝牙 LE Controller 的最新认证情况芯片认证对象模式Design Number / Qualified Design ID通过的 Core Specification 版本ESP32Bluetooth LE Mode1416615.0ESP32Dual Mode经典蓝牙 BLE1478454.2ESP32-C2ESP8684—1940095.3ESP32-C3—2394405.4ESP32-C5—Q3313186.0ESP32-C6—Q3358776.0ESP32-C61—Q3313186.0ESP32-S3—2394405.4ESP32-H2—Q3313186.0从这张表可以读出几个工程上重要的信息认证编号共享与代码复用一致。Q331318 同时对应 ESP32-C5、ESP32-C61 与 ESP32-H2 三款芯片239440 同时对应 ESP32-C3 与 ESP32-S3。这与仓库中 Controller 的交付结构相互印证在 components/bt/CMakeLists.txt 中CONFIG_IDF_TARGET_ESP32S3的 Controller 源码名被映射为esp32c3CONFIG_IDF_TARGET_ESP32C61映射为esp32c6CONFIG_IDF_TARGET_ESP32H21映射为esp32h2components/bt/controller/下也不存在独立的lib_esp32s3或lib_esp32c61目录而是复用lib_esp32c3_family/、lib_esp32c6/等库。从源码结构看S3 与 C3、C61 与 C6 共用同一份通过认证的低层协议实现因此共享同一个合格设计编号是合理的。同一芯片可能存在多个认证编号。ESP32 的 LE 模式认证到 5.0141661而双模经典蓝牙 BLE认证到 4.2147845。如果你的产品使用 ESP32 的 BR/EDR 经典蓝牙功能引用的是 147845 这条双模认证记录若只用 LE则引用 141661。较新的 RISC-V 芯片已覆盖到 Core Specification 6.0C5/C6/C61/H2ESP32-C3 与 ESP32-S3 认证到 5.4ESP32-C2 为 5.3。选型时若产品规格书要求BLE 5.x/6.x 认证应以本表版本为准而不是以芯片营销材料中的口号版本为准。三、Host 认证状态表原文档核心内容下表完整继承自原文档列出 Espressif 蓝牙 LE Host 的最新认证情况HostDesign Number / Qualified Design ID通过的 Core Specification 版本ESP-Bluedroid1983125.3ESP-NimBLEQ3715976.1结合 components/bt/Kconfig 的选项描述可以给出直接的选型对应关系选择BT_BLUEDROID_ENABLEDBluedroid - Dual-mode默认项时运行的是认证编号 198312、版本 5.3 的 Host它在经典蓝牙/双模场景下是唯一选择。选择BT_NIMBLE_ENABLEDNimBLE - BLE only时运行的是认证编号 Q371597、版本 6.1 的 Host仅做 BLE 且希望节省内存时推荐。此外 Kconfig 还提供BT_CONTROLLER_ONLYDisabled选项见 components/bt/Kconfig适用于绕过 ESP 提供的 Host、直接对接 Controller 或使用其他非 Espressif Host 栈的场景此时产品的 Host 认证需要由所选第三方 Host 自行提供不能再引用上表中的 ESP-Bluedroid/ESP-NimBLE 编号。四、两个必须理解的脚注编号体系变更与认证版本 ≠ 全特性支持原文档对两张表附了两条脚注其重要性不亚于表格本身此处完整保留并展开。4.1 2024 年 7 月起新合格设计使用 Design NumberDN而非 QDID自2024 年 7 月 1 日起蓝牙 SIG 对新合格设计的标识编号由 Qualified Design IDQDID形如Q371597改为Design NumberDN形如纯数字。这解释了上表中编号格式的差异ESP32-C5、C61、H2、NimBLE Host 的Q331318、Q335877、Q371597属于旧编号体系下仍被沿用/登记的合格设计而 141661、147845、194009、239440、198312 等数字编号则是新体系下的 Design Number。原文档同时提示设计详情、TCRL 版本、ICS 详情通过的测试用例等信息需要登录 Bluetooth SIG 网站查询对应合格产品的详细信息。因此在实际提交认证文档如 ICS、TCRL 清单时建议以 SIG 数据库中的实时记录为准仓库文档中的编号是截至当前仓库快照的最新状态。4.2 通过某个版本认证不代表支持该版本的全部特性蓝牙 Core Specification 中的许多特性是可选的optional。原文档明确指出通过某一特定规格版本的认证并不意味着支持该版本规范中定义的全部特性。各芯片上实际支持的 BLE 特性请参考Major Feature Support Status文档。对应的仓库文档是 Major Feature Support Status其中逐特性列出 ESP Controller、ESP-Bluedroid Host、ESP-NimBLE Host 三列的支持状态Supported / Experimental / Developing / Unsupported / NA例如LE Isochronous ChannelsBIS/CIS5.2当前对 Controller 与两套 Host 均标记为 UnsupportedChannel Sounding6.0三列均 Unsupported——也就是说即使 ESP32-C5/C6/C61/H2 的 Controller 已通过 6.0 认证也不能直接宣称支持 6.0 全部特性AoA/AoD5.1仅在 ESP32-H2/H21、C5、C61 上为 ExperimentalGATT Caching、Enhanced Attribute Protocol、Encrypted Advertising Data等标记为 NA 或 Host 侧特性的条目则只与 Host 实现相关与 Controller 认证无关。该文档还特别说明若 Controller 与 Host 运行在不同的 Espressif 芯片上Host 的功能不受 Host 所在芯片的 Controller 支持状态限制可参考 Host Feature Support Status。同时原文档声明特性支持状态信息仅供参考、不构成约束性承诺且可能随时变化关键特性建议与 Espressif 客户支持团队确认。五、结合仓库源码核对认证对象的交付形态为了把上文的认证编号落到可验证的工程实体上本节给出components/bt中与认证直接相关的代码与构建证据。5.1 Controller 以预编译库交付认证即针对这些库components/bt/controller/CMakeLists.txt 通过register_bt_ctrl_libs()在顶层 components/bt/CMakeLists.txt 中注册各芯片的预编译库lib_esp32c3_family/、lib_esp32c5/、lib_esp32c6/、lib_esp32h2/等目录下的二进制。这意味着 ESP-IDF 用户日常编译的 Controller 代码与提交给 SIG 测试的 Controller 实现是同一份库文件——认证编号可以直接关联到工程中的二进制依赖而不是源码自行编译出的实现。5.2 Host 选择项与认证表中两个 Host 一一对应components/bt/Kconfig 中的BT_HOSTchoice 定义了三种形态与认证表及前文分析严格对应choice BT_HOST prompt Host depends on BT_ENABLED default BT_BLUEDROID_ENABLED config BT_BLUEDROID_ENABLED bool Bluedroid - Dual-mode # 对应认证表 ESP-Bluedroid1983125.3 config BT_NIMBLE_ENABLED bool NimBLE - BLE only # 对应认证表 ESP-NimBLEQ3715976.1 config BT_CONTROLLER_ONLY bool Disabled # 仅使用 Controller搭配第三方 Host此外BT_CONTROLLERchoice 提供BT_CONTROLLER_DISABLED选项Kconfig用于纯 Host 场景——即运行在另一片支持蓝牙的芯片的 Controller 之上此时本产品引用的是 Host 的认证编号198312 或 Q371597而非本文第二部分表中任何 Controller 编号。5.3 认证与芯片支持之间的差异示例docs/en/api-guides/ble/overview.rst 中按目标芯片给出认证版本描述如ESP32-S3 supports Bluetooth 5.0 (LE) and is certified for Bluetooth LE 5.4与本文 Controller 表中 ESP32-S3 → 5.4 的记录一致。而 components/bt/CMakeLists.txt 中if(${target} STREQUAL linux) return()表明 Linux 模拟器目标不支持蓝牙组件——这也提醒认证信息只适用于真实硬件目标。六、产品化前的核对清单基于上述事实的工程化建议以下清单完全由本文与仓库证据支撑可作为产品认证评审时的检查项确认芯片的 Controller 认证版本对照第二部分的表确定所用芯片对应的 Design Number 与 Core Specification 版本ESP32 需区分 LE 模式5.0/141661与双模4.2/147845两条记录。确认所选 Host 的认证记录在 sdkconfig 中检查CONFIG_BT_BLUEDROID_ENABLED与CONFIG_BT_NIMBLE_ENABLED的设置由 components/bt/Kconfig 生成引用 5.3/198312Bluedroid或 6.1/Q371597NimBLE。用特性支持表约束功能宣传逐条对照 Major Feature Support Status确认产品宣称的每个 BLE 特性如 2M PHY、Coded PHY、Periodic Advertising with Responses、LE Power Control 等在你所用芯片上的状态为 Supported处于 Experimental/Developing 的特性不应作为产品承诺。核对编号体系新登记/新查询时注意 Design Number 与 QDID 的区分2024-07-01 分界并在 SIG 数据库中核对 TCRL 版本与 ICS 通过用例详情。模组用户另行查询本文表格针对的是 SoC 级 Controller/Host 认证模组级认证需查询 SIG Qualification Workspace 中的模组记录。七、小结docs/en/api-guides/ble/ble-qualification.rst虽然篇幅不长但它定义了 ESP-IDF 蓝牙功能在合规层面的事实基线ESP32/C2/C3/S3/C5/C6/C61/H2 各芯片 Controller 的认证版本从 4.2 到 6.0 不等ESP-Bluedroid 认证至 5.3、ESP-NimBLE 认证至 6.1编号体系自 2024 年 7 月起由 QDID 过渡为 Design Number且认证版本与特性实际支持必须分开表述。结合components/bt的源码结构Controller 预编译库 两套 Host Kconfig 选项上述认证编号可以逐一对应到工程中的具体交付物从而在选型、认证评审与文档撰写中做到可追溯、可验证。【免费下载链接】esp-idfEspressif IoT Development Framework. Official development framework for Espressif SoCs.项目地址: https://gitcode.com/GitHub_Trending/es/esp-idf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ESP-IDF 中蓝牙 SIG 认证状态详解：各芯片 BLE Controller 与 Host 的合格设计编号与核心规格版本
ESP-IDF 中蓝牙 SIG 认证状态详解各芯片 BLE Controller 与 Host 的合格设计编号与核心规格版本【免费下载链接】esp-idfEspressif IoT Development Framework. Official development framework for Espressif SoCs.项目地址: https://gitcode.com/GitHub_Trending/es/esp-idf本文以 ESP-IDF 官方文档docs/en/api-guides/ble/ble-qualification.rst为主体完整呈现 Espressif 蓝牙低功耗BLE协议栈在蓝牙 SIG 认证体系下的最新认证状态包括各芯片ESP32、ESP32-S3、ESP32-C2/C3/C5/C6/C61、ESP32-H2 等的 Controller 合格设计编号Design Number / QDID与通过的 Core Specification 版本以及 ESP-Bluedroid 与 ESP-NimBLE 两大 Host 的认证版本。读完本文你能够在产品认证与选型阶段快速核对某个芯片Host 组合对应的 SIG 认证编号理解 2024 年 7 月起 QDID 向 Design Number 的编号体系变更并弄清楚通过某版本认证与支持该版本全部特性之间的关键区别同时结合 ESP-IDF 仓库中components/bt组件的源码结构验证认证对象与实际代码交付形态预编译 Controller 库、两套 Host 实现的对应关系。一、为什么需要单独看待Controller 认证与Host 认证蓝牙 SIG 认证在技术架构上区分两个层次Controller控制器负责 PHY、基带、链路层、HCI 等硬件侧协议和Host主机协议栈负责 L2CAP、GATT/ATT、SMP、GAP 及各类 profile。一个完整的 BLE 产品认证需要 Controller 与 Host 各自通过认证再以产品形式在 SIG 数据库中登记。ESP-IDF 的 BLE 协议栈正是按这一分层组织的这一点在官方架构文档 BLE Overview 中有明确描述最底层是 ESP Bluetooth ControllerPHY、Baseband、Link Controller、Link Manager、Device Manager、HCI其上是两个可选择的 Host ——ESP-Bluedroid由 Android Bluedroid 栈修改而来双模芯片上同时支持经典蓝牙与ESP-NimBLE基于 Apache Mynewt 的 NimBLE Host 移植仅支持 BLE、占用更少的堆和 Flash。在 ESP-IDF 仓库中这些认证对象对应如下代码结构Controller位于 components/bt/controller/按芯片目录组织esp32/、esp32c2/、esp32c3/、esp32c5/、esp32c6/、esp32h2/等并以预编译库形式交付如lib_esp32/、lib_esp32c3_family/、lib_esp32c5/、lib_esp32c6/、lib_esp32h2/、lib_esp32s31/等。SIG 认证的正是这些 Controller 库。Host位于 components/bt/host/bluedroid/ 与 components/bt/host/nimble/即认证表中的 ESP-Bluedroid 与 ESP-NimBLE。顶层构建入口components/bt/CMakeLists.txt 分别加载 Controller 子目录与两套 Host 子目录components/bt/Kconfig 通过BT_HOST选项让用户在Bluedroid - Dual-mode与NimBLE - BLE only之间选择这正是认证表中两个 Host 的落地开关。注意模块module级别的认证不在此表范围内。若你使用的是 Espressif 成品模组如 ESP32-S3-WROOM 等模组上的认证需要另行在 Bluetooth SIG 官方的 SIG Qualification Workspace 中查询模组的认证记录。二、Controller 认证状态总表原文档核心内容下表完整继承自 ble-qualification.rst列出各芯片上 Espressif 蓝牙 LE Controller 的最新认证情况芯片认证对象模式Design Number / Qualified Design ID通过的 Core Specification 版本ESP32Bluetooth LE Mode1416615.0ESP32Dual Mode经典蓝牙 BLE1478454.2ESP32-C2ESP8684—1940095.3ESP32-C3—2394405.4ESP32-C5—Q3313186.0ESP32-C6—Q3358776.0ESP32-C61—Q3313186.0ESP32-S3—2394405.4ESP32-H2—Q3313186.0从这张表可以读出几个工程上重要的信息认证编号共享与代码复用一致。Q331318 同时对应 ESP32-C5、ESP32-C61 与 ESP32-H2 三款芯片239440 同时对应 ESP32-C3 与 ESP32-S3。这与仓库中 Controller 的交付结构相互印证在 components/bt/CMakeLists.txt 中CONFIG_IDF_TARGET_ESP32S3的 Controller 源码名被映射为esp32c3CONFIG_IDF_TARGET_ESP32C61映射为esp32c6CONFIG_IDF_TARGET_ESP32H21映射为esp32h2components/bt/controller/下也不存在独立的lib_esp32s3或lib_esp32c61目录而是复用lib_esp32c3_family/、lib_esp32c6/等库。从源码结构看S3 与 C3、C61 与 C6 共用同一份通过认证的低层协议实现因此共享同一个合格设计编号是合理的。同一芯片可能存在多个认证编号。ESP32 的 LE 模式认证到 5.0141661而双模经典蓝牙 BLE认证到 4.2147845。如果你的产品使用 ESP32 的 BR/EDR 经典蓝牙功能引用的是 147845 这条双模认证记录若只用 LE则引用 141661。较新的 RISC-V 芯片已覆盖到 Core Specification 6.0C5/C6/C61/H2ESP32-C3 与 ESP32-S3 认证到 5.4ESP32-C2 为 5.3。选型时若产品规格书要求BLE 5.x/6.x 认证应以本表版本为准而不是以芯片营销材料中的口号版本为准。三、Host 认证状态表原文档核心内容下表完整继承自原文档列出 Espressif 蓝牙 LE Host 的最新认证情况HostDesign Number / Qualified Design ID通过的 Core Specification 版本ESP-Bluedroid1983125.3ESP-NimBLEQ3715976.1结合 components/bt/Kconfig 的选项描述可以给出直接的选型对应关系选择BT_BLUEDROID_ENABLEDBluedroid - Dual-mode默认项时运行的是认证编号 198312、版本 5.3 的 Host它在经典蓝牙/双模场景下是唯一选择。选择BT_NIMBLE_ENABLEDNimBLE - BLE only时运行的是认证编号 Q371597、版本 6.1 的 Host仅做 BLE 且希望节省内存时推荐。此外 Kconfig 还提供BT_CONTROLLER_ONLYDisabled选项见 components/bt/Kconfig适用于绕过 ESP 提供的 Host、直接对接 Controller 或使用其他非 Espressif Host 栈的场景此时产品的 Host 认证需要由所选第三方 Host 自行提供不能再引用上表中的 ESP-Bluedroid/ESP-NimBLE 编号。四、两个必须理解的脚注编号体系变更与认证版本 ≠ 全特性支持原文档对两张表附了两条脚注其重要性不亚于表格本身此处完整保留并展开。4.1 2024 年 7 月起新合格设计使用 Design NumberDN而非 QDID自2024 年 7 月 1 日起蓝牙 SIG 对新合格设计的标识编号由 Qualified Design IDQDID形如Q371597改为Design NumberDN形如纯数字。这解释了上表中编号格式的差异ESP32-C5、C61、H2、NimBLE Host 的Q331318、Q335877、Q371597属于旧编号体系下仍被沿用/登记的合格设计而 141661、147845、194009、239440、198312 等数字编号则是新体系下的 Design Number。原文档同时提示设计详情、TCRL 版本、ICS 详情通过的测试用例等信息需要登录 Bluetooth SIG 网站查询对应合格产品的详细信息。因此在实际提交认证文档如 ICS、TCRL 清单时建议以 SIG 数据库中的实时记录为准仓库文档中的编号是截至当前仓库快照的最新状态。4.2 通过某个版本认证不代表支持该版本的全部特性蓝牙 Core Specification 中的许多特性是可选的optional。原文档明确指出通过某一特定规格版本的认证并不意味着支持该版本规范中定义的全部特性。各芯片上实际支持的 BLE 特性请参考Major Feature Support Status文档。对应的仓库文档是 Major Feature Support Status其中逐特性列出 ESP Controller、ESP-Bluedroid Host、ESP-NimBLE Host 三列的支持状态Supported / Experimental / Developing / Unsupported / NA例如LE Isochronous ChannelsBIS/CIS5.2当前对 Controller 与两套 Host 均标记为 UnsupportedChannel Sounding6.0三列均 Unsupported——也就是说即使 ESP32-C5/C6/C61/H2 的 Controller 已通过 6.0 认证也不能直接宣称支持 6.0 全部特性AoA/AoD5.1仅在 ESP32-H2/H21、C5、C61 上为 ExperimentalGATT Caching、Enhanced Attribute Protocol、Encrypted Advertising Data等标记为 NA 或 Host 侧特性的条目则只与 Host 实现相关与 Controller 认证无关。该文档还特别说明若 Controller 与 Host 运行在不同的 Espressif 芯片上Host 的功能不受 Host 所在芯片的 Controller 支持状态限制可参考 Host Feature Support Status。同时原文档声明特性支持状态信息仅供参考、不构成约束性承诺且可能随时变化关键特性建议与 Espressif 客户支持团队确认。五、结合仓库源码核对认证对象的交付形态为了把上文的认证编号落到可验证的工程实体上本节给出components/bt中与认证直接相关的代码与构建证据。5.1 Controller 以预编译库交付认证即针对这些库components/bt/controller/CMakeLists.txt 通过register_bt_ctrl_libs()在顶层 components/bt/CMakeLists.txt 中注册各芯片的预编译库lib_esp32c3_family/、lib_esp32c5/、lib_esp32c6/、lib_esp32h2/等目录下的二进制。这意味着 ESP-IDF 用户日常编译的 Controller 代码与提交给 SIG 测试的 Controller 实现是同一份库文件——认证编号可以直接关联到工程中的二进制依赖而不是源码自行编译出的实现。5.2 Host 选择项与认证表中两个 Host 一一对应components/bt/Kconfig 中的BT_HOSTchoice 定义了三种形态与认证表及前文分析严格对应choice BT_HOST prompt Host depends on BT_ENABLED default BT_BLUEDROID_ENABLED config BT_BLUEDROID_ENABLED bool Bluedroid - Dual-mode # 对应认证表 ESP-Bluedroid1983125.3 config BT_NIMBLE_ENABLED bool NimBLE - BLE only # 对应认证表 ESP-NimBLEQ3715976.1 config BT_CONTROLLER_ONLY bool Disabled # 仅使用 Controller搭配第三方 Host此外BT_CONTROLLERchoice 提供BT_CONTROLLER_DISABLED选项Kconfig用于纯 Host 场景——即运行在另一片支持蓝牙的芯片的 Controller 之上此时本产品引用的是 Host 的认证编号198312 或 Q371597而非本文第二部分表中任何 Controller 编号。5.3 认证与芯片支持之间的差异示例docs/en/api-guides/ble/overview.rst 中按目标芯片给出认证版本描述如ESP32-S3 supports Bluetooth 5.0 (LE) and is certified for Bluetooth LE 5.4与本文 Controller 表中 ESP32-S3 → 5.4 的记录一致。而 components/bt/CMakeLists.txt 中if(${target} STREQUAL linux) return()表明 Linux 模拟器目标不支持蓝牙组件——这也提醒认证信息只适用于真实硬件目标。六、产品化前的核对清单基于上述事实的工程化建议以下清单完全由本文与仓库证据支撑可作为产品认证评审时的检查项确认芯片的 Controller 认证版本对照第二部分的表确定所用芯片对应的 Design Number 与 Core Specification 版本ESP32 需区分 LE 模式5.0/141661与双模4.2/147845两条记录。确认所选 Host 的认证记录在 sdkconfig 中检查CONFIG_BT_BLUEDROID_ENABLED与CONFIG_BT_NIMBLE_ENABLED的设置由 components/bt/Kconfig 生成引用 5.3/198312Bluedroid或 6.1/Q371597NimBLE。用特性支持表约束功能宣传逐条对照 Major Feature Support Status确认产品宣称的每个 BLE 特性如 2M PHY、Coded PHY、Periodic Advertising with Responses、LE Power Control 等在你所用芯片上的状态为 Supported处于 Experimental/Developing 的特性不应作为产品承诺。核对编号体系新登记/新查询时注意 Design Number 与 QDID 的区分2024-07-01 分界并在 SIG 数据库中核对 TCRL 版本与 ICS 通过用例详情。模组用户另行查询本文表格针对的是 SoC 级 Controller/Host 认证模组级认证需查询 SIG Qualification Workspace 中的模组记录。七、小结docs/en/api-guides/ble/ble-qualification.rst虽然篇幅不长但它定义了 ESP-IDF 蓝牙功能在合规层面的事实基线ESP32/C2/C3/S3/C5/C6/C61/H2 各芯片 Controller 的认证版本从 4.2 到 6.0 不等ESP-Bluedroid 认证至 5.3、ESP-NimBLE 认证至 6.1编号体系自 2024 年 7 月起由 QDID 过渡为 Design Number且认证版本与特性实际支持必须分开表述。结合components/bt的源码结构Controller 预编译库 两套 Host Kconfig 选项上述认证编号可以逐一对应到工程中的具体交付物从而在选型、认证评审与文档撰写中做到可追溯、可验证。【免费下载链接】esp-idfEspressif IoT Development Framework. Official development framework for Espressif SoCs.项目地址: https://gitcode.com/GitHub_Trending/es/esp-idf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考