1. 为什么选 CH592 做蓝牙 MCU 集成
1.1 芯片定位与核心指标
CH592 是南京沁恒（WCH）推出的低功耗蓝牙无线 MCU。和 STM32WB、nRF52832 这些传统方案比，它最大的特点是基于 RISC-V 内核，BLE 协议栈、Flash、各类外设都集成在单颗芯片里，外部几乎不需要额外器件。很多人第一次拿到这颗料，会觉得它就是“带蓝牙的国产单片机”，但实际上它的低功耗策略、BLE 协议栈封装方式和硬件集成度，决定了它特别适合做小体积、电池供电、需要稳定连接的场景，比如键鼠、手环、体脂秤、智能门锁和各类传感器节点。
具体到关键资源，CH592 内部集成了 BLE 5.x 协议栈（具体版本以官网最新数据手册为准），Flash 容量做到了几百 KB 的量级，RAM 也有几十 KB，这个配置在国产蓝牙 SoC 里算中上水平。对于纯传感器上报类的应用，你甚至不需要外挂 Flash。芯片内部还集成了一系列模拟外设和数字接口：ADC、UART、SPI、I2C、PWM、GPIO 中断等，单芯片就能覆盖一个完整产品的主控加通信需求。
我为什么一直强调先看“单模 BLE”这个属性？因为 BLE 和经典蓝牙是两套完全不同的协议。很多从 HC05 这类经典蓝牙模块转过来的工程师，第一反应是“直接发数据就行”，结果发现手机端要 GATT 连接、要特征值读写，完全不是原来那套串口透传逻辑。CH592 解决的是 BLE 生态的问题，不是替代 HC05 这种经典蓝牙模块。这一点先想清楚，后面做方案能少走很多弯路。
1.2 和其他蓝牙方案的取舍
做项目选型时，我习惯把候选方案分成三档：
| 方案 | 内核 | 协议栈 | 典型成本 | 适合场景 |
|---|---|---|---|---|
| CH592 这类国产 RISC-V BLE SoC | RISC-V | BLE 5.x，SDK 配套完善 | 较低 | 大批量、低成本、功能明确的产品 |
| Nordic nRF52 系列 | ARM Cortex-M4 | 生态成熟、文档齐全 | 偏高 | 高端可穿戴、复杂应用、需大量第三方库 |
| ESP32-C3 / S3 等 WiFi+BLE | RISC-V / Xtensa | WiFi 场景主导 | 中等 | 需要 WiFi、语音、复杂本地处理 |
选 CH592 的核心理由通常不是性能天花板，而是“够用又便宜”。大部分 BLE 外设应用，数据量很小，连接间隔可以拉得很大，CPU 大部分时间在睡觉。这种负载下，高主频和强大算力根本用不上，省下的是几块钱 BOM 成本和一颗电池的寿命。
另一个理由是沁恒的工具链和例程都面向国内工程师，遇到问题看中文文档、进技术支持群，比翻几百页英文手册快得多。不过，RISC-V 生态和 ARM 比确实还有差距，某些现成的协议栈中间件、实时操作系统移植需要自己花时间。真正落地前，建议先买官方 EVT 板验证一遍你需要的所有功能，不要只看手册。
2. 硬件集成方案与最小系统设计
2.1 最小系统构成
一颗 CH592 要跑起来，外围器件并不复杂：
- 电源：宽压输入，通常是 3.3V 或者锂电池直供，建议按数据手册要求在电源引脚放 100nF 和 1uF 去耦电容。
- 晶振：BLE 射频工作需要精确的 32MHz 系统晶振（具体频点以参考设计为准），再加上 32.768kHz RTC 晶振用于低功耗计时和唤醒对齐。晶振不能省，否则蓝牙跑不稳、休眠唤醒会乱套。
- 复位电路：一般加个 10k 上拉到 VDD，预留外部按键或测试点即可。
- 天线匹配网络：根据选用天线类型，预留 π 型匹配位置。
- 烧录接口：SWD 或官方烧录器接口，预留 VCC、GND、SWCLK、SWDIO 四根线足够。
很多工程师第一次画板会忽略晶振周围走线的讲究。射频部分，晶振和匹配网络尽量靠近芯片引脚，走线要短而直，底层地平面要连续，晶振下方不要走其他信号线。这个板子做出来能不能过射频性能测试，七成以上取决于这里的布局，而不是你软件里调了多少参数。
2.2 天线类型与射频匹配
天线这块，物联网项目常用三种：
- PCB 板载天线（倒 F、蛇形），成本最低，但对结构净空区要求高。
- 陶瓷贴片天线，体积小、一致性好，适合手环、耳机这类小设备。
- 外置 SMA 天线，信号最好，多用于网关、测试验证。
不管用哪一种，板上都必须预留串联电感和并联电容组成的 π 型匹配网络。我自己的习惯是先焊成默认值（比如串联 0Ω 加一个很小的并联电容），然后用网络分析仪实测 S11，再调整匹配到 2.4GHz 频段，回波损耗尽量在 -10dB 以下。如果没有网分，可以借信号源和频谱仪测试板端灵敏度，或者直接抄官方参考设计的匹配值，但天线形式一变，参考值就仅供参考。
这里有个容易踩的坑：天线正下方和周围不要铺铜，不要放按键、排针、螺丝孔。很多量产产品出现“手一摸蓝牙就断”的怪问题，多半是天线净空被结构件或者金属外壳压缩了。做结构评审时，射频工程师一定要在场，给天线区域留足空间。
2.3 电源设计要领
CH592 这类低功耗 MCU，对电源电压要求不高，但对电流瞬态响应有点要求。BLE 发射时电流会呈现几毫安到十几毫安的脉冲，如果前端 DC-DC 动态响应差，会造成电压跌落，轻则发射功率下降，重则复位重启。
给出两个我验证过的供电方案：
- 电池直接供电：如果电池电压落在芯片工作范围内，加一颗低功耗 LDO 稳压到 3.3V，LDO 后级再放 2.2uF 陶瓷电容改善动态响应。这个方案待机功耗极低，适合 CR2032 这种微电流电池。
- 锂电池加 DC-DC：先转换到稳定电压再进 MCU。这里要特别注意 DC-DC 的静态电流，很多看似高效的芯片静态功耗有 1mA 以上，会把整个系统的睡眠功耗拉爆。选 DC-DC 要看“休眠电流”或“关断电流”指标，最好小于 5μA。
还有一个细节：不要用大阻值分压电阻直接测电池电压。做电池电量检测时，分压电阻日常就在漏电，会白白增加功耗。正确做法是用 MOS 管做开关，只在测量时刻导通，平时分压网络完全断开。这个习惯能省 2~3μA，对纽扣电池设备来说可能就是几个月的续航差距。
3. 低功耗设计要点详解
3.1 睡眠模型与唤醒源
低功耗设计的第一步不是调参数，而是理解芯片有哪几种工作状态。以 CH592 为参考，芯片通常有正常运行、睡眠（Sleep）、深度睡眠（Deep Sleep）等模式。不同模式下，CPU、外设、RAM 的供电情况不一样，功耗差距可以从几百 μA 降到几 μA，甚至更低。
我习惯把低功耗设计拆成三层：
- 芯片内部：选对睡眠模式，保留需要的 RAM 区域，关闭不需要的外设时钟。
- 外设层面：传感器、运放、指示灯、通信模块都要能“断电”或者“失能”，不能光靠 MCU 睡觉。
- 时间层面：尽量让所有工作集中在一个很短的时间窗口完成，然后立刻进入下一个长睡眠周期。平均电流才是电池续航的决定因素，不是峰值电流。
对应到实际项目里，唤醒源通常有 GPIO 中断、RTC 定时器、BLE 射频唤醒等。你可以在低功耗模式下让协议栈继续跑广播或连接事件，也可以完全睡觉，等外部事件再拉起系统。比如做无线门磁，常态睡眠，门打开时霍尔传感器触发 GPIO，系统上报一次状态后马上又睡；而做蓝牙键盘，芯片需要保持 BLE 连接，就得让定时唤醒或者射频事件参与调度，几百毫秒醒来一次维持连接，其余时间保持深度睡眠。
3.2 BLE 协议参数对功耗的影响
低功耗设计一半在硬件，一半在协议参数。BLE 的功耗模型是事件驱动的，平均功耗近似等于：
平均电流 ≈ 单次事件能耗 × 事件频率 + 睡眠电流
能优化的就三个变量：单次事件能耗、事件频率、睡眠电流。
- 事件能耗：广播、扫描、连接事件时的射频收发电流和时长，可调项包括发射功率、数据包长度、重传次数。
- 事件频率：广播间隔、连接间隔、从机延迟（slave latency）。间隔越大越省电，但交互延迟越明显。
- 睡眠电流：取决于芯片模式和外围电路的漏电，前面已经提过。
举个例子。做一个低功耗温度计，每秒上报一次，广播间隔 100ms 时平均功耗可能到几百 μA，这个量级不适合电池长期工作。把广播间隔改成 1s，发射功率降到 0dBm，温度传感器只在采集时刻上电，平均功耗就能压到几十 μA。如果改成每 10 秒上报一次，用 CR2032 撑一年问题不大。
所以需求评估阶段就要问自己：这个产品允许多大的通信延迟？是按键立刻响应，还是数据几分钟上报一次都可以？这决定了后面能不能把连接间隔拉大、把从机延迟开高，也就直接决定了电池容量选型。
3.3 外围 IO 的功耗陷阱
这部分是最容易被忽略，也是我调试功耗时花时间最多的地方。以下问题我在不同项目里都踩过：
- 悬空输入脚会通过内部上拉或下拉产生额外电流。未使用引脚必须配置成模拟输入或者输出低电平，并关闭内部上下拉。
- LED 限流电阻算错，一颗 LED 常亮就是 1~2mA，比整个芯片休眠电流大两三个数量级。指示灯一定要由软件控制，平时关断。
- 传感器上电后忘了关。很多 MEMS 传感器正常测量电流几百 μA，但 sleep 模式电流可能只有 1μA，需要在待机流程里显式调用传感器的 sleep 函数。
- 外部 Flash、LCD 驱动芯片只要还在供电，静态电流一直在流。合理做法是加负载开关，或者在硬件上选本身就带休眠功能的器件。
- 芯片进入深度睡眠后，如果低速晶振继续振荡，电流会多几十 μA。要按手册配置时钟树，确认振荡器在睡眠阶段确实被关断。
排查技巧很简单：用电流表串联供电，逐项拔掉外设或者关掉外设电源，看电流在哪一步下降，基本就能锁定问题。如果板子上有跳线，优先隔离外设电源做对照实验。
3.4 功耗测量方法
低功耗测量不是拿个万用表一夹就行的。BLE 芯片电流是脉冲式的，普通万用表响应速度不够，测出来的平均电流偏大，而且根本看不出问题。我的工作台配置是这样：
- 睡眠电流：用带微安量程的高精度万用表，或者数据采集卡记录。
- 动态电流曲线：用示波器加电流探头，也可以用“电阻采样法”。在供电回路里串联一个 10Ω 精密电阻，探头测电阻两端电压，用欧姆定律换算成电流。采样电阻不能太大，否则压降会影响芯片供电，10Ω 以下比较安全。
- 长时间续航估算：用低功耗电流记录仪跑 24 小时，统计峰值、平均、最小三个值。没有专业设备时，可以用大电容积分法：给电容充好电，断开电源，记录电压下降曲线，再换算总耗电量。
分享一个实际案例。有台设备标称深度睡眠 2μA，实测却有 80μA。用示波器一看，发现芯片每隔 20ms 就被 RTC 唤醒一次，每次醒来做了一堆初始化操作又睡下，这 20ms 的转身时间把平均功耗拉高了非常多。后来把不必要的唤醒源全部关闭，只留按键中断，平均电流从 80μA 降到了 3μA。这类问题不抓波形根本看不出来。
4. BLE 协议栈与应用落地
4.1 广播、扫描与连接
BLE 应用的核心是 GATT 模型：一个设备做 Server，暴露服务（Service）和特征值（Characteristic），另一个设备做 Client，读写这些特征值。CH592 的 SDK 里会提供完整的协议栈封装，广播包内容、连接参数、服务表都能配置。
上手时建议先跑一个最简透传例程：上电广播，手机用 nRF Connect 这类调试 App 扫到设备，连接，找到 RX/TX 特征值，写数据，灯亮或者串口打印。把这条链路跑通，整个 BLE 开发的骨架就搭起来了。后面不管是传感器上传、遥控器，还是 OTA 升级，都是在 GATT 上增加服务而已。
广播和扫描是最容易出问题的地方。广播间隔越小，发现越快，但功耗越高。做可发现设备时，我会用快速广播（30~50ms）持续几秒，让手机能顺利连上，连接建立后就切换成低速广播或者直接停止广播，避免无谓耗电。
4.2 蓝牙 HID 与键鼠应用
如果你做蓝牙键盘、鼠标、遥控器，走的通常是 HID over GATT 这套规范。HID 设备和透传设备最大的区别是，它要在 GATT 上建立 HID 服务，包含报告地图、报告数据、HID 控制点等特征值，主机端（电脑、手机）才能把它识别成键盘或鼠标。这比普通透传要复杂一点，但 CH592 SDK 一般会带 HID 键盘/鼠标例程，可以基于例程改键值表。
研发中容易被细节卡住的地方：
- 报告描述符（Report Descriptor）里按键的用法页、最小最大值、报告大小要定义正确，否则按键会乱码或者无法被识别。
- HID 设备要支持休眠唤醒，否则长时间不用就会断连，按一下才能恢复。
- 配对绑定：键盘类产品通常需要“一键配对”，按芯片和系统的配对交互流程实现，并注意不同系统的弹窗差异。
- 主机兼容性：Windows、macOS、Android 对 HID 的兼容性存在差异，拿多台机器做回归测试是必须的。
4.3 Mesh 与多节点组网
Mesh 功能是用在多盏灯、多传感器这种“一对多”场景的。BLE Mesh 不是靠经典蓝牙的“一主多从”，而是通过管理型泛洪、代理节点、朋友节点等机制，让每个节点都能转发消息，从而形成全网络通信。CH592 是否支持完整的 Mesh profile，取决于官方协议栈版本，开发前先到资料中心确认。
如果只是简单多节点控制，可以先用经典的“一对多连接”解决：一个中心设备连接多个从机，每个从机有自己的服务，中心对它们逐个读写。这种方式实现简单，但中心设备任务重、连接数受限。如果节点数量超过二十个，或者需要任意两点通信，Mesh 的价值就体现出来了。
组网的时候还要考虑配置参数：TTL 值、消息重传次数、密钥更新策略等。Mesh 调试比单连接复杂，建议先用 3 个节点验证流程，再逐步扩到几十个节点，不然定位丢包就要花很长时间。
4.4 OTA 升级
物联网产品免不了要远程更新固件。BLE OTA 的常见做法是在 GATT 服务里增加一个 OTA 服务，用特征值分片传输固件，然后写入内部 Flash。CH592 内部 Flash 容量比较大，可以做双 Bank 设计，就是把固件放在两个区域，先写 Bank2，校验成功后切换启动标志；也可以做单 Bank 升级，由 Bootloader 接收固件写入并跳转到 App。双 Bank 的好处是升级失败还能回滚，缺点是占用 Flash 翻倍。
OTA 的坑主要在断点续传和失败恢复。如果传输一半断连，主机从头再传一次，用户体验就很差。我一般在协议里做“分包加序号加校验”，从机收到完整固件包后再做整体校验，校验失败不切换。另外，升级过程中不能断电，硬件上可以加超级电容或者低电压提示，防止写坏 Flash。
5. 开发工具与调试流程
5.1 工具链与 SDK
CH592 的开发环境和传统 STM32 不太一样。官方主推的 IDE 是 MounRiver Studio，配合 WCH-Link 烧录器使用。工程创建直接在 IDE 里选芯片型号，SDK 里的例程可以直接导入，不用像某些平台那样纠结配置文件路径。
如果你以前只写过 Arduino 或者 Keil 环境，第一次用 MRS 会稍微不习惯，但核心逻辑是一样的：配置工程、编译、烧录、调试。国内技术支持响应很快，遇到疑难问题发工单或者去官方社区，一般都能拿到解决办法。
有个建议：不要一上来就改例程，先原样编译烧录一次，确认开发环境没问题。很多工程师一拿例程就狂改，最后分辨不出是代码问题还是工具链问题，调试成本翻倍。
5.2 烧录、调试与日志
烧录接口，板子上一般引 SWD 四线（VCC、GND、SWCLK、SWDIO）或者直接用官方调试器连 EVT。量产时可以用串口烧录或者固件升级方案，减少夹具复杂度。
调试方面，BLE 应用光看断点还不够，还是要看协议交互。我会配合两种手段：
- 串口日志：在关键流程（广播、连接、断开、收到数据）打印状态，板子接 USB 转串口线看日志。缺点是要多连一根线，某些低功耗测量会被串口芯片漏电干扰。
- 手机 BLE 调试 App：nRF Connect 或 LightBlue 可以查看广播包、服务列表、读写特征值，是验证 BLE 行为最直接的工具。
如果怀疑射频参数有问题，可以用支持 BLE 的空口抓包工具抓空中报文，能直接看到广播间隔、连接参数、重传次数。很多玄学问题的答案，都藏在抓包里。
5.3 从例程到产品的改造路径
我习惯的开发节奏是：
- 跑通官方最小例程（透传）。
- 改业务服务：增加自己的 Service UUID 和特征值。
- 加入低功耗管理：初始化后进入低功耗，用事件驱动唤醒。
- 批量测试：连续通信、断线重连、长时间低功耗运行。
- 量产前做功耗标定：用功耗仪跑 48 小时，统计平均电流并推算电池寿命。
接着处理量产相关的事项：唯一的设备地址、广播名称、加密绑定、批量烧录脚本。这些如果在样品阶段就规划好，后面导入产线会顺很多。CH592 的 SDK 一般提供获取芯片唯一 ID 的接口，可以用来生成默认广播名称和地址，避免每台设备都手动改。
6. 常见问题与排查技巧实录
6.1 手机搜不到设备
这是蓝牙项目里最常见的“第一个坑”。先用排除法：
- 芯片是否正常上电并配置了广播？串口日志有没有打印广播相关状态？
- 广播参数是否正确，广播通道是否在 37/38/39 上都开启，扫描的 PHY 是否匹配？
- 天线和匹配是否有问题？看板载天线的离地距离、结构件和外壳金属的情况。
- 手机蓝牙缓存问题：在手机设置里清除蓝牙缓存再试。
如果拿别的手机能搜到，就集中查这台手机的系统设置和蓝牙权限。如果所有手机都搜不到，基本是板子射频或芯片状态的问题，优先检查晶振是否起振、射频部分是否按参考设计实现。
6.2 连接后马上断开，或者连接不稳定
这类问题优先看空中抓包。断开前最后一个报文的交互状态能告诉你很多：是手机主动断的？是从机超时？还是加密协商失败？常见原因有这几类：
- 配对不匹配：一方要求加密，另一方不支持；或者一方要求 MITM，另一方没有对应配对流程。先把配对模式统一设置成 Just Works 或 Passkey 方式打通链路。
- 连接参数冲突：中心设备要求小连接间隔，从机坚持大间隔，反复协商失败。把从机允许的连接参数范围放宽，或者直接按中心设备的参数走。
- 电源问题：射频发射瞬间电压跌落导致芯片复位，串口日志会出现异常复位记录。
- 主机兼容性：某些主板自带无线网卡在特定系统版本下的蓝牙兼容性不佳，网上常有人反馈“无线网卡蓝牙搜索不到设备”，这可能跟操作系统驱动和射频共存有关。这时可以人工调整广播间隔、发射功率或换一个适配器对比测试，判断是板子问题还是主机问题。
6.3 功耗测出来不正常
前面已经讲了测量方法，这里再给一个排查清单：
| 现象 | 常见原因 | 排查动作 |
|---|---|---|
| 睡眠电流偏高 | GPIO 悬空、内部上下拉、外设未断电 | 逐项屏蔽外设，对比电流变化 |
| 周期性脉冲电流 | RTC 或 BLE 定时事件过于频繁 | 用示波器看唤醒周期，调整事件间隔 |
| 发射时电流异常大 | 电池电压偏低、LDO 输出不稳 | 用直流电源供电，观察电压和电流关系 |
| 整体功耗和理论值差很远 | 广播间隔太小、连接事件太频繁 | 重新审视广播间隔、连接间隔、从机延迟 |
6.4 关于 HC05 连接不上这类经典蓝牙问题的提醒
很多从 HC05、JDY 系列模块转过来的工程师，遇到新设备连接不上时，第一反应是拿 HC05 的经验往 BLE 上套。这里要特别提醒：HC05 是经典蓝牙（BR/EDR）串口透传，手机要配对后打开虚拟串口才能收发；CH592 这类是 BLE，手机端通过 App 直接读写特征值，根本不存在“串口透传”这个操作。开发流程、调试工具、功耗模型完全不一样。所以遇到“连不上”，先确认你手上到底是经典蓝牙还是 BLE 设备，再用对应工具排查，不要用一套思路解决两个不同协议的问题。
7. 最后想说的几条实战经验
先说工具链。不要用 PC 蓝牙调试一切设备。PC 蓝牙在某些系统下行为复杂，很多问题其实是主机侧驱动引起的。我做过一个有问题的板子，在手机上一切正常，一接 PC 就反复连接断开，后来查出来是主机蓝牙驱动和加密算法的兼容性问题，跟板子一点关系都没有。因此，做 BLE 调试，手机调试 App、串口日志、空口抓包三件套齐了，再定位问题会高效很多。
再说低功耗。低功耗设计不只是把芯片调到睡眠模式就完事了，而是一个从硬件原理图、协议参数到外设管理的系统工程。芯片数据手册写着 2μA，实测 200μA，原因多半是 GPIO 漏电、LED 忘关、DC-DC 静态电流大。我的建议是硬件打样后第一件事，先测核心板在最小代码下的睡眠电流，确认功耗基线。基线明确之后，每加一个功能就对比一次功耗变化，每根毛刺都容易查。
最后一个建议：量产前一定留出整机级功耗和射频一致性测试的时间。样品阶段能跑通功能不算完成，产品掉电重启、断线重连、长时间待机、不同手机兼容性，这几关都过了才算能交付。CH592 的集成度已经帮我们省掉了不少 BOM，剩下的事就是把功耗、连接、稳定性这些细节一点点抠到位。芯片只是工具，好的产品都是磨出来的。
