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 SoCRISC-VBLE 5.xSDK 配套完善较低大批量、低成本、功能明确的产品Nordic nRF52 系列ARM Cortex-M4生态成熟、文档齐全偏高高端可穿戴、复杂应用、需大量第三方库ESP32-C3 / S3 等 WiFiBLERISC-V / XtensaWiFi 场景主导中等需要 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.3VLDO 后级再放 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 工具链与 SDKCH592 的开发环境和传统 STM32 不太一样。官方主推的 IDE 是 MounRiver Studio配合 WCH-Link 烧录器使用。工程创建直接在 IDE 里选芯片型号SDK 里的例程可以直接导入不用像某些平台那样纠结配置文件路径。如果你以前只写过 Arduino 或者 Keil 环境第一次用 MRS 会稍微不习惯但核心逻辑是一样的配置工程、编译、烧录、调试。国内技术支持响应很快遇到疑难问题发工单或者去官方社区一般都能拿到解决办法。有个建议不要一上来就改例程先原样编译烧录一次确认开发环境没问题。很多工程师一拿例程就狂改最后分辨不出是代码问题还是工具链问题调试成本翻倍。5.2 烧录、调试与日志烧录接口板子上一般引 SWD 四线VCC、GND、SWCLK、SWDIO或者直接用官方调试器连 EVT。量产时可以用串口烧录或者固件升级方案减少夹具复杂度。调试方面BLE 应用光看断点还不够还是要看协议交互。我会配合两种手段串口日志在关键流程广播、连接、断开、收到数据打印状态板子接 USB 转串口线看日志。缺点是要多连一根线某些低功耗测量会被串口芯片漏电干扰。手机 BLE 调试 AppnRF 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剩下的事就是把功耗、连接、稳定性这些细节一点点抠到位。芯片只是工具好的产品都是磨出来的。 
长河君 · 2026/10/30 1:10:25 · 阅读 1.2k CH592蓝牙MCU集成实战：低功耗BLE应用与硬件设计要点
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 SoCRISC-VBLE 5.xSDK 配套完善较低大批量、低成本、功能明确的产品Nordic nRF52 系列ARM Cortex-M4生态成熟、文档齐全偏高高端可穿戴、复杂应用、需大量第三方库ESP32-C3 / S3 等 WiFiBLERISC-V / XtensaWiFi 场景主导中等需要 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.3VLDO 后级再放 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 工具链与 SDKCH592 的开发环境和传统 STM32 不太一样。官方主推的 IDE 是 MounRiver Studio配合 WCH-Link 烧录器使用。工程创建直接在 IDE 里选芯片型号SDK 里的例程可以直接导入不用像某些平台那样纠结配置文件路径。如果你以前只写过 Arduino 或者 Keil 环境第一次用 MRS 会稍微不习惯但核心逻辑是一样的配置工程、编译、烧录、调试。国内技术支持响应很快遇到疑难问题发工单或者去官方社区一般都能拿到解决办法。有个建议不要一上来就改例程先原样编译烧录一次确认开发环境没问题。很多工程师一拿例程就狂改最后分辨不出是代码问题还是工具链问题调试成本翻倍。5.2 烧录、调试与日志烧录接口板子上一般引 SWD 四线VCC、GND、SWCLK、SWDIO或者直接用官方调试器连 EVT。量产时可以用串口烧录或者固件升级方案减少夹具复杂度。调试方面BLE 应用光看断点还不够还是要看协议交互。我会配合两种手段串口日志在关键流程广播、连接、断开、收到数据打印状态板子接 USB 转串口线看日志。缺点是要多连一根线某些低功耗测量会被串口芯片漏电干扰。手机 BLE 调试 AppnRF 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剩下的事就是把功耗、连接、稳定性这些细节一点点抠到位。芯片只是工具好的产品都是磨出来的。