1. 项目背景与方案选型先说结论这次做的是一个基于 CH592 的蓝牙外设项目核心诉求是“稳定连接 低功耗 单芯片搞定”产品形态接近蓝牙 HID 遥控器但里头还顺带跑了一路数据采集。CH592 这个型号在沁恒的蓝牙 MCU 家族里属于集成度很高的一档内置 2.4G 射频、BLE 协议栈、低功耗内核还带了比较丰富的 GPIO 和通信外设因此整体集成方案可以做得非常紧凑。很多人一听到“蓝牙 MCU”第一反应是 ESP32 或者 nRF52832再要么是用 HC05 这种透传模块。我也踩过这几条路。ESP32 性能强但功耗偏大做电池供电的遥控器并不合适nRF52832 各方面都不错但开发环境相对封闭成本也比 CH592 高。HC05 模块倒是简单可它和“低功耗设计”基本沾不上边而且占面积、多一颗物料。CH592 的优势在于它把射频、协议栈、MCU 集成在一个芯片里外围只需要天线匹配和晶振就能跑起来这对小体积产品来说非常关键。从这个项目的实际需求倒推选型标准主要是三条第一是休眠电流要能压到微安级别第二是协议栈要稳定、文件齐全第三是采购和打样要方便。CH592 当前支持 BLE 5.3单芯片方案只需要 3 到 4 颗外围元件就能工作开发资料里甚至有现成的 HID、透传、Beacon 例程直接省去了从零搭建蓝牙协议栈的功夫。当然也不是说 CH592 万能。如果产品需要跑大量 DSP 运算或者要同时支持 WiFi那就应该考虑别的平台。但要是做遥控器、穿戴配件、传感器节点、智能锁、小型数据采集设备这类“蓝牙外设”CH592 这种集成方案性价比非常突出。2. 蓝牙 MCU 集成方案的整体设计2.1 硬件最小系统设计从原理图到天线很多刚接触蓝牙 MCU 的朋友以为画原理图就是“芯片 电源 晶振”三件套实际上天线匹配这部分才是最容易翻车的地方。CH592 的最小系统确实简单但简单不等于可以随手连。以官方参考设计为例射频输出脚需要按参考设计预留 π 型匹配网络位置尽量靠近芯片的 RF 引脚走线长度越短越好过孔数量能少就少。我自己打样时犯过两个比较典型的错误一是天线下方铺了完整的地铜皮导致射频能量被地平面吸走二是把晶振放在靠近天线馈点的地方结果晶振谐波干扰了射频性能实测通信距离直接缩水三分之一。如果你没有矢量网络分析仪最简单保险的做法是严格照抄官方评估板的 PCB 布局别自己发挥等首版验证后再做微调。电源部分要特别注意滤波。蓝牙在发射时瞬时电流可以达到 10mA 以上如果电源纹波太大射频前端的相位噪声会变差导致误码率升高。建议在 VDD 脚旁边放 1uF 和 0.1uF 陶瓷电容并联并且尽量靠近芯片引脚。电池供电场景下最好再加一个低功耗 LDO 或者干脆用纽扣电池直接供电前提是确认芯片工作电压范围覆盖你的电池电压。CH592 的封装有 QFN32、QFN48 等几种QFN32 对于大部分遥控器、信标、传感器节点都够用。原理图里记得把保留引脚例如烧录脚、复位脚的测试点引出来量产烧录和售后维修都方便很多。2.2 蓝牙协议栈与 profile 选择HID 还是其他集成方案里最关键的是选对 BLE profile。不同 profile 决定了数据组织方式、功耗模型、以及和手机/电脑的交互方式。CH592 官方 SDK 里提供了非常多的例程包括 HID Keyboard、HID Mouse、BLE UART、Beacon、心率服务等基本覆盖了常见应用。如果是做遥控器、键盘、游戏手柄这类产品HID 是绕不开的。系统会把你识别成一个标准输入设备不需要安装 App 就能用。HID 例程里面的报告描述符是核心按键数量、组合键、多媒体键都要在这里定义好。我看到不少人在网上搜“蓝牙 HID”“蓝牙键盘”其实一般不是连不上而是报告描述符写得不规范导致主机端只识别了一部分按键。如果你的产品是数据采集、传感器上报、或者自定义透传建议直接用 BLE UART 或者自定义 Service。CH592 SDK 里有一个非常实用的 UART 透传例程它相当于把蓝牙做成了“无线串口”手机端用 LightBlue 或者微信小程序就能直接收发数据。这个方式调试阶段特别省事后续再慢慢替换成自己的协议、加加密和鉴权。需要提醒的是BLE 一次通信数据包长度有限默认 MTU 是 23 字节其中有效负载只有 20 字节。SDK 支持协商更大 MTU但提高 MTU 会略微增加内存占用和协议栈开销不要一股脑把 MTU 调到 512除非你的数据帧确实需要这么大。2.3 与主控/外设的数据通路UART、SPI、GPIO 还是内置 MCU 搞定集成方案另一个要决策的问题是CH592 是当主控用还是当协处理器用这个决定影响整个架构。CH592 本身是一颗 RISC-V 内核 MCU主频不高但跑 BLE 协议栈和简单逻辑绰绰有余。很多场景其实是单芯片方案按键直接接在 GPIO 上传感器接 I2C/SPI数据在 CH592 内部处理后再通过蓝牙发出去。这样省掉了一颗外部主控 MCU成本、面积、功耗都更低。但某些项目会遇到两种情况一是原有系统已经有主控 MCU只是想把数据无线化二是需要跑复杂的业务逻辑、UI 或者电机控制不适合放到 BLE 芯片里。这时 CH592 可以作为通信协处理器通过 UART 或 SPI 和主控对接。最简单的做法是把 CH592 配置成“蓝牙透传”模式主控只发串口数据其他一概不管。我在实际项目中更倾向于用 CH592 做主控尤其是在遥控器这种应用里。因为每次按键唤醒、上报、再睡着的流程如果跨芯片通信不仅要多费电还容易因为握手协议出 Bug。单芯片方案里按键中断直接唤醒 CH592数据拼帧后广播或连接上报整个链路非常干脆。2.4 从模块化到单芯片的集成成本很多人做第一版样品时会用现成模块比如 HC05、SPP 模块或者某些 BLE 模块。模块的好处是上手快但模块通常会引出邮票孔或排针体积大模块上的晶振、天线、屏蔽罩都是成本整体物料价格往往比单芯片方案高出不少。我算过一笔账一个中规模蓝牙模块大概 8 到 15 元而 CH592 单芯片方案加上天线匹配、晶振、阻容整体外围元件成本可能只有模块的一半左右而且 PCB 面积能缩小到原来的三分之一甚至更小。如果你月出货量上到几千片芯片方案的节省非常可观。当然模块方案也有它的价值。懒得做射频调试、工程师对天线不熟、或者项目周期极其紧张时模块就是最稳妥的选择。但如果你希望产品有竞争力、体积可控、功耗可调建议早点切换到单芯片方案。CH592 的射频前端已经集成在内只要 PCB 天线按照参考设计画射频一致性并不难保证。3. 低功耗设计要点芯片、软件、外围的三层减法3.1 CH592 的功耗模式与唤醒路径低功耗设计不是某一个寄存器的功劳而是从芯片模式选择到软件调度到外围电路的综合结果。CH592 提供了多种低功耗模式最常用的是 Halt 模式和 Sleep 模式。Halt 模式下 CPU 停摆但 RAM 保持内容唤醒后可以立即接着跑Sleep 模式关掉更多时钟唤醒时间稍长但功耗更低。设计时要先搞清楚“空闲时”芯片在做什么。如果你只是等按键那就进入最深的睡眠用 GPIO 中断唤醒如果你还保持 BLE 广播那就必须使用支持广播保持的低功耗模式让射频在定时唤醒窗口内发包。CH592 的协议栈支持类似 CM0P 的 sleep 管理机制芯片会在没有任务执行时自动进入休眠定时器到了再醒来处理广播或连接事件。我之前犯过一个非常经典的错以为只要调用了某个“power off”函数就万事大吉结果 GPIO 悬空导致引脚漏电流整体待机电流居高不下。后来才明白低功耗设计第一步是把所有不用的 GPIO 配成输入上拉或模拟输入禁止它们浮空。浮空引脚在 CMOS 输入端会造成不定电平内部电路反复翻转功耗从微安级别飙升到几十微安。唤醒路径也要提前安排好。如果是按键唤醒注意按键按下时产生的电平跳变要能稳定触发 GPIO 中断如果是 RTC 定时唤醒要算好唤醒周期避免唤醒太频繁导致平均电流反而变大。3.2 广播间隔、连接间隔与睡眠策略BLE 的功耗模型非常依赖广播间隔和连接间隔的参数配置。这个部分直接决定你产品“续航是几个月还是一周”。在广播状态下芯片每次发广播包都要拉高电流然后迅速回到睡眠。广播间隔越短被手机发现越快但功耗越高。比如广播间隔 20ms 和 1000ms 相比平均功耗可能相差十几倍。如果你的产品需要快速被搜索到可以用短间隔广播几秒等配对完成后切换到长间隔或停止广播。连接状态下功耗主要取决于连接间隔。连接间隔是主机和从机协商的从机可以请求一个合适的连接间隔但最终主机说了算。比如连接间隔 30ms 意味着每 30ms 就要唤醒一次接收/发送间隔越长越省电但数据延迟也越大。对于传感器请求 300ms 甚至更长的间隔通常没问题对于遥控器或者实时双向控制间隔最好保持在 20 到 50ms 之间。CH592 的协议栈还支持从机发起连接参数更新请求这是一个很实用的能力。产品可以在没有交互业务时自动把连接间隔拉到很长等用户按下按键立刻请求短间隔保证传输畅通。这套动态策略比固定一个间隔高效得多前提是你对协议栈 API 足够熟悉。广播数据的设计同样影响功耗。广播包里包含的设备名、Service UUID、厂商数据等字段越长广播包越长功耗也略高。没必要把一大段广告词塞进广播包设备名短一点、Service UUID 按需放既省电又能降低碰撞概率。3.3 功耗测量与实测数据低功耗做得好不好不能光靠嘴说要用工具测。最土但有效的办法是串联一个万用表测电流不过万用表采样率太低只能看到平均效果看不到瞬态。更理想的是用电流探头配合示波器或者使用高精度功耗分析仪观察广播事件、连接事件的电流波形。我用 CH592 的 HID 例程做了一版测量广播间隔 100ms广播功耗平均在 20 到 30uA 左右连接间隔 30ms 时平均电流大概在 40 到 60uA具体取决于射频窗口时长和 TX 功率。如果进入深度睡眠只用按键唤醒电流可以做到 5uA 以下。拿一个 200mAh 的纽扣电池来算深度待机时间是非常可观的即便算上偶尔的连接通信跑几个月到一年都有可能。测功耗时要注意一个骗人的细节芯片刚上电或者下载程序后是不会立刻进入最低功耗状态的。要等它跑完初始化和第一个广播事件再量“稳定态”。很多网上说“实测电流大”的帖子其实是没等到芯片休眠就开始读数了。3.4 外围电路的功耗减法芯片本身的电流再低如果外围电路一直在漏电整体功耗还是会被拉起来。这里最容易忽略的是 Flash 芯片、传感器、LED、分压电阻和 LDO 的静态电流。我常用的办法是给传感器和 LED 供电串一颗 P 沟道 MOSFET 或者直接通过 GPIO 控制 LDO 的 EN 脚。不需要采样时把传感器供电彻底切断这样传感器不管自身有多少漏电都不影响系统。LED 只在按键反馈或者配对状态指示时点亮平时全部熄灭哪怕待机时只亮 1mA 的灯也会比芯片自身功耗高出几个数量级。电感式升压电路如果空载损耗也很大。如果你的产品用 3.7V 锂电池却要跑 3.3V 逻辑最好直接用低静态电流的 LDO或者用 CH592 的宽电压特性直接电池供电。如果必须用 DC-DC要选择带 PFM 模式、轻载自动降低频率的型号避免在微安级负载下还在固定开关。还有上拉电阻也要算。I2C 总线上拉电阻如果选得太小比如 1k两条线的上拉电流就能把休眠电流吃掉几十微安。在低功耗设计里I2C 上拉可以选 47k 甚至 100k配合软件里的弱上拉既保证通信时序又不至于漏电太多。4. 核心环节实操从开发环境到样例复现4.1 开发环境搭建与基础工程CH592 的开发环境其实比很多品牌更轻量。官方推荐使用 MounRiver Studio IDE这是一个基于 Eclipse 的集成开发环境同时支持 RISC-V 编译和下载调试。也可以选择 Keil实际上沁恒的 WCH-Link 调试器配合 MounRiver 是最稳的组合。SDK 从官网下载后解压目录里包含了 EVT 例程、驱动库、评估板原理图等。我建议第一次使用的人先不要急着改代码而是把官方 EVT 里的“BLE_UART”例程编译、下载、跑通一遍。编译链接时注意芯片型号选择 CH592F 或者 CH592X具体取决于你手上的型号。链接脚本里的 Flash 和 RAM 容量如果选错程序可能无法启动或者跑飞。下载调试用的是 WCH-Link有两种工作模式RISC-V 模式和 ARM 模式。CH592 是 RISC-V 内核插上 WCH-Link 后需要确认 LED 状态正确。如果识别不到芯片多半是接线松了或者下载器模式不对。用 MounRiver 的下载配置选“WCH-Link RV”模式然后再点烧录基本就通了。整个工程里包含了协议栈的静态库应用代码主要关注 main.c 里的初始化、事件回调和外设驱动。CH592 的 API 风格和传统 STM32 很像如果你原来写的是 Cortex-M上手后会有一种“老友重逢”的感觉学习成本不高。4.2 配置一个低功耗 HID 键盘HID 键盘这个场景很能代表“集成 低功耗”的综合需求。具体实现步骤如下从官方 SDK 复制 HID_Keyboard 例程确认 boards 配置里引脚映射正确比如按键接在哪些 GPIO 上是高有效还是低有效。我习惯把所有按键统一接成“GPIO 输入上拉按键另一端接地”这样 GPI/O 平时是高电平按下时变低通过下降沿中断唤醒。在 report 描述符里把键盘按键按标准用法页定义。注意普通按键和媒体键不能混在一个 report ID 里最好分成两个 report。手机或电脑的连接方式可以有两种一是让 CH592 作为从机广播手机直接配对二是支持 HID over GATT但这其实是同一个协议栈已经封装好的你只需要使能对应服务。进入低功耗时要注册按键唤醒功能。HID 例程中的 main 循环会检查是否有按键事件如果没有且系统处于休眠状态CPU 会执行休眠指令。调试时在 main 循环里加一个 GPIO 翻转观察是否还在正常调度。如果按键按下没反应先检查是不是把“唤醒源”配置写漏了。这里有个非常容易踩的坑CH592 的 HID 例程默认可能让你把按键扫描放在一个 10ms 定时器里这会阻止系统进入深度睡眠因为定时器一直有任务。正确做法是空闲时不启动定时器按键中断到来后再初始化扫描扫描完毕立即停止定时器。这样就能保证手离开键盘后芯片进入待机功耗快速下降。4.3 手机/小程序连接与数据传输如果你的产品不是 HID而是需要通过 App 或微信小程序收数据那么数据通道的打通需要关注几个环节。首先CH592 端需要自定义 Service 和 Characteristic并设置相应的读写属性、通知属性。然后在手机端通过蓝牙 API 扫描设备、连接、发现服务、订阅通知。微信小程序蓝牙开发这几年热度一直很高它用的是微信官方的蓝牙接口逻辑上其实和原生 App 差不多。要注意的是小程序必须在 onBLECharacteristicValueChange 回调里接收数据而且 DataFrame 的分包逻辑要提前设计好。如果一包数据超过 MTU需要自己拆包接收端按序号组装。我建议自定义一个简单的帧头 序号 长度 校验字段别寄希望于系统帮你处理分包。我用 CH592 跑过一段传感器数据上报每 500ms 采集一次温度通过 Notify 发给手机。连接间隔设置为 30msNotify 数据长度分别为 20 字节实测没有出现明显丢包。如果要加大数据量开启 DLE 功能协商更大 MTU但要注意调大后 Flash 和 RAM 占用是否够用。调试工具推荐 nRF Connect 或 LightBlue电脑端可以用官方工具或者 Python 的 bleak 库。我习惯先用通用串口工具验证 CH592 的 UART 输出再用 BLE 调试助手观察属性表中的数据变化。一旦发现手机能读到特征值但收不到通知大概率是 CCCD 没有使能也就是手机没订阅通知不是代码逻辑问题。4.4 量产测试与天线匹配量产阶段最容易出问题的不是软件而是射频一致性和装配一致性。每块板子的天线周边元件如果有偏差谐振频率就会跑偏辐射功率下降通信距离变短。所以小批量试产时一定要抽测射频指标最好测试输出功率和接收灵敏度。没有专业仪器也可以用间接方法检验固定一个距离用手机或者主设备统计 RSSI。同一个位置多次测试RSSI 波动在合理范围内说明板子一致性还行如果 RSSI 忽高忽低那就要检查天线焊接、屏蔽罩接地和壳体内金属件的影响。另外纽扣电池供电的产品要注意电池内阻。电池电量不足时发射瞬间压降会拉低芯片电压可能触发掉电复位表现就是“按一下蓝牙断开”。解决方法是加一个足够容量的储能电容放置在电池和芯片电源之间确保大电流瞬间电压不掉太多。5. 常见问题与排查技巧实录5.1 连接不上、频繁断开怎么办这是所有蓝牙项目里提问最多的一类问题。连接不上的原因可以列一长串广播参数设置太激进、设备名冲突、手机缓存了旧的广播信息、天线匹配不好、晶体频率偏了等等。第一步先看手机能不能扫描到广播。如果扫不到检查设备是否在广播状态、广播间隔是否太大、通道选择是否正确。如果扫得到但连不上重点看安全模式和配对方式是否匹配。CH592 的例程默认通常不开启配对绑定如果你改成了“需要配对”手机端可能因为弹不出配对框而一直失败。频繁断开最常见的原因是连接参数更新失败或者主机和从机的连接间隔没协商好。从机请求的间隔如果超出主机允许范围主机可以拒绝但拒绝后如果从机继续反复请求就会导致连接不稳定。我一般会让从机配置一个“保守”的连接参数别一上来就请求 7.5ms 这种极限值。还有一个经历板子工作正常但一到金属外壳里面信号差。这是典型的壳体屏蔽问题需要调整天线伸出区域或者改用外置天线。蓝牙射频设计就是这么现实软件再努力也改变不了物理边界。5.2 广播信号弱、距离短怎么排查距离短不是“调大发射功率”这么简单。CH592 的发射功率有好几档但蓝牙标准本身对最大功率有限制而且功率加大之后功耗也变大。信号弱要从链路预算上看天线效率、接收灵敏度、环境遮挡、摆放方向。我排查信号弱会按顺序做第一确认天线匹配网络元件值是否和参考设计一致第二检查 PCB 天线是否被覆铜或者外壳内的金属件大面积遮挡第三用频谱仪或者另一个接收端测 RSSI 和距离曲线第四看晶振频率是否偏得离谱。很多时候不是芯片不行而是天线周围净空不够。网上有些词条比如“HC05 蓝牙模块连接不上”其实和 CH592 关系不大但思路是通用的先查供电、再查配置、再查配对模式。老一代蓝牙模块用的是经典蓝牙和 BLE 在协议上完全不同。CH592 只支持 BLE不支持经典蓝牙 A2DP/SCO 这类音频流千万别拿它做蓝牙音箱。如果用 CH592 做耳机或音频传输那不是选错 profile 的问题是选错芯片了。5.3 低功耗后唤醒异常、电流下不去唤醒异常的表现通常是按键没反应、需要按两次、或者周期任务不再执行。多半原因是中断配置有问题。GPIO 唤醒要求在休眠前把对应引脚中断使能同时正确设置触发条件。如果你把按键接成低电平触发但唤醒配置却写了上升沿那按下时根本不会唤醒。电流下不去的原因排查顺序是先断开所有外设只留最小系统量芯片本身电流然后逐个接回外设找到是哪个部件把电流拉高。遇到过一个项目是传感器一上电就把 I2C 总线拉死导致芯片休眠时 I2C 引脚持续被外部器件拉低产生电流倒灌。解决方法是给传感器加独立的负载开关休眠前先关电源再进休眠。另外注意程序里尽量不要用 while 循环空转等待某事件那会让 CPU 一直处于活跃状态休眠调度根本没机会跑。改用事件驱动或者定时器中断把等待时间交给低功耗模式。5.4 关于“蓝牙 HID”和“蓝牙定位”的延伸思考周围经常有人问到“蓝牙 HID”和“蓝牙定位”因为它们在工业、个人设备上很常见。HID 我们已经聊了不少简单说就是让设备伪装成键盘鼠标不依赖 App系统自动识别。蓝牙定位则更多用在室内定位、资产追踪它依赖信号强度 RSSI 换算距离也可以通过 AOA 测角实现更精准定位。CH592 做 Beacon 和 RSSI 测距是完全可行的。Beacon 应用只需周期性广播特定格式的数据包手机端根据 RSSI 估算距离。但 RSSI 测距精度有限环境遮挡、人体走动都会造成几米到十几米的波动。如果想做厘米级定位需要额外的到达角算法和阵列天线CH592 并不合适要选带定位引擎的芯片。网上关于“蓝牙广播是在不同信道同时广播还是分时广播”的讨论也很多。BLE 广播实际上是在 37、38、39 三个信道上轮流发送广播包同一个事件在三个信道按顺序广播不是同时。主设备在同一时间只监听其中一个信道所以广播间隔决定了扫描方多久才能抓到一次包。这也是为什么广播间隔太长时手机连接会显得很慢。5.5 热词里的“连接参数”“MTU”“A2DP”都是什么在调试蓝牙时把几个基础概念捋清楚能少踩很多坑。MTU 我之前提过它决定单包数据最大长度连接参数包括连接间隔、从机延迟、超时时间直接影响延迟和功耗A2DP 和 SCO 是经典蓝牙的音频协议用于蓝牙耳机通话BLE 芯片不支持千万别混为一谈。关于“蓝牙模块 AT 指令集”这是早期蓝牙串口模块比如 HC05的命令方式。CH592 不是纯模块没有默认的 AT 固件但你可以自己在协议栈之上实现 AT 命令用来对外配置参数或透传数据。这样既保留了芯片的低功耗与体积优势又兼容了模块时代的调试习惯。如果你做的是需要一个虚拟蓝牙设备、使用 Bumble 这类 Python 库做测试也可以和 CH592 搭配。原理是电脑模拟主机CH592 作为从机通过 HCI 层或者直接用调试工具抓包分析交互细节。这种方式对协议学习很有帮助但不建议作为量产测试手段。6. 经验总结与后续扩展建议这套 CH592 方案跑下来我最大的感受是低功耗从来不是某一个寄存器的开关而是从硬件电路、协议栈配置、应用层调度到量产测试的整体工程。单芯片集成不等于没有门槛但它把很多门槛拉低了不少尤其是对做小体积、电池供电产品的人来说CH592 是一个值得认真考虑的选项。如果你接下来要在这个方案上继续扩展有几个方向很实用一是做多节点组网利用 CH592 的 BLE 连接和广播能力搭建星型网络二是做微信小程序数据上报把传感器数据直接在手机端可视化三是做 OTA 升级利用 BLE 的 notify 和 write 通道实现固件升级省去产线有线烧录的工序。最后分享一个小技巧量产固件里尽量开启看门狗并预留恢复出厂设置的功能。蓝牙设备一旦出现配对信息混乱或者广播参数异常用户最粗暴的办法就是恢复出厂。CH592 的 Flash 空间足够存好几页配置你可以用一个长按按键触发恢复默认值这个功能在产品售后阶段能救你很多次。