1. 选型逻辑为什么把蓝牙功能直接做进 MCU 里1.1 CH592 在可选的蓝牙方案里到底属于哪种定位前两年做低功耗蓝牙产品我一直在两种方案之间摇摆一种是主控 MCU 蓝牙模块主控跑应用逻辑模块负责协议栈和射频两边用串口通信另一种是一颗蓝牙 SoC 搞定所有事应用代码和协议栈跑在同一颗芯片里。CH592 属于后者而且是比较彻底的后者。这颗芯片是沁恒基于 RISC-V 内核做的 BLE SoC射频收发器、基带、协议栈、应用处理器全部集成在一颗芯片里。也就是说你不需要再去单独选一颗蓝牙模块也不需要额外再挂一颗主控 MCU。对于做传感器、Beacon、智能家居面板、电子标签这类产品来说这颗芯片的资源是够用的常规 GPIO、UART、SPI、I2C、ADC、PWM 都有内置 Flash 和 RAM跑应用逻辑绰绰有余。我拿到的 CH592 样片支持的是 BLE 5.4 协议栈这一点对做低功耗设备很重要后面我会专门讲协议栈版本对广播、连接和功耗的影响。芯片支持多种低功耗模式官方标称的睡眠功耗在微安甚至亚微安级别但这里我要先说一句标称值永远只代表芯片自己不代表你的整机。这也是我在文章标题里强调低功耗设计要点的原因真正的功耗大头往往藏在你的外围电路和软件调度里。1.2 对比主控 MCU 蓝牙模块的老方案我在早期产品里用过很成熟的串口透传模块比如 HC-05 那种经典蓝牙模块也用过一些 BLE 透传模块。这类方案的好处是开发快模块内部已经把协议栈封装好了主控只要发 AT 指令就能收发数据。但缺点也很明显功耗拉不起来模块本身要一直维持一颗独立的射频芯片工作哪怕你让模块进入低功耗模式主控和模块之间的串口、状态检测引脚也会产生持续漏电。两块芯片的低功耗联动远没有单芯片做得好。体积和成本下不去模块有屏蔽罩、天线、外围晶振和电感占用 PCB 面积大成本也高。做消费品每一分钱和每一平方毫米都很关键。调试链路长主控和模块之间的串口波特率、流控、数据分包任何一个环节出问题都会导致连不上、丢包。出了问题还要先判断是主控代码问题还是模块固件问题排查起来特别费劲。换成 CH592 这样的单芯片方案之后应用跑在芯片上协议栈也跑在芯片上射频链路直接从芯片出来到天线中间没有串口和模块固件这一层翻译电路设计和故障排查都简单不少。从 BOM 成本上看也很有优势一颗芯片加晶振加少量阻容就能工作。当然单芯片方案不是没有代价。天线设计和射频走线需要你亲自处理不能像模块那样插上去就能用蓝牙协议栈的配置、GATT 服务搭建、广播和连接参数调整都要自己写或者至少自己要看得懂。这也是我写这篇文章的原因把集成过程和低功耗设计里最容易翻车的地方讲清楚。1.3 适合与不适合的场景做选型一定要先分清场景。我个人的判断是适合电池供电的 BLE 传感器温湿度、门磁、运动检测、Beacon 定位发射端、电子货架标签、智能门锁、遥控器、穿戴设备。这类产品数据量小、连接频率低、对续航要求高CH592 这种高集成度 BLE SoC 是天然匹配。勉强适合需要同时跑较重应用逻辑比如复杂的 UI、音视频协议且对主频和内存要求高的产品虽然 CH592 能跑不少应用代码但硬塞进去会导致开发效率降低。不适合需要连续高速率传输的场景比如蓝牙音频、大数据量的厂商私有高速通信需要大规模 MESH 组网且对网络拓扑要求极高的场景建议优先选功能更强的专用方案。我在产品选型时有一条经验先画出系统功耗预算和通信模型再看芯片能不能覆盖。如果应用逻辑简单、交互以低频率小数据量为主那单芯片 BLE SoC 是最优解。下面开始讲硬件集成这部分做不好后面功耗和射频全都会崩。2. 硬件集成方案最小系统到量产板的几个关键环节2.1 最小系统清单与布局顺序CH592 的最小系统比我最初想象的简单主要组成部分也就这么几块电源供电与去耦、高频晶振射频基准时钟、低速时钟如果芯片内部没有集成 RC或者你需要在低功耗模式下维持 RTC、天线和匹配网络、复位/下载调试接口。画原理图的时候我习惯先按电源域和射频域把电路分成两块。电源域负责把所有电源引脚的退耦电容放到位射频域负责把天线、匹配电路、晶振这一类高频器件就近布置。这两块如果混在一起布局后患无穷尤其射频部分走线稍微绕一下灵敏度就能差出好几个 dB。具体到 CH592建议严格按照数据手册的引脚分布来规划。高频晶振尽量靠近芯片的 XI/XO 引脚走线要短两侧包地。匹配网络和天线之间的走线要控制阻抗如果能做到 50Ω 最好做不到也要保证走线短且相对宽度一致不要在中途换层。电源引脚旁边放 0.1μF 和 1μF 或 10μF 的组合电容高频去耦和小电流储能都要覆盖。2.2 晶振选型与匹配电容的计算细节晶振是低功耗蓝牙设备里最容易看似正常、实则隐患的器件。CH592 正常工作需要一颗高频晶振作为射频收发器的基准时钟频率一般是 MHz 级别如果要用低功耗 RTC 定时唤醒还需要一颗低速晶振——具体频率以你手上的芯片型号和数据手册为准不同批次可能不一样。我这次选型用的是 32MHz 高频晶振低速晶振也配上了这样 Sleep 模式下 RTC 还能走定时唤醒从软件上实现起来最稳。晶振选型要重点看两个参数负载电容CL和等效串联电阻ESR。负载电容直接决定匹配电容的取值公式很简单C匹配 (CL - C寄生) × 2比如晶振的 CL 是 12pF芯片引脚寄生电容大约 2~3pF那么每边匹配电容大约取 16~20pF。实际调板时还要再微调因为 PCB 走线的寄生电容也会影响。我遇到过一批板子常温下晶振起振没问题但放到高低温箱里就偶发启动失败最后查下来就是匹配电容偏小晶振负阻余量不足。所以建议晶振两侧的匹配电容预留一个调试位不要一上来就焊死。另外低功耗设计和晶振的功耗也有关系。晶振起振后要消耗电流低频晶振比高频晶振电流小很多但高频晶振只有在射频收发时才需要。所以软件里射频不工作时一定要把高频晶振停掉进入 Sleep 后只保留低速晶振跑 RTC。这个细节如果没注意整机睡眠电流会被高频晶振拖住比你预期的多出几百微安。2.3 天线布局、净空区和阻抗匹配天线部分我强烈建议在原理图阶段就预留一个 π 型匹配网络串联电感、并联电容、再串联电感的 C-L-C 形式。虽然很多参考设计会告诉你直接抄官方天线就行但实际 PCB 的地层厚度、外壳结构、电池位置、甚至 USB 座都会影响天线阻抗。留匹配位就是为了在调试阶段能把驻波调回来。PCB 天线底下的净空区是重中之重。天线正下方以及周边一定范围内不要铺地、不要走线、不要放金属器件具体净空尺寸参考芯片厂商的参考设计一般至少保证天线周围一圈没有铜皮和元器件。我之前做的一款外壳是金属边框的产品天线装在塑料支架里看着离金属还有一段距离但实际测灵敏度掉了接近 6dB后来把天线位置往下挪了 5mm 才好。这种问题靠仿真能提前发现如果仿真条件不允许就一定要留出足够的调试余量。天线走线如果用的是 PCB 天线走线宽度根据板厚和叠层算一下普通双层板控制在 0.8~1mm 左右即可但更重要的是共面波导或者说参考地要连续。天线馈线两侧的过孔要打密把顶层地和底层地缝合起来这样信号不会泄漏到 PCB 边缘去。2.4 电源设计对射频和低功耗的双重影响CH592 这类 BLE SoC 对电源噪声比较敏感。射频发射瞬间电流会有比较大的脉冲如果电源纹波大会导致发射频谱杂散、接收灵敏度下降。电源设计时要注意电池直接供电的话尽量走低阻抗路径电源引脚旁边至少放置一个大容量储能电容10μF 以上靠近射频发射电路再放一组 0.1μF 高频去耦。如果是用 LDO 或 DCDC 供电LDO 的静态电流一定要小。很多 LDO 静态电流是微安级信号处理器或其他数字电路用着没问题但在低功耗设备里这几微安可能比芯片 Sleep 模式本身的电流还大直接废掉整机续航。DCDC 方案效率高但开关噪声会对射频产生干扰要注意电感位置远离天线输出电容也要选低 ESR 的。软件里还要配合电源策略在进入低功耗模式前关闭没有使用的外设电源域如果有外部传感器用 MOS 管或负载开关独立控制供电采集完立即断电。不要把传感器一直挂在 VCC 上待机很多传感器待机电流标称很低实际量产批次参差不齐整机功耗预算会被一个个小漏电路吞噬掉。3. 低功耗设计从芯片标称参数到整机真实功耗的落差3.1 CH592 的功耗模式与状态切换路径低功耗设计的第一步是彻底吃透芯片的工作模式。CH592 主要的工作模式可以用一张表理清楚模式CPU 状态外设状态典型唤醒方式我的理解Active运行运行中全部可用-正常工作瞬时电流最大Sleep睡眠暂停可配置保留或关闭定时器、GPIO、RTC保留 RAM 和部分寄存器唤醒快Shutdown关断关机大部分关闭特定 GPIO、复位、某些专用唤醒源电流最低但醒来像冷启动不要把 Sleep 和 Shutdown 当成唯一的省电手段真正的低功耗产品往往是多级功耗状态来回切换。比如连接建立后每次连接间隔事件到来芯片就醒来处理数据处理完立即回 Sleep长时间没有交互则进入更深的低功耗状态只保留 RTC 定时唤醒做周期广播或扫描。这里有一个容易踩的坑芯片在 Sleep 模式下UART、SPI、I2C 这些外设如果不显式关闭或者引脚没有配置成确定状态会产生漏电流。低功耗设计不只是调一个模式变量而是要把所有引脚状态、时钟开关、外设电源全部管理起来。3.2 事件驱动把轮询改成醒来做一下做完就睡低功耗软件架构的核心原则是能睡就睡睡深一点。我用 CH592 做完一颗温湿度传感器的固件架构是这样的初始化所有外设和传感器注册 GATT 服务和广播参数主循环进入低级功耗等待通过 RTC 定时器设置一个唤醒周期比如 10 秒RTC 时间到芯片醒来打开传感器电源等待传感器稳定发起一次 ADC 或数字接口读取计算和处理数据更新 GATT 特征值决定是否广播一次比如 Beacon 场景或保持待连接状态关闭传感器电源关外设时钟再次进入 Sleep。伪代码大致是while (1) { // 进入睡眠前关掉不必要的时钟和外设 sensor_power_off(); uart_disable(); adc_disable(); // 配置下一次唤醒时间比如 10s 后 set_rtc_wakeup(10000); enter_sleep_mode(); // 醒来后第一时间恢复时钟和引脚 system_clock_restore(); sensor_power_on(); adc_enable(); sensor_data read_sensor(); update_gatt_characteristic(sensor_data); // 根据是否需要广播/连接决定下一跳状态 decide_next_power_state(); }这套结构看起来简单但很多产品做不到位原因无非是启动恢复时间太长导致频繁唤醒反而耗电、传感器上电等待时间过长、GPIO 在睡眠期间处于浮空状态等。特别强调一下 GPIO 状态所有进入睡眠的引脚要么输出低要么设置成上拉或下拉绝对不能让引脚悬空。悬空引脚会产生不确定电平导致内部缓冲器反复翻转漏电这个电流虽然不大但会显著抬高整机睡眠功耗。3.3 外设隐性损耗传感器、稳压器、指示灯芯片本身的低功耗做得好不代表整机功耗就好。我做过一次整机功耗测量才发现问题根本不在 CH592 上而是在一颗小小的电源指示灯上。LED 加限流电阻看起来电流只有一两个毫安但如果软件忘了在睡眠前关掉它这一个 LED 的功耗就比整颗芯片睡眠功耗高了好几个数量级。外设部分需要逐项排查的隐性损耗传感器待机电流很多传感器有 sleep 模式但默认状态下并不一定进入需要用寄存器显式配置上拉/下拉电阻I2C 上拉电阻、按键上拉电阻在睡眠时如果有路径电流流过会持续漏电必要时用 GPIO 动态控制上拉电源电源指示灯和电平指示建议把电源指示灯的驱动方式设计成仅在唤醒期间点亮并加 MOS 开关控制供电;LDO/DCDC 静态损耗前文提过LDO 静态电流要选低于目标睡眠电流的型号电池保护板和电量计如果使用了电量计注意它本身的休眠模式有些电量计一直跑可以到微安级可以接受但如果是几十微安就要重新评估。一个系统化的做法是把整机功耗预算表列出来逐项填写待机电流、工作电流、工作时长就能很快定位是哪个环节超标。低功耗不是玄学是加减乘除。3.4 实测功耗的正确姿势采样电阻和波形万用表测平均电流完全不够用。BLE 设备是突发式功耗模型平时微安级一旦射频发射瞬间可能跳到十几毫安甚至更高。这种快速脉冲用万用表测只会得到一个平均到看不出问题的数字。我常用的方法是用示波器加电流探头或者串联一个 1Ω 采样电阻把电压波形转成电流波形。重点观察几个时刻睡眠期间的底噪基线是否平坦有没有周期性尖峰每次射频事件广播/连接的电流脉冲宽度和幅度是否符合预期从 Sleep 醒来后是否有本来可以避免的长时间工作比如外设初始化等了很久、Flash 写入时间过长。还有一种更直接的测法是用超低功耗电流记录仪比如带对数电流记录的仪器用 USB 供电记录 24 小时电流曲线这样可以看到随机唤醒、偶发连接带来的额外功耗到底有多大。我一般把设备放在正常工作场景下连续采集一天再做一次电池续航推算比只看规格书可靠得多。4. 蓝牙协议栈与数据链路设计4.1 GATT 服务结构从能收发数据到能可靠收发数据BLE 应用层开发绕不开 GATT。CH592 的 SDK 里通常已经封装好了 GATT 服务注册接口你需要决定自己的产品暴露哪些 Service 和 Characteristic。以我做温湿度传感器为例设计了三组特征值温湿度数据特征值Notify设备在采集完成后主动通知主机设备信息特征值Read比如固件版本、设备序列号、电池电量控制特征值Write主机下发配置命令比如修改广播间隔、进入深度睡眠、触发 OTA 等。GATT 服务设计时最容易犯的错是特征值属性设置不对。比如主机要接收通知特征值属性就必须包含 Notify同时还要在 CCCDClient Characteristic Configuration Descriptor里使能通知否则主机收不到数据。很多初学者只配置了特征值忘了 CCCD结果手机 App 怎么调都收不到数据。SDK 的例程一般会把 CCCD 逻辑封装好但你自己新增一个服务时还是要确认一遍。数据传输的可靠性也要在设计阶段想清楚。BLE 的 Notification 是不可靠传输主机收到数据后如果想确认最好在应用层加一个简单 ACK 机制。我在产品里是这么做的每次上报数据带上一个递增的序列号主机收到后回一个 ACK 特征值设备如果发现序列号不连续就重传。这套机制看起来笨但对数据可靠性要求高的场景很有效。4.2 广播参数与连接参数功耗和实时性的平衡杆BLE 的功耗控制核心就是广播参数和连接参数。先说广播参数主要有广播间隔和发射功率。广播间隔越短被发现越快但功耗越高发射功率越大覆盖越远但电流越大。默认值往往不是最优值一定要根据产品形态调。以 Beacon 为例如果只是每隔几秒广播一次温湿度数据广播间隔可以放到 500ms 到 1000ms发射功率调到中档兼顾覆盖范围和功耗。如果产品是靠近即连接的交互设备比如门锁广播间隔可以短一点比如 100~200ms因为连接交互的实时性要求高。但这个间隔下长时间广播功耗会明显增加所以还要配合广播超时停止策略。连接参数包括连接间隔、从设备延迟slave latency和超时时间。连接间隔越短主从设备通信越实时但从设备被唤醒的频率越高功耗越大。从设备延迟允许设备跳过多次连接事件而不响应这是低功耗设备最喜欢用的一招。比如主机配置的连接间隔是 30ms从设备延迟设置为 9就意味着从设备最多可以跳过 9 次连接事件只在第 10 次才真正醒来处理数据功耗在实时性要求不高的场景里可以降很多。在 SDK 里这些参数通常在初始化连接参数请求时配置也可以通过 GATT 的一个服务动态修改。我建议产品出厂时编译一套保守参数再在 App 端提供高性能/低功耗模式通过控制特征值动态切换这样一套固件能适配不同用户的需求。4.3 预留调试通道AT 指令和 OTA 设计量产和调试阶段一定要留一个可靠的调试和数据通道。我用的方式是在 UART 上做一组简单的 AT 指令方便产测工具快速配置设备参数。比如ATMAC? 查询设备 MAC 地址 ATBROADCAST500 设置广播间隔为 500ms ATTXPOE-10 设置发射功率 ATSLEEP 进入低功耗模式AT 指令集在开发阶段特别有用因为它不需要专门写上位机程序直接用串口调试助手就能操作设备。到了量产阶段产测工具也可以用这套指令一键完成射频参数配置、MAC 地址校验和功能测试。注意 AT 指令解析逻辑要写得健壮避免因为分包粘包导致解析出错。OTA 升级是低功耗产品必须考虑的。设计固件时把 Flash 分成两个区运行区和下载区。设备收到新固件先写入下载区校验完成后通过标志位切换启动区。OTA 过程要注意功耗整个升级过程要保持连接不能因为链路空闲就强制进入不可唤醒的深睡眠。建议在 OTA 模式下把连接参数调到高速模式升级完成后再恢复到低功耗模式。另外Flash 写入需要内部高压电流会比正常运行高OTA 期间要确保电池电压不会跌破复位阈值否则会变砖。5. 实测与量产阶段的高频踩坑记录5.1 低功耗模式下醒不过来的完整排查链路这个问题我碰到过不止一次而且每次原因都不同。如果你在 CH592 上遇到睡眠后唤醒失败不要急着怀疑芯片坏了按下面的链路一步步排查检查唤醒源配置进入睡眠前唤醒引脚的触发模式上升沿/下降沿、内部上下拉、数字滤波是否配置正确。很多人配置完就忘了结果中断信号来了芯片因为触发模式不对直接忽略。检查引脚复用如果唤醒脚和某个外设引脚复用且该外设还有时钟配置睡眠前外设没有被完整关闭可能造成唤醒信号被外设寄存器吞掉。检查中断标志醒来后如果中断标志没有清除下一次睡眠可能无法进入。处理方式是醒来后第一时间读取中断寄存器并清标志先清标志再恢复系统时钟。检查时钟恢复从 Shutdown 模式醒来系统时钟可能需要重新锁相如果代码在时钟稳定前就去访问外设会导致读到的数据全 0看起来像系统卡死。解决办法是醒后延时或轮询时钟稳定标志。检查看门狗如果用了独立看门狗唤醒后初始化时间过长看门狗会先触发复位表现为睡下去就重启。排查这类问题我建议在唤醒路径的每个关键节点加调试输出正常运行版本再关掉比如唤醒源已触发时钟已恢复GPIO 已复位主循环已继续执行这样能快速定位卡在哪一步。5.2 功耗测量里的幽灵电流是怎么来的有一批板子测出来睡眠电流比整机预算高了 80μA 左右查了很久最后发现是一颗 GPIO 控制的传感器电源 MOS 管在睡眠时没有完全关断。驱动 MOS 的 GPIO 在初始化时是高电平睡眠前代码里关断了传感器电源但没看到代码里把 GPIO 拉低于是虽然传感器被逻辑上关断但电源 MOS 管一直开着传感器芯片的待机电流一路漏出去。这类问题的共性是低功耗是系统级行为不是芯片级行为。锁存性隐患还包括GPIO 配置成浮空输入引脚电平不确定内部钳位二极管产生微漏I2C 总线设备存在但主设备已经睡眠总线上拉电阻继续耗电ADC 采样通道未关闭采样保持电路的等效电阻持续漏电开关电源在轻载下进入脉冲模式产生低频纹波导致射频误唤醒。排查幽灵电流最有效的方法是二分法从电源入口开始挨个断开各功能模块的供电观察电流变化。断开某部分后电流明显下降那个模块就是漏电源。板子小的时候可以拿热成像仪看温度异常点发热的部位往往就是漏电的地方。5.3 射频性能验证不一定要完整暗室也能测出问题量产前的射频测试正规流程是进屏蔽室测发射功率、接收灵敏度和频偏。但开发阶段不可能天天进暗室我自己的快速验证方法是频偏验证把设备设置为连续载波模式或用固定间隔广播用频谱仪看频点是否落在中心频率上偏得多了说明晶振匹配或频偏校准有问题。发射功率验证广播后看频谱仪峰值功率和配置值对比偏差太大说明匹配网络或天线有问题。接收灵敏度验证用一台现成的手机或 BLE 测试仪逐步拉远距离看设备能不能稳定收到连接请求。虽然没有标准灵敏度的绝对数值但同一室内环境下和参考板对比能快速发现天线是否哑火。这里要特别提醒频谱仪不会说谎但测试环境会。在办公室里测的绝对值不能代表量产性能必须在标准传导测试环境或至少半开放环境再验证一遍。另外不同批次 PCB 板材的介电常数有差异天线匹配最好在批量生产前做一次阻抗确认预留的 π 型匹配网络在生产前要固定成标准值不要留下每个人调得不一样的隐患。量产产测固件也很重要。我习惯在产测固件里把射频调到固定广播状态然后产测设备自动读取广播 RSSI同时校验 MAC 地址、固件版本和基本功能。这样做能拦截掉一批晶振不良、天线虚焊、电源不达标的板子出问题的板子修起来也快很多。6. 写在最后的一些实际体会如果只让我留三条经验我会这样总结第一CH592 这类单芯片 BLE SoC 的集成价值只有在系统级低功耗设计做对之后才能真正体现。芯片本身能睡到微安级但你随便一个 GPIO 悬空、一颗传感器忘断电、一个 LDO 静态电流偏大都能把功耗拉回去。第二硬件调试不能满足于功能能跑通。射频和功耗这两项必须用仪表量化验证否则量产阶段一定会集中爆发问题到时候再改 PCB 和天线成本和周期都很难受。第三低功耗蓝牙产品的调试一定要把软件策略和硬件设计放在一起看。比如广播间隔和连接参数调优是软件的事但它直接决定电池能用多久晶振匹配和电源去耦是硬件的事但它直接影响协议栈在低功耗模式下能不能稳定醒来。两头都要有人懂最后才能做出一颗真正让人满意的低功耗设备。我做这颗产品踩过的坑基本都写在前面了。后续如果你也在做 CH592 相关的集成建议先把最小系统板和功耗测量环境搭好再往里面加功能。硬件底子打好了软件和协议栈的调整都是水到渠成的事。