做低功耗蓝牙设备的人，这两年应该逐渐习惯了一个趋势：传统“MCU 主控 + 蓝牙透传模块”的两件套方案，正在被一颗自带 BLE 协议栈的 SoC 取代。CH592 就是沁恒这套思路里很有代表性的一颗 RISC-V 蓝牙 MCU——它把 2.4GHz 收发器、BLE 5.4 协议栈、USB、常用模拟外设全塞进一颗芯片，让蓝牙低功耗产品的硬件集成方案一下子变得很干净。这篇文章不讲 PPT 参数，只讲我在实际项目中集成 CH592、调整低功耗策略时踩过的坑和沉淀下来的经验，适合正在做 HID 外设、传感节点、便携标签这类产品的开发者和硬件工程师参考。
1. 选型视角：为什么 CH592 这类“一体化 BLE SoC”值得进方案池
1.1 一个 SoC 顶替“主控 + 蓝牙透传模块”三件套
以前我做一款温湿度记录仪，方案是 STM32 + 一个 BLE 模块，模块走串口透传。从功能上看没什么问题，但从集成角度看非常浪费：模块自带一颗 MCU 跑协议栈，主控这边还要留一路 UART、一组排针、一对电平转换，板子上光模块和排针就占了四分之一面积。整机待机功耗也一直压不下去，因为模块即使不进睡眠，上电后串口监听和其他后台逻辑也在耗电。
换到 CH592 之后，主控和蓝牙模块合并成了一颗芯片，模块和排针直接消掉了。广播、扫描、连接、GATT Service 全部可以在同一颗芯片里完成，多出来的 GPIO 可以拿去做按键矩阵、LED、ADC 采样、外设 EN 控制。对于功能清晰、量大的产品，这类一体化 BLE SoC 在 BOM 成本、贴片成本、单板面积和功耗控制上优势非常明显。
1.2 与常见替代方案的差异
不少同事问过我，既然要选低功耗蓝牙方案，为什么不直接上 nRF52810 或者 ESP32-C3。这里我把几个常见选项的取舍逻辑摆一下：
- nRF52810 系列：Nordic 生态成熟、资料多、低功耗口碑好，但 SDK 学习曲线和整体 BOM 成本更高。如果你的产品对成本敏感、开发周期又紧，它的优势会被价格和复杂度抵消掉。
- ESP32-C3 这类 WiFi/BLE 双模 SoC：开发环境友好、社区资源多，拿来做原型很快。但做纯电池供电设备时，它的深度睡眠、唤醒链路和 BLE 动态功耗整体偏重，除非你本来就需要 WiFi，否则没必要扛着这块功耗和价格。
- WCH 之前的 CH579/CH58x 系列：TMOS 这套事件驱动框架从那个时期就开始沉淀了，BLE 库、烧录工具、Keil/MounRiver 生态都能平滑接续。CH592 相当于是把内核切到 RISC-V、协议栈升到 BLE 5.4 后的新一代版本。
我的观点是：这类国产 RISC-V BLE SoC 最适合的场景是“量大、功能边界清楚、对功耗和成本都敏感”的产品。它不追求覆盖所有场景，而是把一枚单片机该有的外设、射频、功耗管理尽量放在一颗芯片里，让集成方案从一开始就简单。
1.3 适用场景和边界
适合用 CH592 的产品包括：蓝牙键盘/鼠标/演示笔、温度湿度标签、ibeacon 定位标签、便携医疗小设备、智能锁/门磁、低功耗传感器节点。如果你要做蓝牙测距和室内定位，CH592 也能当 beacon 用，但 RSSI 测距在室内有很强的多径和人体遮挡效应，单点 RSSI 很不稳定，工程上建议用多个基站做指纹库，再配合行人航位推算 PDR 融合，而不是指望一个点的 RSSI 值就能精确定位。
不太适合的产品也要说清楚：需要经典蓝牙音频 A2DP/SCO 的耳机、音箱，CH592 帮不了你；需要 WiFi 协议栈的项目，请出门左转选双模芯片；本地要做重计算、对 RAM 需求超过整颗芯片容量的应用，也不要硬挤。选型阶段就把这些边界划清楚，后面集成才不会返工。
2. 硬件集成：最小系统、天线匹配和 PCB 布局的落地细节
2.1 最小系统元件表
CH592 是高集成度 SoC，芯片周围真正核心的就三块：电源、晶振、RF 匹配网络。下面这张表是我做首版原理图时固定会检查的内容：
| 部分 | 器件 | 作用 | 注意事项 |
|---|---|---|---|
| 电源 | VDD 去耦电容 1uF + 100nF | 滤除数字和射频噪声 | 电容靠近电源引脚，回路短 |
| 主晶振 | 32MHz 无源晶振 + 负载电容 | BLE 射频时钟基准 | 布局靠近芯片，晶振下方不走其他信号 |
| 低频晶振 | 32.768kHz 晶振（可选） | RTC 定时唤醒、Shutdown 低功耗时钟 | 如果做低功耗设备建议直接加上 |
| RF | LC 巴伦 + π 型匹配 | 将差分 RF 输出转为 50Ω 单端 | 元件值以官方参考设计为准，不要照抄其他芯片 |
| 调试口 | SWDIO/SWCLK/VCC/GND | 烧录和调试 | 预留 4Pin 排针或测试点 |
供电方面，CH592 的工作电压范围在 1.7~3.6V 附近，纽扣电池 3V 可以直接供电，这比很多需要 3.3V 精确供电的平台省了一个 LDO。如果你用的是 4.2V 锂电池，就必须加 LDO 或 DC-DC，把电压先稳住再进 VDD。
我习惯在立项阶段就把 32.768kHz 晶振和匹配电路占好位。第一版哪怕用内部 RC 时钟也能跑，但后续要做 RTC 定时唤醒、低温漂的功耗调度时，外部 32K 晶振的精度和稳定性还是更可靠，位置没预留的话后面重新改板很痛。
2.2 天线走线与净空区
天线是蓝牙硬件集成里最容易翻车、也最容易被忽略的一块。2.4GHz 射频信号从芯片 RF 脚出来，常见处理方式是走 LC 巴伦转换之后，再过 π 型匹配到 50Ω 天线。板上从匹配网络到天线焊盘的那段线，阻抗要控制在 50Ω 附近。
几个实际经验：
- 射频走线尽量短，不要打太多过孔，走线两侧和下方要保持完整地平面。
- 天线区域要留净空，铜皮挖掉，而且 2.4G 陶瓷天线也不是随便贴到板边就行，必须按天线厂商标注的净空尺寸布置。
- 天线附近不要放金属外壳、电池、USB 金属壳、螺丝，这些都会拉偏谐振点。
- 整机装壳之后一定要重测 RSSI。塑料壳和金属壳差距经常能到 10dB 以上，天线匹配在完全敞开时调得再好，装壳后也可能完全变形。
如果没有仪器，最简单的方法是用手机 nRF Connect 这类工具连接设备，对比设备在不同摆放方式下的 RSSI 数值，至少能定性看出天线区域有没有被结构性东西挡住。
2.3 GPIO 规划与按键扫描
HID 键盘这类产品，按键矩阵引脚最好集中放在芯片同一侧，方便走线和后续的按键扫描。睡眠前把行线和列线统一配到确定电平，防止按键扫描电路在睡眠时形成电流环路。
指示灯用 PWM 驱动而不是 GPIO 直推高亮 LED，LED 串阻选 1k~5kΩ 范围，亮度和功耗之间找个平衡。电池电压检测可以走 ADC 采样，但分压电阻会持续耗电，建议给分压网络加一个 MOS 开关，只在采样瞬间打开，采样完立刻关断。
GPIO 规划时还要考虑量产一致性：SWD 调试口、UART 日志口固定下来，别为了多用一两个 GPIO 把调试口删掉。尤其后期量产要校准、要测电流，多一个测试点就是多一条退路。
2.4 首板硬件检修清单
首板回来后不要直接上电调软件。我会按这个顺序查一遍：
- 万用表二极管档量 VDD 到 GND 是否短路，反向也要量一遍。
- 可调电源限流 50mA 上电，看电流是否异常。
- 确认 32MHz 晶振起振，用示波器看 RF 测试脚或者直接用手机搜广播。
- 串口看 Boot 日志，确认芯片跑起来了。
- 用 nRF Connect 连一次设备，确认广播、连接、断开全链路正常，再开始写业务。
这五步走完，硬件问题基本能排除八成。剩下的问题，大多是天线匹配和电源噪声，需要到有频谱仪和暗室的环境里去解决。
3. 软件框架：TMOS、BLE 协议栈与最小工程的跑通路径
3.1 拿到 CH592EVT 先做的事
官方会提供 CH592 EVT 压缩包，里面有外设例程、BLE 例程、HID 例程、OTA 例程等等。IDE 用 MounRiver Studio 或者 Keil 都可以，工程结构对 WCH 用户来说很亲切。
第一次拿到开发板，别急着写业务，先做三件事：
- 把一个 BLE 外设例程编译烧录进去。
- 手机安装 nRF Connect 或 LightBlue，搜一下设备名，确认广播和默认服务能出来。
- 打开串口日志，确认日志输出、模块启动流程都正常。
之后按自己的板子改三处配置：设备名、连接参数、客户服务的 UUID。这三处分别对应用户看到的设备名、连接功耗与延迟、以及手机 App 能找到的数据通道。只要这三处能跑通，剩下的业务逻辑往任务回调里填就行。
3.2 TMOS 事件驱动机制与主循环功耗的关系
TMOS 是沁恒蓝牙芯片上的一套任务管理框架，本质上是非抢占式事件调度器。你的业务逻辑注册成一个任务，系统空闲时检查有没有待处理事件，处理完事件之后回到空闲状态，让芯片有机会进入低功耗模式。
下面的结构只是一个流程示意，具体 API 以 SDK 头文件为准：
/* main 流程示意 */ int main(void) { SystemInit(); /* 时钟、电源域、外设配置 */ GpioConfig(); /* 按键、LED、调试口 */ CH592_BLE_Stack_Init(); MyApp_Task_Register(); /* 注册应用任务给 TMOS */ TMOS_SystemInit(); while (1) { TMOS_SystemProcess(); /* 事件分发，空闲时睡眠 */ } }这个框架对低功耗设计影响非常直接。如果你在业务代码里写一个DelayMs(100)这种忙等延时，CPU 就会在这 100ms 里全程开着，平均电流顶到 mA 级，把前面省下的功耗全部吃掉。正确做法是开一个 TMOS 定时器事件，到点再执行下一段操作，中间的时间全部交给睡眠逻辑。
我见过不少同事接手这类框架后第一反应是“这个 while 循环空转太浪费了”，然后自己加一堆轮询。其实恰恰相反，这个空循环本身就是低功耗入口，重要的是不要在业务任务里做忙等，把时间让给系统去睡。
3.3 广播、连接参数怎么设
BLE 参数直接影响功耗和体验，不能全用默认值。我常用的一套初始配置参考如下：
| 参数 | HID 外设建议 | 低功耗传感器建议 |
|---|---|---|
| 快速广播间隔 | 20~30ms | 50ms 左右 |
| 慢速广播间隔 | 1s | 1~2s |
| 连接间隔 | 7.5~15ms | 30~50ms |
| 从机延迟 | 0~2 | 4~10 |
| 连接超时 | 1~3s | 2~5s |
| 发射功率 | 0dBm，有余量可降 | 0~-8dBm |
HID 设备把连接间隔做到 7.5~15ms，是为了让键盘、鼠标的输入延迟足够低。但代价是平均功耗明显升高，因为芯片每个连接事件都要醒来收发包。传感器类设备则可以把连接间隔拉长，配合从机延迟减少无效唤醒。
另外，连接成功后设备会自动停广播，这是标准行为。如果你的产品需要支持随时被手机连接，就要处理好广播和连接状态的切换。
3.4 HID 键盘、键鼠合一的 Profile 集成要点
蓝牙 HID 是 CH592 一个很典型的应用方向，官方 EVT 里有 HID 相关例程。这里要理解清楚：BLE HID 不是一个独立协议，而是一个标准 GATT Service，Service UUID 是 0x1812，里面要包含 Report Map、Report、HID Information、HID Control Point 这些特征值。
键鼠合一的做法是在同一张 Report Map 里用 Report ID 区分键盘报告和鼠标报告。键盘报告通常包含修饰键、保留字节和 6 个按键键值，鼠标报告包含按键状态、X/Y 位移和滚轮数据。上报时每条通知前面带一个字节的 Report ID，手机或 PC 就能区分当前数据是哪类设备发来的。
这个方向我踩过的主要是配对问题：BLE HID 设备和 PC、Android 配对时，配对信息是保存的，很多设备要求绑定之后只接受白名单广播，否则每次重新开机都要再搜一次、再配对一次。工程上要提前把白名单和配对回调处理做好，不然用户侧体验会很差。
3.5 数据透传服务的 MTU 与吞吐
做数据透传时，默认 ATT_MTU 是 23 字节，扣掉 ATT 头之后单包用户数据只有 20 字节。很多低端透传模块停留在这个状态，传大文件会非常痛苦。
在 CH592 上建议把 ATT_MTU 协商到更大值。MTU 越大，单个通知能装的数据越多，传输吞吐自然越高，但如果固件配置的接收缓冲不够大，RAM 会被撑爆。我一般会在 SDK 配置里把 MTU 上限、接收缓冲个数、单包最大长度三项一起调，而不是只改一个值。
BLE 5.x 协议栈通常还提供 2M PHY、Coded PHY 这些物理层选项。2M PHY 可以把吞吐拉高，但要手机端也支持；Coded PHY 是为了远距离传输，吞吐会下降，适合低速率远距离采样，不适合高速透传。
4. 低功耗设计要点：从模式选择到电流实测的完整链路
4.1 Sleep、Halt、Shutdown 三种模式怎么理解
芯片手册里通常会把低功耗模式分成三档，不同型号的命名和细节会有一点差异，以你手上的数据手册为准。关键在于理解它们之间的功耗和保留状态区别：
| 模式 | CPU | SRAM | 外设/时钟 | 典型电流量级 | 主要唤醒源 |
|---|---|---|---|---|---|
| Sleep | 停止 | 保留 | 部分外设可运行 | 数 μA 到数十 μA | GPIO 事件等 |
| Halt | 停止 | 保留 | 时钟基本停止 | μA 级以下 | GPIO、RTC |
| Shutdown | 掉电 | 视芯片设计，通常不保留 | 全部停止 | nA~μA 量级 | GPIO、RTC |
我通常先问自己要哪种唤醒方式，再选模式。如果只是按键唤醒，Halt 一般够用，唤醒速度快，RAM 内容还在，软件不用重新初始化。如果要做 RTC 定时记录日志、定时上报，要确认在相应低功耗模式下 RTC 的工作时钟和比较寄存器还活着。如果追求极低静态电流，Shutdown 是最终选择，但唤醒后要从头初始化，不能指望 RAM 里的状态还在。
4.2 唤醒源设计
唤醒源最常用的是 GPIO 边沿唤醒和 RTC 定时唤醒。GPIO 唤醒要注意睡眠前把对应引脚拉到确定电平，避免悬浮电平一直抖。RTC 定时唤醒要依赖低频时钟，外部 32.768kHz 晶振比内部 RC 精度高得多。
我遇到过的一个典型问题：每次唤醒后，上一个唤醒周期打开的 UART、ADC、SPI 没有显式关闭，导致平台平均电流多了将近 200μA。后面我养成了习惯，在唤醒处理函数末尾统一关闭外设时钟，再进入下一轮低功耗。
提示：低功耗不只是“选一个模式”，更是“进入模式前把系统和外设恢复到已知状态”。这步不做，模式选得再低，实际功耗也降不下来。
4.3 平均电流和 BLE 参数权衡
BLE 低功耗项目的平均电流主要由射频唤醒窗口决定，CPU 频率和 Flash 操作通常不是大头。粗略估算公式是：
平均电流 ≈ 活动电流 × 活动时间 / 周期 + 静态电流
做连接态功耗测试时，芯片每个连接事件要醒来约 1~5ms 收发包，取决于包长、PHY 和协议栈处理。举例：
- 连接间隔 30ms、从机延迟 0，每个连接事件活动 6ms，活动电流按 8mA 估，平均就是 8mA × 6 / 30 ≈ 1.6mA，加上静态电流也压不到哪里去。
- 连接间隔 50ms、从机延迟拉到 19，有效连接周期变成 1s，每个事件活动 6ms，平均就到 8mA × 6 / 1000 ≈ 48μA，再加上静态电流，整机续航就非常可观。
你可以在软件里做动态连接间隔：设备空闲时向手机申请拉长连接间隔，检测到按键或数据需要传输时再随时申请缩短连接间隔。这个功能很多手机端协议栈支持，层层的参数协商对用户体验和功耗是一个很实用的平衡手段。
4.4 实测电流的正确姿势
低功耗设计最终要用实测数据说话，不能只看手册标称值。我常用的测量方法有这么几种：
- 精密万用表：串联在电源回路里，切到 μA 档，适合测静态电流，但看不到动态波形。
- 采样电阻 + 示波器：在 VDD 回路串一个 10Ω 采样电阻，用示波器测电阻两端压差，压差除以电阻就是电流。可以看到广播、连接事件、睡眠各个阶段的实时波形。
- 功耗分析仪：比如 Joulescope 这类专用工具，能同时测电压、电流、能量，调试复杂功耗问题时效率高很多，预算够的话值得买一台。
测低功耗前一定要断开调试器，WCH-Link 这类工具的 SWD 线上拉电阻和给目标板供电都会污染电流数据。如果你需要抓日志，用独立的 USB 串口模块供电，跟被测板之间只连 TX 和 GND，不要额外供电。
提示：万用表电流档本身有内阻，在低电压场景下可能把芯片压到复位边缘；测电流时尽量用可调电源单独供电，或用采样电阻看动态波形，避免电流表内阻干扰。
4.5 我实际踩过的低功耗翻车点
- 未用 GPIO 悬空：每个悬空脚都会产生漏电，虽然是 nA~μA 级别，但整机 20 个脚加起来就很可观。把所有未用引脚显式初始化成确定的输入下拉或输出低电平。
- 外部上拉电阻漏电：1MΩ 上拉在 3V 下就是 3μA，看起来很小，但在目标是整机 10μA 以下的设备里，一个电阻就吃掉三分之一预算。能用内部上拉尽量用内部，必须外部上拉时选高阻值并确认睡后状态。
- 传感器和运放没断电：低功耗系统的电流大头往往不在 MCU，而在外部器件。用 GPIO 控制 DC-DC 的 EN 脚或负载开关，睡眠时直接把这些器件从电源上断开。
- 关机边缘电压复位：使用纽扣电池时，如果进入 Shutdown 模式的电流瞬间拉低电压，低电保护没做好会让芯片反复复位。要仔细看电源瞬态，必要时加一个小电容储能。
5. 量产与测试环节容易忽略的几个点
5.1 烧录、日志和调试
开发阶段用 WCH-Link 的 SWD 两线烧录调试就行，MounRiver Studio 和 Keil 都支持工程导入。量产环境可以考虑做烧录夹具或者直接走芯片 Boot 模式批量下载。
日志输出也要工程化管理：开发版留着 UART 日志重定向，发布固件时把日志宏关掉，否则日志打印本身会不停唤醒 CPU 和占用引脚。我在量产机上见过日志开着导致整机静态电流翻倍的案例，最后定位到就是 UART 一直有个 TX 低电平在推电流。
5.2 产测项目
量产时建议固定这样几项测试：
| 测试项 | 方法 | 通过标准 |
|---|---|---|
| 射频频偏/功率 | 频谱仪看单载波或发射功率 | 在标称范围内 |
| 与手机连通性 | 用标准手机 App 扫描并连接 | 可发现、可连接、可断开重连 |
| 待机电流 | 设备自动进入睡眠后测静态电流 | 按设计阈值，比如 3 秒内 <10μA |
| 功能回路 | 按键触发、LED、传感器上报 | 全流程自动判断 |
静态电流抽检是我每次都会强调的一项。它会暴露贴片不良、漏焊、GPIO 配置错误、外设没关干净等一系列问题，比单纯测射频更能反映整机质量。
5.3 与手机兼容性和重连
BLE 设备最终都要和手机、PC 配合，兼容性测试要提前安排。Android 各厂商的 BLE 协议栈差异很大，HID 设备连接行为也不完全一致；iOS 上对 BLE HID 外设的限制比较多，如果你的目标设备是手机外设，一定要先确认目标系统的支持策略，再决定要不要走标准 HID Profile。
重连逻辑也要做细：配对后写白名单，开机只对已配对主机发定向广播，既能省电又能减少被无关设备搜到的概率。手机系统省电策略可能会在后台杀掉扫描进程，尤其 Android，设备端保持稳定可发现的广播间隔，比反复高频广播更靠谱。
最后分享一个我做低功耗实测的土办法：在电源回路里串一个 10Ω 采样电阻，测功耗时示波器两只探头放在电阻两端看压差波形，先看整机静态波形对不对，再按一次按键触发唤醒，看唤醒后的电流包络。很多时候问题定位就在那一两条波形的对比里，是 GPIO 没关、串口在推流、还是射频窗口没收敛，一目了然。芯片的低功耗参数是官方的，但只有自己实测到的数据，才是项目里可以拿来拍板的依据。
