从去年下半年开始团队陆陆续续做过几个基于沁恒 CH592 的蓝牙低功耗项目包括一个两节纽扣电池供电的温湿度传感器、一个带蓝牙 HID 功能的遥控器还有一个需要做私有 2.4G 与 BLE 共存的数据采集终端。说实话CH592 这颗芯片在低成本 BLE 方案里算是把集成度和低功耗平衡得相当不错的一颗但前提是你得吃透它的低功耗机制和射频特性否则最后做出来的板子功耗能跑到几十上百微安跟手册上写的零点几微安完全两个世界。这篇就围绕 CH592 的集成方案和低功耗设计把我踩过的坑、验证过的参数、参考过的算账方法一次性整理出来。CH592 是一颗集成 BLE 5.3、支持蓝牙 HID、自带 2.4G 私有协议、内置 USB 控制器和触摸按键通道的 RISC-V MCU适合做遥控器、键鼠、传感器节点、电动牙刷之类的小型低功耗产品。但芯片本身再强如果你的电源拓扑、晶振布局、广播间隔设置、GPIO 默认电平没处理好整机功耗和连接稳定性都会出问题。这篇文章会把从硬件选型到软件调参再到功耗实测的完整链路都过一遍适合正在做 CH592 选型评估、或者已经画完板子正在调功耗的工程师参考。1. 项目整体思路与芯片选型背后的事1.1 CH592 的产品定位与资源盘点先给不熟悉这颗芯片的朋友交代一下背景。CH592 是沁恒的 RISC-V 内核低功耗蓝牙芯片支持 BLE 5.3自带 2.4G 私有协议还有 USB 主机/设备控制器、触摸按键检测、12 位 ADC、多个 UART/SPI/I2C内置 512KB Flash 和 32KB SRAM。最大亮点是它的蓝牙 2.4G双模能力意味着同一颗芯片既能跑标准 BLE 通信也能跑私有 2.4G 协议这两个模式之间可以分时切换非常适合做BLE 配网 2.4G 私有高速通信的产品。选型的时候有一个细节容易被忽略CH592 是 MounRiver Studio 或 WCH 系列 IDE 开发SDK 里同时提供了 BLE 和 2.4G 的协议栈但是 Flash 和 RAM 的占用要提前规划。比如你既要开 BLE 广播又要跑 OTA还要保留一段非易失的用户数据存储区那么 Flash 分区方案就得在项目启动时就定好不然中途换分区会牵扯到 BootLoader 和 App 地址跳转比较折腾。再一个情况是CH592 的定位其实和 nRF52810、泰凌微 TLSR8258、杰理 AC79xx 系列有一部分重叠但它更有特色的地方是内置 USB 和触摸按键。这意味着做一个 BLE 键盘或者遥控器不需要再外挂一颗触摸 ICPCB 面积和 BOM 成本都能降下来。和我之前用蓝牙 MCU 独立触摸芯片做的方案相比CH592 的集成方法确实省事硬件调试的工作量也小了不少。1.2 集成方案里的核心矛盾功耗、射频、成本任何蓝牙方案设计本质上都在解决三个矛盾——够不够省电、连不连得稳、贵不贵。CH592 的 BLE 接收峰值电流大概在 7~8mA发射电流在 8~16mA 之间这个数字在中低端蓝牙 MCU 里属于正常水平但真正决定续航的是睡眠功耗。低功耗芯片的设计思路很简单平时尽量睡觉醒来干完活赶紧继续睡。CH592 提供了多种低功耗模式比如 Shutdown、Standby、Sleep 等。但进得去是一回事睡得沉是另一回事。如果你的外部器件在睡眠时还在耗电比如 LDO 的静态电流、Flash 的待机电流、GPIO 上下拉电阻的漏电那整机功耗就不是芯片数据手册能扛住的。集成的意义不是把芯片焊上去就完事而是要把整个板级的功耗和射频链路作为一个整体来设计。这也是为什么我会在整篇文章里反复强调软件层面的低功耗策略必须跟硬件设计配合两者拆开单看都是空谈。2. 低功耗设计的底层逻辑2.1 先把低功耗模式分清楚别上来就 SleepCH592 的低功耗模式并不只是睡眠越深越好。我习惯把它的功耗模式粗略分成三档运行态、浅睡态、深睡态。运行态就是 CPU 和射频都在工作功耗在毫安级别浅睡态一般指低频时钟还在跑RAM 保持可以快速唤醒深睡态则是尽可能关闭所有时钟和外设只保留必要的唤醒源电流能做到几个微安以下。实际设计里要按业务场景来选择睡眠模式而不是一味追求最低功耗。比如一个 BLE 温湿度传感器如果希望保持蓝牙连接并定期上报数据那它需要能够被连接事件唤醒这时候用保持时钟、RAM 不掉电的模式更合适因为每次连接事件来了之后能快速处理不用重新初始化协议栈。而如果是一个纽扣电池供电、每天只开机一次的智能标签那就应该用最深的睡眠模式用 GPIO 中断或定时唤醒醒来之后初始化协议栈再广播这样待机功耗能压到极低。这里有个常见误区很多人以为进入睡眠模式后BLE 连接还保持这是不可能的。你要睡深了连接就断了你要保连接就得在广播/连接事件之间醒来。所以设计的第一步是明确产品形态是连接保持型还是事件上报型。这个决策会直接影响所有后续的功耗参数。2.2 功耗预算的计算方法和工作场景建模做低功耗设计最忌讳边做边猜。我在项目启动阶段就会先做一张功耗估算表把每个工作阶段的电流、持续时间和频率列出来最后折算成平均电流验算电池寿命。举个例子一个温湿度传感器设计成每 30 秒唤醒一次做测量和 BLE 广播每次唤醒工作时间 50ms工作电流 8mA睡眠电流 3uA电池用 CR2032容量 220mAh。那么平均电流大概是(0.05 秒 * 8mA 29.95 秒 * 0.003mA) 除以 30 秒约等于 0.0163mA也就是 16.3uA 左右。用 220mAh 除以平均电流理论续航大约 13500 小时差不多一年半。这个算账过程能帮你快速判断设计方案是否可行。但要注意平均电流只是第一层。第二层要关注峰值电流能不能被电池和电源芯片承受住。纽扣电池内阻比较大如果发射瞬间需要 16mA电池电压会被拉低严重时会造成复位或者射频性能下降。所以硬件设计上要加一个大一点的储能电容放在电池和芯片电源引脚之间这个电容的作用就是水库平时充电发射瞬间放电避免电压跌落。软件上同样可以做功耗建模比如 BLE 广播间隔设成 100ms 和 1s平均电流差很多。用 100ms 广播间隔每次广播时间约 1ms 接收窗口功耗约 8mA算下来平均电流增加不少但手机连接速度更快。这个取舍没有标准答案得看产品交互需求但一定得在代码里做成可配置项方便现场调整。3. 硬件集成方案与 PCB 设计实操要点3.1 天线匹配与射频布局CH592 的射频前端是单端射频输出需要预留 π 型匹配网络。这个网络一般由一个串联电感和两个并联电容组成作用是匹配天线阻抗兼顾滤波。原理图上看就是一根 RF 走线从芯片出去经过 π 型网络再到天线但真正决定性能的是 PCB 布局。射频走线要用 50 欧姆阻抗线尽量短不要有过孔。如果走线必须转弯用圆弧或 45 度角避免直角反射。地层要完整天线下方最好不要铺铜净空区要按天线厂商的推荐留足。我见过太多人把天线区域下方铺了完整地平面导致辐射效率严重下降蓝牙信号强度掉了将近 10dB。调试的时候如果你没有网络分析仪最实用的方法就是做整机拉距测试和灵敏度测试。CH592 的 BLE 接收灵敏度大约在 -97dBm 左右实际板子如果做到 -90dBm 以上在室内已经够用了。如果没有仪器也可以用手机连接在固定距离观察 RSSI反复调匹配电容的值找到 RSSI 最好的组合。这个方法虽然土但很有效。3.2 电源系统设计LDO、电池和去耦电容CH592 工作电压范围比较宽一般是 1.8V 到 3.6V可以直接用纽扣电池供电这是它做低功耗产品很方便的一点。但如果你的系统里还有其他外设比如屏幕、传感器而且输入电压可能到 5V那就要加 LDO。选 LDO 的时候重点看静态电流普通 LDO 的静态电流可能在几十微安对于整机目标电流只有几微安的产品来说这个静态电流就是毁灭性的。所以要么选超低功耗 LDO要么干脆电池直供。去耦电容的摆放我一直坚持靠近电源引脚的原则。CH592 的电源脚一般建议放 1uF 左右的电容靠近射频电路还要额外放一个 100nF 的高频去耦电容。这里要说一个实战细节不要只盯着容量还要注意电容的 ESL/ESR。射频瞬间电流需要低阻抗路径多层陶瓷电容的封装越小寄生电感通常越小所以 0402 比 0603 在高频去耦场景下更有优势。电源平面和地平面也要认真处理。如果做双层板推荐底层尽量完整铺地顶层走信号RF 区域不要走其他高速信号线。如果有条件可以做四层板第二层整层做地这样射频和电源的完整性会好很多抗干扰能力也更强。3.3 晶振与复位电路这些不起眼的地方CH592 需要一颗高频晶振比如 32MHz和一颗低频晶振32.768kHz来提供不同时钟域。高频晶振用于射频和 CPU 主频低频晶振用于低功耗模式下的定时唤醒和 BLE 协议栈的计时。如果低频晶振不工作很多低功耗模式根本进不去或者唤醒时间不对。晶振布局要把负载电容尽量靠近晶振引脚走线短而直别绕。这里有个容易翻车的点负载电容的取值要跟晶振的 datasheet 匹配通常是在 6pF 到 12pF 之间。如果容值不对晶振的起振余量不足会出现冷启动不起振、热机之后正常的怪问题排查起来非常痛苦。复位电路相对简单一般接一个上拉电阻再加一个小电容到地用于滤除毛刺。CH592 内部有上电复位和掉电复位外部复位电路主要是在调试阶段方便手动复位。如果你发现板子偶尔跑飞优先检查复位脚有没有被噪声干扰而不是怀疑代码。4. 软件层面的低功耗实现与协议栈调优4.1 BLE 广播参数和连接参数的权衡软件层面的低功耗优化核心是控制射频活动时间。BLE 协议栈里能调的主要就这几样广播间隔、广播数据长度、连接间隔、从机延迟slave latency、超时时间。每一项都直接影响平均电流。广播阶段间隔越长越省电但连接发现速度越慢。我一般把广播间隔设成 100ms 到 1s 可配置让产品出厂默认用较快广播间隔方便用户配对配对完成后切换到较慢广播间隔或者直接停止广播然后建立连接。连接阶段连接间隔决定主机与从机的通信频率。间隔越短数据延迟越小但是双方都得频繁醒来功耗高间隔越长延迟越大功耗越低。CH592 的 BLE 协议栈可以接受主机下发连接参数请求但很多手机厂商的主机不会主动采纳你的建议所以实际产品里如果从机想省电更好的办法是使用从机延迟。从机延迟的意思是从机可以选择跳过若干个连接事件不要每个连接事件都醒来响应主机这样平均功耗能大幅下降。比如连接间隔 30ms从机延迟设为 4实际从机每 150ms 才醒来一次功耗就省下来了。这里要提醒一个问题从机延迟设置太大会导致主从之间的交互变慢如果你的产品有实时控制需求比如蓝牙灯、蓝牙锁那就不能设太大。必须在响应速度和功耗之间做平衡而且每个具体产品要实测。4.2 外设管理和 GPIO 电平的隐藏功耗很多低功耗项目最后测出来多出几十微安问题往往不在芯片而在 GPIO 和外设。CH592 的大部分 GPIO 都有内部上拉或下拉电阻但默认状态可能是浮空。浮空的 GPIO 在睡眠模式下会因为外部电平不确定而反复翻转带来额外的漏电甚至引起芯片从低功耗模式唤醒。所以进低功耗之前一定要把不用的 GPIO 统一设置为确定电平要么输出低要么使能内部下拉。特别要注意那些连到外部器件的引脚比如按键扫描脚、LED 控制脚如果外部器件在睡眠时还在通过 GPIO 灌电流那功耗就白省了。外设管理上我要强调一个规则用到的才开不用的就关。CH592 集成了 USB、触摸、ADC、多个串口和 SPI默认状态可能有部分外设时钟是开的。在进入睡眠之前要把所有不需要的外设时钟关掉把 ADC 和触摸模块也停掉否则它们在后台跑低功耗模式根本沉不下去。另外还有个细节是代码里的等待循环。有些开发者喜欢用忙等待方式延时比如DelayMs(100)这在正常运行时没毛病但在低功耗产品里100ms 的忙等待意味着 CPU 全速跑了 100ms功耗浪费非常大。正确的做法是在需要延时的场景尽量用定时器唤醒或者协议栈的软件定时器让 CPU 在等待期间进入睡眠。4.3 协议栈集成时要注意的 RAM 和 Flash 占用CH592 的 SDK 集成了 BLE 协议栈但协议栈本身会占用一部分 RAM 和 Flash。如果你的 App 代码写得比较胖可能会遇到 RAM 不够用或者 Flash 放不下的情况。我建议在工程早期就把协议栈的裁剪开关看一下比如不需要 GATT 服务就关掉相关特性不需要多连接就限制连接数为 1。Flash 分区也要提前规划。OTA 固件升级需要预留一块独立的 App 区启动时要判断是否需要跳转到 BootLoader。这块逻辑如果没规划好后期的升级功能会很难加。我自己的习惯是BootLoader 占 8KBApp 区尽量留足再用一小块区域存系统参数这样即使 OTA 写失败了设备重启还能回到旧版本。还有一点是中断优先级。BLE 协议栈要求 RF 中断和定时器中断有比较高的优先级如果被其他无关中断阻塞会导致蓝牙协议栈处理不及时出现掉连接或者广播卡顿。所以在写驱动的时候中断服务函数里不要做耗时操作只做标记把逻辑挪到主循环或者任务里处理。5. 蓝牙集成调试与常见问题排查实录5.1 连不上、掉连接、扫描不到设备蓝牙项目最头疼的就是扫描不到设备和连上了又掉。这些问题优先排查射频硬件再排查软件参数。扫描不到设备先看芯片是不是真的在广播。把广播间隔调到 20ms用手机 nRF Connect 这类工具扫描如果还是看不到大概率是射频问题要么天线匹配不对要么晶振频率偏了要么射频走线有问题。我曾经遇到过一块板子高频晶振虚焊导致广播信号从 -30dBm 掉到 -70dBm手机在现场完全连不上。连上就掉原因通常是连接参数问题。手机和从机之间如果连接间隔协商失败或者从机响应不及时连接就断了。可以先查看协议栈返回的连接句柄事件看看断开原因是什么比如 0x08 表示超时。如果是超时尝试减小连接间隔或者关闭从机延迟再观察。还有一种情况是电源问题。发射瞬间电流过大板级电源跌落芯片复位或者射频失锁表现为近距离能连上远距离一发射就断。这时候先示波器打一下芯片电源引脚的波纹看看发射瞬间有没有明显跌落如果有就在电源端加一个 100uF 或更大的钽电容或者升级电池型号。5.2 实测功耗偏高从哪里开始查当你用功耗仪测整机电流发现比理论值高很多的时候别慌按照从硬件到软件的顺序一点点排查。先把芯片外围所有跳线断开只保留最小系统测芯片本身的睡眠电流。如果这时候已经偏高了检查是不是 GPIO 浮空或者低频晶振没有停。很多芯片进入睡眠后如果低频晶振还在跑电流会多个好几微安。如果最小系统电流正常那就把外设一个一个接回去每次接入一个模块就重新测一次很快就能定位到是哪个外设漏电。软件层面的排查我用过比较有效的一招是把所有外设驱动都注释掉只跑协议栈进低功耗看睡眠电流是否正常。然后逐个打开外设测出每个外设增加的功耗。这样就能区分到底是硬件漏电还是代码没有正确关闭外设时钟。另外注意功耗仪的采样率。BLE 的广播是周期性脉冲式的平均电流小但峰值电流高普通万用表测不出来真实平均值要用带积分功能的精密功耗分析仪或者至少用示波表配合电流探头在被测设备两端并联一个取样电阻通过看波形估算平均电流。5.3 Bluetooth HID 与私有 2.4G 模式的经验CH592 支持蓝牙 HID做遥控器或键鼠的时候很方便。HID 设备的广播包里面要包含 HID 服务的 UUID手机或者 PC 才能识别出这是键盘还是遥控器。如果广播数据配置不对PC 端能搜到设备但连接后没有输入响应。我在做蓝牙 HID 键盘时踩过一个坑初始化完协议栈直接开启广播结果 PC 提示配对失败。后来查代码发现 HID 的 report map 配置有误键盘的按键码没有正确映射。蓝牙 HID 的 report map 是描述键盘/鼠标功能的特殊数据结构必须严格按照 HID 规范来填错一个字节主机就认为设备不合法。私有 2.4G 模式则是另一套玩法。CH592 的 2.4G 可以和 BLE 共存但同一时间只能跑一个协议。如果你需要在 2.4G 通信过程中保持 BLE 连接那么只能采用分时切换比如每 100ms 切换一次。注意切换会产生一个短暂的盲区如果 2.4G 收发的数据量比较大可能影响 BLE 的响应速度。这个模式下我建议把 2.4G 通信的时隙和 BLE 连接事件对齐尽量让两个协议的射频窗口错开这样能减少冲突和重传。6. 一些实际项目里的数据与调试心得上个月帮朋友调一个 CH592 的低功耗门锁遥控器方案目标是用两节 CR2032 撑两年。整机待机电流要求在 5uA 以下蓝牙按键按下的时候工作电流 10mA 左右每次按键时间 200ms。最初待机电流测出来是 13uA超了 8 个微安。排查过程很典型先断开外设最小系统电流 3uA正常范围。然后一路接回触摸按键驱动电流变成 5.5uA再接回 LED 控制脚发现 LED 脚的 GPIO 配置成输入浮空外部噪声导致反复翻转灌进去了一点电流修复后待机 5.8uA。最后再压下去的一点功耗是靠把低频晶振的负载电容从 12pF 微调成 9pF起振电流小了一些整机待机降到了 4.7uA达标。这个案例给我的体会是低功耗设计不是某一个大招而是无数细节的叠加。每一路 GPIO、每一个外设时钟、每一段忙等待代码都可能在偷偷吃掉你的电池寿命。把整机功耗当成一个预算表一项项核对每一项消耗比盲调某个参数有效得多。CH592 项目最后能跑多低很大程度上取决于你能不能管住每一微安。所以我的建议是从第一个 demo 板开始就引入功耗测试工具建立每次改动的电流记录表格这样你的功耗优化过程就是有迹可循的而不是靠运气。这个习惯是我做过十几个低功耗项目后觉得最值得养成的。