做低功耗蓝牙产品设计芯片选型这一关就能筛掉大半问题。CH592是我在最近几个BLE项目里用得比较顺的一颗国产RISC-V蓝牙MCU它把2.4GHz射频、BLE协议栈和应用处理器做进单颗芯片主打低功耗、高集成和够用的外设资源。这篇文章就围绕CH592的集成方案和低功耗设计展开把我在原理图设计、PCB布局、协议栈开发到功耗实测过程中沉淀下来的要点整理出来给正在评估这颗料或者准备做BLE传感器、HID键鼠、防丢器、智能家居遥控器的朋友做个参考。1. CH592在集成方案中的定位与选型逻辑1.1 芯片能力拆解CH592是一颗国产的32位RISC-V内核蓝牙SoC面向BLE单模应用。我目前项目里用的这一档配置大致是主频几十MHz量级内置数百KB级Flash和上百KB级SRAM集成BLE 5.4协议栈、2.4GHz收发器、12位ADC、UART/SPI/I2C/PWM等常用外设支持GATT、HID、OTA这类典型应用。具体到不同子型号参数会有差异选型时以对应型号数据手册为准不能拿一颗料的宣传页当全家通用配置。在集成方案里CH592最有价值的点是“单芯片”射频前端、链路层、协议栈、应用逻辑都在一颗芯片内跑完不需要再外挂一颗蓝牙模块或者独立MCU。对比经典的“STM32 HC05串口透传模块”做法物料从两颗变一颗功耗从毫安级降到微安级开发也从“发AT指令”变成“直接调BLE API”。这两条路线我都走过体感差距非常大。HC05这种模块适合快速做验证、做课设、做样机但到了量产阶段成本、体积、功耗、一致性全都会成为问题。1.2 选型逻辑哪些产品适合CH592适合的场景非常明确需要电池供电、有周期性上报需求、需要长期低功耗待机的物联网设备比如温湿度计、智能门锁、防丢器、电子价签、医疗贴片还有一类是HID人机接口设备比如蓝牙键盘、鼠标、遥控器、游戏手柄。CH592的资源和协议栈能力做这类产品都算顺手。不太适合的场景也要说清楚。CH592是BLE单模不支持经典蓝牙BR/EDR所以蓝牙音箱、蓝牙耳机这类必须走A2DP播放、HFP通话的音频产品不要选单模BLE芯片。这是另一条技术路线。我见过不止一个朋友在这上面栽跟头以为“蓝牙就是蓝牙”结果样机打样回来才发现根本走不了音频流整个方案推翻重来。做产品选型先分清单模和双模比研究任何细节都重要。还有一个常见的对比对象是nRF52832和ESP32-C3。我整理了一个简表方便大家按项目情况对号入座方案架构协议栈待机特性开发难度适用场景CH592单芯片RISC-V BLE SoCBLE 5.4睡眠电流低支持多种电源模式较低官方IDESDK传感器、HID、遥控器、防丢器STM32 HC05MCU蓝牙透传模块经典串口透传整体毫安级低AT指令即可原型验证、教学实验nRF52832单芯片Cortex-M4 BLE SoCBLE 5.0较低资料丰富中等可穿戴、复杂BLE应用ESP32-C3单芯片RISC-V Wi-FiBLEBLE 5.0相对偏高中等需要Wi-Fi功能的IoT设备这个表很直白如果需要Wi-Fi选ESP32-C3如果追求极低功耗且纯BLE场景CH592和nRF52832都合适CH592的成本和上手门槛有明显优势。做产品没有“最好”的芯片只有“最合适”的架构。2. 硬件设计要点从最小系统到射频链路2.1 最小系统与外设规划CH592的最小系统不算复杂但有几个关键点必须做对。供电范围一般在2.3V到3.6V纽扣电池或LDO都可以直接供电但要注意电源纹波。BLE发射瞬间电流会突然抬升如果电池内阻偏大或者线路压降明显VDD可能跌落轻则影响发射指标重则直接复位重启。我做首版样机时直接用CR2032供电结果一广播就复位后来在电源输入端加了10uF和0.1uF电容组合问题才消掉。这不是玄学去耦电容在射频系统里就是命根子。晶振选择要特别上心。BLE对射频时钟精度有明确要求主晶振建议选32MHz、精度±10ppm以内的产品否则会影响收发灵敏度甚至出现某些手机能连上、某些手机始终连不上的怪问题。想真正做好低功耗32.768kHz的RTC晶振一定不能省。它不只是给RTC计时用的也是芯片进入深度睡眠后保持定时唤醒的关键。RTC晶振的负载电容要按晶振规格书给定值结合PCB寄生电容调整别直接抄个参考设计就量产。调试接口必须留。CH592一般通过SWD调试口连接WCH-Link建议板上至少引出SWDIO、SWCLK、GND、3V3四个点。我吃过亏量产板省掉了调试座结果现场软件问题没法连只能飞线非常痛苦。哪怕量产版不打算调试留几个测试点花不了多少面积紧急时刻能救命。2.2 天线设计为什么2.4G PCB天线必须“接地”很多朋友问“2.4G蓝牙PCB天线为什么要接地”这里要先把概念校准一下天线需要的是完整的“参考地平面”不是让你把地线直接短接到天线馈点上。PCB天线比如板边IFA天线、陶瓷天线的辐射体需要底层参考地形成镜像和回路地平面不完整、被走线割断、或者净空区开得太小天线效率会明显下降通信距离直接缩水一半以上。设计PCB时记住三点。第一天线所在板边要留净空区天线正下方和周围不要铺铜、不要走线很多参考设计会给出精确的keep-out区域抄板时连净空区一起抄。第二射频走线从芯片引脚出来到天线馈点这段要按50欧姆控制参考地连续路径尽量短不要乱打过孔。第三天线旁边不要放金属屏蔽罩、大螺丝孔、电池等金属物件这些都会影响天线匹配和辐射效率。新手做天线不要自己发明。芯片数据手册或SDK里通常有配套的参考天线直接用官方推荐尺寸射频匹配网络也照抄成功率最高。天线这东西形状差一点、净空差一点性能就差很多先用成熟方案把产品跑起来再谈天线优化。2.3 用网分调好匹配网络天线做好之后最好用矢量网络分析仪看射频引脚的S11。CH592的射频输出一般是单端50欧姆后面接π型匹配网络网分调出来的目标是在工作频段内让S11尽量落在-10dB以下能到-15dB更好。史密斯圆图上看到阻抗偏离中心太多就要调整匹配电容、电感的值往中心收。没有网分也有一个土办法板子放固定位置用手机或者另一台BLE测试设备在不同天线方向测RSSI反复换匹配电容值看信号强度变化。虽然精度不高但能抓出非常离谱的匹配错误。等进入量产阶段前建议还是找有网分的朋友或者专业实验室测一轮天线一致性差的产品在产线上很容易出问题。另外提醒一个走线细节射频走线两边放地过孔阵列要克制。很多人觉得过孔越密屏蔽越好结果把微带线参考地打成了筛子阻抗全乱。正确做法是地过孔沿走线两侧均匀放置间距不要小于走线宽度的三倍既能稳定参考地又不会破坏阻抗连续性。3. 低功耗设计从原理到实测3.1 低功耗的本质是“少干活”BLE低功耗设计很多人一上来就纠结“芯片睡眠电流到底是0.3uA还是0.5uA”其实方向有点偏。BLE低功耗的核心逻辑是“时间分片”设备大多数时间在睡觉偶尔醒来发一个包或者响应一次连接事件然后立刻回去睡。把单次射频事件的时间压缩、把广播和连接间隔拉大才是低功耗产品真正的胜负手。用一个例子就能说明白。假设设备睡眠电流2uA广播时平均电流8mA每次广播持续3ms。如果广播间隔是1秒占空比就是0.3%平均电流大致是2uA加上24uA约26uA如果广播间隔缩短到500ms平均电流就涨到约50uA。一颗CR2032电池容量约220mAh理想状态下26uA可以跑将近一年50uA就只能撑半年左右。所以方案初期就要把广播间隔、连接间隔定下来这比纠结芯片手册上的睡眠电流多0.2uA重要得多。3.2 睡眠模式、唤醒源与GPIO状态管理CH592提供多种电源管理状态简单理解就是工作态、空闲态、睡眠态和更深的掉电模式。睡眠态下CPU停住、外设时钟关闭靠RTC、GPIO中断或者BLE射频事件唤醒更深的状态功耗更低但唤醒条件和恢复速度都有取舍。设计初期建议把电源状态机画清楚运行、待机、睡眠、深睡分别由什么条件进入由什么条件唤醒对应哪些外设还带电。这个状态机是低功耗产品的总纲没有它后面全是补丁。实际项目里有一种非常隐蔽的漏电GPIO浮空。芯片进入睡眠后只要引脚配置成浮空输入电平不确定输入缓冲电路就会产生直流漏电。GPIO带施密特触发器输入的引脚抗干扰能力好一些但睡眠时如果电平悬空施密特结构里的输入级一样会漏电。我遇到过一次睡眠电流实测有30多uA排查了很久最后发现是一颗按键检测引脚没有加下拉配置成了浮空输入。处理办法很朴素所有不用的GPIO要么上拉/下拉固定电平要么配置成输出低按键引脚睡眠前也要保证有确定电平。另一个容易被忽略的是外设时钟。很多SDK示例代码把UART、I2C初始化之后就不管了进入睡眠前一定要用接口关闭无关外设的时钟。外设模块即使不工作只要时钟还在跑就有基础功耗。3.3 供电链路与动态电压调节低功耗不只是睡眠电流的事供电链路也要整体考虑。CH592这类SoC用LDO供电可以直接工作但如果输入电压偏高LDO压差乘负载电流就是白白消耗的功率。BLE场景电流通常在毫安级普通LDO损耗一般可以接受但如果你用的是DC-DC供电可以试试动态电压调节这个进阶做法。具体思路是用MCU的PWM、DAC或者I2C接口的数字电位器去微调DC-DC反馈引脚的反馈分压网络从而动态改变输出电压。产品工作状态需要足够电压保证射频性能进入长期待机时可以把输出电压降到刚好维持RAM数据的最低值等唤醒后再升回来。这样能把整机待机功耗再压一截。这个方法可行但要注意反馈网络响应速度和电压跌落对MCU复位的影响所以新项目第一版不建议上这个功能先把基础睡眠功耗做到位再谈进阶优化。3.4 电流预算的实操计算我习惯在画原理图之前先把整机电流预算算完这样能确定电池容量和上报策略。以一个远程传感器上报场景为例事件电流时长周期睡眠2uA剩余全部时间持续传感器采样200uA20ms每5分钟BLE广播8mA3ms每1秒BLE连接事件6mA1ms每100ms按这个参数粗算睡眠贡献约2uA广播部分8mA x 3ms / 1s 24uA采样部分200uA x 20ms / 300s约0.013uA基本可以忽略连接事件6mA x 1ms / 100ms 60uA。平均总电流大约86uA一颗220mAh的CR2032理论上可跑约2500小时。但如果目标是一年就必须把连接间隔拉大到250ms以上同时配合从机延迟来降低保活开销。这个计算结果点出一个很反直觉的现象真正吃掉电池的不是睡眠电流而是射频事件的平均化电流。所以调参的时候优先看广播间隔、连接间隔、事件时长芯片本身的睡眠电流反而是相对次要的变量。4. 软件与协议栈开发从广播到HID4.1 开发环境与工程骨架CH592的官方开发环境是MounRiver Studio基于Eclipse定制配合WCH-Link调试上手成本比很多国产芯片低。SDK提供BLE协议栈库文件和参考工程结构大致分三层应用层、协议栈接口层、驱动层。整体开发模式不是以前那种“MCU裸机 外挂蓝牙模块 串口指令”而是事件回调里写业务逻辑。我的建议是拿到SDK先别急着改代码把官方例程里各类BLE事件回调跑通连接建立、断开、收到Write请求、GATT回调、配对完成等。这些事件是BLE应用的骨架。把例程广播跑起来手机能连上、能读到数据再开始往里面加自己的业务逻辑。很多工程师不适应事件驱动模型总觉得串口指令直来直去好理解。我的经验是把代码里的阻塞等待改成状态机加事件回调时序自然就流畅了。阻塞式延时在BLE工程里很危险容易撞上休眠或射频活动导致协议栈异常。另外正式产品要提前规划OTA固件升级链路。如果SDK支持无线升级和版本回滚保护量产前务必把升级流程走一遍避免出现发货后设备无法OTA只能返厂的尴尬。版本回滚保护这类机制在正式固件里也要设计好防止误刷旧固件导致设备异常。4.2 广播、连接与功耗参数的联动广播数据包是设备未连接状态下的“门面”。CH592 SDK里会有广播配置接口传入广播类型、广播数据、广播间隔等参数。广播数据有两个注意点一是总长度不能超过31字节SDK一般会做校验但自己填数据时要心里有数二是内容结构要为App解析留好设计比如标志字段、设备名称、服务UUID、厂商自定义数据该如何排列。广播数据不是说越长越好越长意味着单次广播时间越长功耗越高。连接参数是功耗的另一把钥匙。SDK里有最小连接间隔、最大连接间隔、从机延迟、超时时间这几项。连接间隔越小交互越频繁功耗越高从机延迟slave latency允许从机跳过若干次连接事件而不必每次都响应是低功耗产品必须掌握的参数。比如连接间隔设为30ms从机延迟设为4从机等效每150ms响应一次功耗能降一个量级。代价是上报实时性降低所以具体值要看场景。做HID键鼠这种需要快速响应的设备连接间隔就不能拉太大做温湿度传感器从机延迟拉高完全没问题。4.3 BLE HID键盘参考实现HID over GATT是BLE上非常典型且实用的应用服务UUID是0x1812CH592提供了完整支持。做蓝牙键盘、鼠标、遥控器、游戏手柄都走这条路。整体实现分几步在GATT表里添加HID服务包括HID信息特征、报告映射特征、报告特征、协议模式特征构造符合HID规范的报告描述符每次按键变化时通过GATT通知把输入报告发给主机。最容易翻车的是报告描述符和报告特征的长度配置。做普通键盘时输入报告通常是8个字节修饰键、保留位、6个按键码。但如果你要加多媒体按键、音量控制报告结构就要扩展。主机通过报告映射来判断报告含义结构不对主机端要么识别不了设备要么键位错乱。调试HID设备时不要只在Android上测Windows、macOS都要跑一遍各主机对HID描述符的兼容性差异很大。键鼠产品对低功耗要求很高CH592正好对口。待机时进深度睡眠按键通过GPIO中断唤醒再重新建立或恢复连接。这里提醒一点HID设备的配对信息要妥善保存。很多用户遇到“鼠标删除后再搜索搜不到”的问题本质是设备端保存了旧配对信息主机删除后重新配对时双方密钥对不上设备需要先清掉bonding信息再重新广播。在固件里做一个“长按清配对”的隐藏功能能帮客服省很多事。4.4 测距与定位的轻量玩法这些年蓝牙测距的热度一直不减从RSSI粗略测距到高精度测距方案都有讨论。CH592做RSSI测距是可行的原理是根据接收信号强度反推距离。常用的对数路径损耗模型d 10^((TxPower - RSSI) / (10n))其中TxPower是1米处的参考接收功率n是路径损耗指数空旷环境接近2室内通常取2.5到4。实际用RSSI测距最大的问题是环境不稳定多径效应会让RSSI抖动很大。我的处理方法是先做滑动平均滤波再用多个信标交叉定位精度做到米级可以适合防丢器、区域判断、存在性检测这类场景。广播包里记得带上TxPower字段接收端才有校准依据。如果是要求厘米级精度的场景得换支持新测距机制的方案RSSI这条路走不通。5. 实战中遇到的高频问题与排查思路5.1 手机搜不到设备手机APP搜不到广播设备是BLE开发里出现概率最高的问题。我推荐按这个顺序排查先确认板子在跑、没有意外进睡眠再确认广播函数返回成功广播间隔不是异常值然后直接用手机系统蓝牙设置页搜看系统里能不能看到设备名用来区分是系统问题还是APP过滤问题。Android上很多APP搜不到设备是因为没申请位置权限这属于系统权限问题别对着设备端代码瞎改。设备端常见的坑是广播数据超长或广播类型配置冲突。有的SDK把广播数据和扫描响应数据分开配置填错位置广播直接失败。排查这类问题时接上WCH-Link看日志同时用手机BLE调试工具观察空中包两边对照很快能定位。5.2 实测功耗高得离谱如果睡眠电流实测是几十微安甚至毫安级按优先级检查GPIO是否浮空、外设时钟是否关闭、板载其他芯片是否有漏电路径、指示灯和电平转换电路是否有常通回路。很多“睡眠电流降不下来”的问题最后都出在外围电路而不是MCU本身。比如一颗指示灯串了1k电阻睡眠时只要电平是高电平就有3V/1k3mA的电流这比MCU睡眠电流大三个数量级。测功耗的方法也要讲究。用一个普通万用表测动态平均电流没问题但如果看到数值跳动很大建议用带记录功能的仪器或串一个采样电阻用工装看电流波形。BLE电流是脉冲式动态变化的瞬时峰值和平均值的差距非常大凭一次读数判断功耗容易误诊。5.3 通信距离短或连接容易断距离短先怀疑天线和匹配不是协议栈问题。固定软件不变硬件调整前后对比RSSI就能判断是天线问题还是环境干扰。另一个容易忽略的点是晶振频偏32MHz晶振精度不够收发频点偏了距离和稳定性都会变差低温下尤其明显。连接容易断开还要看连接超时时间和从机延迟的配合。有些主机侧为了避免长时间失联设置了较短的连接超时从机如果唤醒不及时就会掉线。5.4 系统侧蓝牙小问题的通用处理开发过程中大量时间花在和各主机系统蓝牙“毛病”打交道。比如Windows下删除蓝牙设备失败、蓝牙显示已关闭但重新打不开、网卡自带蓝牙搜不到设备等。这些大概率是系统蓝牙驱动和缓存问题。通用处理办法是在设备管理器卸载蓝牙设备并重新扫描驱动或者清除系统蓝牙缓存后重启蓝牙服务。做键鼠产品遇到用户反馈卡顿先排除干扰和使用环境因素再看固件上报频率是否合理。调试自己的产品时配合BLE抓包工具分析空中包非常有用。选抓包工具时注意要支持BLE 5.4的新特性否则一些扩展广播和编码PHY的数据解不出来。抓包建议只过滤自己的设备地址方便定位问题。5.5 几条踩坑经验最后分享几条我个人长期实践沉淀下来的经验。第一不要过度追求芯片手册上的参数下限实际产品的功耗瓶颈往往在容易被忽略的细节上GPIO浮空、外围器件漏电、连接参数太激进这些都要在项目初期统一规划。第二所有GPIO要统一管理画原理图时就标清楚每个引脚的默认电平策略和睡眠状态别等软件写完了再回来补。第三射频部分的PCB改动不要并行每次只动一处变量才能准确判断影响。这些道理看起来简单但我在多个项目里真真切切花过几周填这些坑。做一个稳定可靠的低功耗BLE设备基本功永远比花哨技巧重要。
在NLP中的实战应用与优化)
