CH585 是沁恒（WCH）推出的一款低功耗蓝牙（BLE）MCU，面向 L0 级低成本物联网设备。典型配置为 Flash 约 448KB、CPU 主频约 78MHz，无专用加密协处理器；工程上常以单蓝牙形态出现，BLE 驱动多由独立工程编译。基于该芯片的模组（如 XOH-MESH）通过适配 OpenHarmony 统一互联（iot_connect），可与生态内富设备完成发现、连接与本地控制。

本文汇总 CH585（及基于该芯片的 XOH-MESH 模组）适配 OpenHarmony 统一互联过程中的三类问题：集成后 Flash 超限、BLE 接口适配受限、连接认证耗时过长。

设备环境

案例疑难分析：集成统一互联后 Flash 超出芯片容量限制

1. 问题描述

使用环境与设备： CH585 低功耗 BLE 芯片（Flash 总容量 448KB），工程中各应用分属不同工程编译，BLE 驱动使用独立工程；目标是在 OpenHarmony mini/small 设备上集成统一互联组件 iot_connect，并具备 XTS 兼容性测试能力。

问题现象（必现）： 将 BLE 工程中的原始驱动库并入统一互联工程后，Flash 占用超出 448KB 上限，镜像无法按目标规格完整集成。

一句话概括：统一互联依赖库 + CH585 BLE 驱动合入后，Flash 装不下。

2. 分析过程

步骤一：厘清最小依赖集合

统一互联 XTS 测试所需最小库集合如下（含启动、参数、日志、HUKS、设备认证、测试框架及 iot_connect 本体）：

库名称
-lbegetutil	-ludidcomm	-lbegetutil_static	-lbootstrap
-lbroadcast	-lhal_sysparam	-lhievent_lite_static	-lhilog_lite_static
-lhilog_static	-lhiview_lite_static	-linithook	-linit_log
-linit_utils	-lnative_file	-lparameterbase	-lmbedtls
-lfsmanager_static	-lexport_headers_lib	-lhuks_3.0_sdk	-lfsmanager_static_real
-lparam_client_lite	-lsamgr	-lsamgr_adapter	-lsamgr_source
-lhal_token_static	-lhctest	-lhuks_test_common	-ldevattest_sdk
-ldevattest_core	-lcjson_static	-liotc	-lmodule_ActsIotConnectTest

统一互联纯功能最小集合为：

库名	说明
-lnative_file	原生文件操作
-lmbedtls	TLS / 加密
-lcjson_static	JSON 解析
-liotc	IoT 连接核心
-lCH58xBLE	CH585 专用 BLE 驱动

其中 -lCH58xBLE 来自厂商 BLE 工程，合入后是 Flash 增长的主要来源之一。

步骤二：对比各版本 Flash / RAM

CH585 Flash 总量 448KB。各版本占用对比：

版本	Flash 占用	RAM 占用
SDK 原始版本	基准值	基准值
单适配 OH 版本	含 XTS 测试	含 XTS 测试
统一互联功能版	453264 B（98.80%）	129792 B（99.02%）
统一互联 XTS 版	419000 B（91.33%）	117112 B（89.35%）

结论：

1. 功能版 Flash 已到 98.80%，接近极限，继续堆依赖会直接超限
2. XTS 版与功能版目标不同，不能用同一套镜像兼顾认证与量产
3. 根因是 芯片容量硬约束 + 多工程合并带来的库膨胀，不是单点配置写错

3. 解决方案

采用双版本策略，按场景裁剪依赖：

版本	用途	Flash	说明
统一互联 XTS 版	兼容性认证	419000 B（91.33%）	带 ActsIotConnectTest 等测试库
统一互联功能版	产品部署	453264 B（98.80%）	仅保留业务必需库

构建侧按版本拆分 BUILD.gn / 链接库列表，避免「认证镜像」与「出货镜像」互相拖累体积。

案例疑难分析：厂商 BLE 驱动能力不足导致统一互联接口无法完整适配

1. 问题描述

使用环境与设备： CH585 为单蓝牙（仅 BLE）设备；统一互联要求将产品侧蓝牙能力适配到 iot_connect，并通过 BLE 完成发现、广播与 GATT 交互。

问题现象： 统一互联接口模型较统一，但 CH585 厂商驱动能力不齐；目前仅广播相关少量接口及回调可正常适配，其余 BLE 基础管理、GATT、安全等接口适配困难，影响完整能力闭环。

一句话概括：不是统一互联接口设计有问题，而是 CH585 驱动侧能力覆盖不全，映射不上去。

2. 分析过程

CH585 只需适配 BLE，不涉及 Wi-Fi / Combo。需对接的接口分为五类。

BLE 基础管理接口（协议栈与本地信息）：

接口名称	功能说明
DisableBtStack	禁用蓝牙协议栈
SetLocalName	设置本地设备名称
SetDeviceName	设置设备显示名称
IsBleEnabled	检查 BLE 是否启用
GetLocalAddr	获取本地蓝牙地址
GetBtState	获取蓝牙状态
ReadBtMacAddr	读取蓝牙 MAC

GATT 服务接口（服务注册与数据交互）：

接口名称	功能说明
BleGattsStartServiceEx / BleGattsStopServiceEx	启停扩展 GATT 服务
BleGattsRegister / BleGattsUnRegister	注册 / 注销 GATT 服务
BleGattsAddService	添加 GATT 服务
BleGattsAddCharacteristic	添加特征值
BleGattsAddDescriptor	添加描述符
BleGattsStartService / BleGattsStopService / BleGattsDeleteService	启停 / 删除服务
BleGattsSendResponse / BleGattsSendIndication	响应 / 指示

广播接口（被发现的关键路径）：

接口名称	功能说明	适配状态
BleStartAdvEx	启动扩展广播	可适配
BleSetAdvData	设置广播数据	可适配
BleSetAdvParam	设置广播参数	可适配
BleStopAdv	停止广播	受驱动能力限制

安全接口：

接口名称	功能说明
BleGattsSetEncryption	设置 GATT 加密
BleSetSecurityAuthReq	设置安全认证请求
BleSetSecurityIoCap	设置安全 IO 能力
BleGattsDisconnect	断开 GATT 连接

回调接口（需全部适配）：
add_service_callback、add_characteristic_callback、add_descriptor_callback、start_service_callback、stop_service_callback、delete_service_callback、read_request_callback、write_request_callback、mtu_changed_callback、set_adv_data_callback、start_adv_callback、stop_adv_callback、conn_state_change_callback，以及 BleGattsRegisterCallbacks / BleGattRegisterCallbacks。

适配结论：当前驱动侧可稳定映射到统一互联的，主要是 BleStartAdvEx、BleSetAdvData、BleSetAdvParam 及上述回调；其余接口因厂商驱动差异难以直接对齐。

3. 解决方案

采用分层适配，而不是强行一一裸映：

1. 直接适配层：广播三件套（BleStartAdvEx / BleSetAdvData / BleSetAdvParam）+ 全部回调，直接接到 iot_connect
2. 封装适配层：基础管理、GATT、安全接口经中间层把厂商 API 转成统一互联语义，补齐驱动缺口
3. 功能裁剪：对短期无法落地、且不影响当前 XTS/业务主路径的接口，提供空实现或裁剪，避免阻塞主线联调

联调时优先保证「可被发现 + 回调齐全」，再逐步补 GATT/安全能力；构建侧仍按 Flash 裁剪双版本策略链接 -lCH58xBLE 与 -liotc，避免为凑接口把体积再次顶满。

案例疑难分析：无硬件加密加速的 L0 芯片上统一互联连接耗时超过 5 秒

1. 问题描述

使用环境与设备： XOH-MESH 模组（CH585，L0 级低成本芯片，CPU 约 78MHz，无加密协处理器）；对端为统一互联 / 通用互联 App，走 iot_connect 点对点本地控制与连接认证。

问题现象（普遍）： App 与设备建立稳定连接耗时普遍超过 5 秒，偶发连接失败，不满足「连接时长 < 5 秒」指标。

一句话概括：链路能连，但 SPEKE 密钥协商在 L0 芯片上算不动，把总耗时拖爆。

2. 分析过程

当前 iot_connect 连接认证使用基于大整数离散对数的 DL-SPEKE（社区亦在演进 SPEKE 相关方案）。方案特点：

1. 密钥长度大（约 512 bit 量级）以保证强度
2. 依赖大素数域模幂，涉及大整数生成、验证与运算
3. 有无加密协处理器，对耗时影响极大

该方案更适合有协处理器或主频较高的设备。CH585 / XOH-MESH 的硬件约束正好踩中短板：

• 无专用加密协处理器，密码学运算全靠软件
• CPU 仅约 78MHz（对比海思 3863 约 240MHz）

因此大素数生成/验证与模幂成为连接初始化最慢环节；协商无法在预期窗口完成时，表现为连接偏慢或超时失败，同时 CPU 长时间满载还会牵连其他任务与功耗。

因果链：

DL-SPEKE 计算重 → L0 无硬件加速且主频低 → 认证超时/超标 → 连接慢或失败。

3. 解决方案

• 短期： 对 XOH-MESH / CH585 类 L0 模组申请连接时长指标豁免，避免用高等级芯片指标卡死低成本硬件
• 长期： 推动采用更适合低功耗设备的轻量协商（如 EC-SPEKE，密钥约 256 bit，部分参数可预计算/缓存），降低每次连接的软件计算量

在产品侧联调时，应同时抓 App 与设备侧认证阶段耗时，确认瓶颈落在 SPEKE 而非广播发现或 GATT 建链本身；若认证阶段占比过高，再评估豁免或算法替换，而不是先调广播/扫描参数。