简介：面向蓝牙嵌入式开发者与物联网爱好者的PB03模块二次开发资料包已打包发布，覆盖安信可PB-03蓝牙5.2模块基于PHY6252 SoC的完整开发链路。资料面向有单片机基础、希望快速上手低功耗蓝牙产品研发的读者，可解决环境搭建、固件升级、外设驱动与应用移植等常见问题。包体共1163个文件，约66.23MB，以C/H源码工程为主，配合uvprojx等Keil工程文件、sct链接脚本、bat批处理、lib库以及pdf说明文档和hex固件，可支撑从编译烧录到调试验证的完整流程；同时包含OTA升级工具APK与相关配置文件，便于直接开展BLE5.2透传与FOTA测试。目前已有2235人学习下载。资料中既提供PHY6252的SDK源码、参考例程和Windows开发环境，也整理了通用AT指令、多种休眠模式、射频性能参数等说明文档，目录包含多个示例工程与工具脚本，适合作为PB03项目开发的起始模板和排错手册。 PB03这块芯片，最近在IoT圈子里的讨论度确实不低。尤其它把蓝牙5.2、低功耗、低成本这几个点集齐了之后，很多人拿它做透传模块、智能家居网关、便携设备的数据上行通道。我去年也基于PB03完整走过一轮从SDK熟悉、demo修改、到自定义服务开发的流程，说实话，网上关于它二次开发的资料比较散，官方文档虽然全，但缺少一个面向开发者的“串讲”，所以这篇把我自己的实操记录和踩坑经验整理出来，希望能给你提供一条更快上手的路径。
1. 项目需求与整体设计思路拆解
1.1 PB03蓝牙5.2到底适合做什么
先把这个芯片本身的定位看清楚。PB03是奉加微电子（PhyPlus）推出的一款低功耗蓝牙SoC，核是Cortex-M0，主频在64MHz左右，集成蓝牙5.2协议栈，支持2Mbps、LE Coded PHY、扩展广播这些特性。片内Flash和RAM虽然不算大，但跑一个标准的BLE从机应用绰绰有余。关键是它外围接口够用，UART、SPI、I2C、PWM、ADC、多路GPIO基本都带，这意味着你不需要额外挂一颗MCU，直接用PB03就能搞定传感器数据采集、透传、IO控制这类典型场景。
从蓝牙5.2这个版本看，它最实用的提升在于低功耗特性更完善了，包括LE功率控制、增强型ATT等。实际项目中，我用PB03做了一款小型温湿度采集终端，广播间隔拉到200ms，连接间隔跑在30ms左右，用纽扣电池供电，实测平均电流能控制在十几微安级别，这个表现和同级别的nRF52810其实在一个水平线上，但成本和供货稳定性上PB03有自己的优势。
1.2 二次开发的两条路线：AT指令还是SDK
说到“二次开发”，很多人会先糊涂：PB03到底是用AT指令还是写代码？两条路都存在，取决于你要做什么。
如果你只是需要一个“串口进、蓝牙出”的透传通道，那直接用官方AT指令固件就行，MCU侧只管发串口数据，PB03帮你完成蓝牙链路的维护。这种方式开发周期最短，但灵活度有限，比如你没法自定义GATT服务、没法直接控制广播数据格式、没法在芯片内部做本地逻辑处理。
反过来，如果你要做的是有特定服务、特定交互逻辑的产品——比如自定义一个电量上报服务、远程控制多路IO、本地传感器数据预处理——那就得走SDK二次开发。这也是我这次分享的重点：PB03在SDK层面把协议栈封装好了，你不需要关心蓝牙底层链路细节，只需要基于它的应用层模板去改自己的业务逻辑。这种“半裸露”的开发方式，对应用工程师来说最友好，既能保留定制能力，又不用啃协议栈源码。
1.3 为什么值得做SDK级定制而不是纯AT指令
我自己的项目最开始也想偷懒用AT指令，结果发现要做多服务、多特征值、还带安全加密的交互，AT指令根本绕不动。AT指令适合“MCU主控+蓝牙从机”的架构，但代价是每一条指令都要过串口，交互效率低，而且很多底层能力暴露不出来。
SDK二次开发生态上，PB03官方提供了完善的例程，从最基础的peripheral模板到基于RTX操作系统的复杂工程都有。拿到手改起来其实很快，核心工作无非是：改广播内容、改GATT服务、改回调处理逻辑。这篇文章后面的部分，我会带着你把这一套流程完整走一遍。
2. 核心细节解析与实操要点
2.1 SDK目录结构与关键文件
先花点时间把SDK的目录结构看明白，这比急着编译demo重要得多。以官方PhyPlusKit及配套SDK为例，工程里几个关键目录是：
app/：存放应用层代码，包括main函数、用户任务、外设驱动初始化都在这里改。driver/：芯片外设驱动，类似于STM32的标准外设库，所有外设操作都从这里调API。lib/：协议栈库文件，蓝牙协议栈已经编成静态库了，你不需要也无法修改它。profile/：GATT服务和特征值的定义，自定义服务主要在这个目录或者直接在app里调用API添加。
还有一个容易被忽略的地方是platform/，里面是芯片底层的时钟、电源管理等配置。遇到休眠功耗异常，十有八九问题出在这里而不是你的业务代码。
2.2 初始化流程：从main函数到蓝牙广播
跑起来一个demo之后，我建议你顺着main函数的调用链捋一遍，把整个启动流程弄清楚。核心逻辑大概是：系统时钟和电源初始化 → 外设驱动初始化（串口、GPIO等） → 协议栈初始化并注册回调 → 配置广播参数 → 启动广播 → 进入主循环或RTOS调度。
这个过程中，最容易踩坑的是协议栈初始化的顺序。比如你必须在启动广播之前把GATT服务添加完毕，否则手机端扫不到你自定义的服务。很多新手在这里出错，表现就是“程序能跑，但手机连接后服务列表里啥都没有”。
下面是一段精简的例程逻辑，展示了核心顺序：
int main(void) { // ... 系统时钟、GPIO、外设初始化 // 1. 平台初始化，内部会完成蓝牙协议栈的底层配置 platform_init(); // 2. 注册BLE事件回调（连接、断开、收到写入等） ble_event_callback_register(app_ble_event_handler); // 3. 初始化并添加GATT服务（必须在广播前完成） app_add_custom_service(); // 4. 配置广播数据+扫描响应数据 update_advertising_data(); // 5. 设置广播参数并启动广播 ble_advertising_start(); // 6. 进入主循环，处理低功耗和事件 while(1) { app_main_task(); } }2.3 自定义GATT服务的添加逻辑
如果你要做的是非标准服务，那就需要自己定义服务和特征值的UUID。在PB03的SDK里，通常是通过一个服务注册回调，把特征值数组传给协议栈。这里要说一个关键点：所有特征值需要一个回调函数集中处理读写事件，代码里会对event_type做switch-case分发，写业务逻辑时别在回调里做耗时操作，否则会影响协议栈响应。
实际项目中，我添加了一个“设备信息上报服务”，里面放了三个特征值：温湿度数据、设备状态、控制指令。数据采集在主循环里做，采集完成后主动通过ble_server_send_notify或ble_server_send_indicate推送给手机端。控制指令则是在回调里解析，然后去翻转对应的GPIO。
过程中要注意的是：如果数据长度超过20字节，需要和手机端约定好分包策略，因为BLE单个通知包在传统ATT MTU下最多承载20字节有效数据。虽然可以通过协商MTU扩展到更大，但接收端APP如果不支持，仍然只能按20字节处理。
2.4 广播数据格式与功耗的权衡
广播数据的配置直接关系到手机端能不能快速识别你的设备。PB03的例程里会给你一个默认的广播包，包含设备名称和厂商自定义字段。这里有三个参数你需要重点关注：
- 广播间隔：100ms时设备发现快，但功耗高；1s时功耗低，但手机扫描到设备会慢。折中方案是快广播+慢广播的组合。
- 广播类型：可连接非定向广播是大多数外设的选择，低功耗模式下可以用不可连接广播只做信标。
- 扫描响应数据：手机端发扫描请求时才会回传，适合放大块厂商数据，不影响普通广播的功耗。
实践下来，我建议动态调整广播间隔：上电后前30秒用100ms快速广播方便配对，连接建立后停止广播，断开后重新进入快速广播。这样既兼顾了用户体验，又把日常功耗压到了极低。
2.5 工具链与辅助分析手段
二次开发调试时，除了串口打印，强烈建议你用nRF Connect或者LightBlue这类手机App做蓝牙空中抓包和数据交互验证。可以查看设备广播包、扫描响应、服务表、特征值、甚至直接读写和订阅通知。
还有一个容易忽视但非常有用的手段：启用协议栈日志。PB03的SDK里可以打开协议栈调试输出，能看到蓝牙链路的连接事件、加密状态、MTU协商结果。遇到连不上、老是掉线的问题，这些日志会让你少走很多弯路。实测下来，排查连接异常时，日志比逻辑分析仪还能说明问题。
3. 实操过程与核心环节实现
3.1 开发环境搭建与编译烧录
我开发时用的是官方PhyPlusKit烧录工具和配套SDK，编译工具链用的是arm-none-eabi-gcc，也可以用IDE版本，看个人习惯。在Windows上操作，步骤如下：
- 安装PhyPlusKit工具，它会自动安装烧录驱动。
- 获取PB03的SDK压缩包，解压到工作目录，不要有中文路径，避免编译出错。
- 命令行进入
project目录，执行编译脚本（或者用IDE导入工程编译）。 - 编译生成固件后，连接烧录器，在PhyPlusKit中进入ISP模式，加载固件，擦除并烧录。
- 烧录完成后复位芯片，手机App扫描验证广播名称。
第一次烧录有个细节需要注意：芯片进入ISP模式的方式是上电前拉低特定引脚，不同开发板标识不一样，最好确认一下原理图。有些情况下，拔插USB并不能自动进入ISP模式，需要在PhyPlusKit中点“连接”，再给目标板上电，掌握好这个上电时序基本就不会失败了。
3.2 修改广播名称与设备过滤
先做一个最简单也最有成就感的实验：修改广播名称。SDK例程里通常有一个数组存放广播数据，其中包含设备的短名或完整名称。你需要把设备名前缀的字节长度改掉，再把新的名字按ASCII填入。
有个很阴间的坑：广播包里的设备名如果超过一定长度，会被拆分到扫描响应数据里。手机端可能看到两个不同的设备名，或者名称显示不完整。解决办法是把短名称放进广播包，完整名称放到扫描响应包。如果你只改广播包里的名称而不处理扫描响应，手机端可能出现“扫描到但名称不变”的诡异现象。
我实际改完后的扫描结果，设备名称能正常显示“MyPB03_Dev”，广播间隔200ms，手机端在零距离扫描时间大约在几十毫秒内，符合预期。
3.3 串口打印与调试信息输出
调试过程中，串口打印是最重要的信息出口。PB03 SDK里通常把printf重映射到了某个UART口，默认波特率在工程配置里定义。我的配置是：
// 串口初始化在platform或者外设驱动里配置 uart_init(UART_0, 115200, UART_TX_PIN, UART_RX_PIN);然后工程里会有类似这样的宏定义：
#define DEBUG_LOG(fmt, ...) printf("[PB03] " fmt "\r\n", ##__VA_ARGS__)用这个宏替代裸printf的好处是，调试信息会统一带前缀，后续量产时只要关掉一个宏就能全部静默，不需要满代码去删打印。
启动日志我建议至少打印这些内容：系统版本、SDK版本、设备MAC地址、广播是否启动、连接事件、断开原因。尤其是断开原因，很多莫名其妙的掉线问题都能从协议栈返回的错误码里找到线索。
3.4 我的实际项目：温湿度计BLE上报
把以上知识点串起来，说一下我做的温湿度计项目。硬件上，PB03通过I2C读取SHT30传感器数据，板上有一颗LED做状态指示，按键用作触发立即上报。
代码逻辑是：
// 读取SHT30温湿度 sht30_read(&temperature, &humidity); // 组装数据包，格式：类型(1Byte)+温度(2Bytes)+湿度(2Bytes) uint8_t report_data[5]; report_data[0] = 0x01; report_data[1] = (uint8_t)(temperature_int >> 8); report_data[2] = (uint8_t)(temperature_int & 0xFF); report_data[3] = (uint8_t)(humidity_int >> 8); report_data[4] = (uint8_t)(humidity_int & 0xFF); // 通过Notify特征值推送给手机端 ble_server_send_notify(service_handle, char_handle, report_data, 5);手机端用nRF Connect订阅该特征值的Notify，每5秒能收到一次实时数据。按键按下时，也会主动触发一次上报，用于测试低功耗模式下手动唤醒链路是否正常。
功耗测试结果让我比较满意：全速运行时约2.3mA，连接但无数据时约20µA，睡眠深睡态下约0.8µA，平均取决于上报频率。如果你的项目对功耗有硬指标，建议把传感器也做成间歇供电模式，采集时再上电，能省一大截电流。
4. 常见问题与排查技巧实录
4.1 烧录失败的典型场景
PB03烧录失败的现象通常有几种：PhyPlusKit报“连接失败”、烧录进度条卡住、烧完之后设备无法启动。逐个排查：
- 连接失败：先检查ISP引脚状态，目标板如果已经跑起了应用程序，有些引脚被复用导致ISP模式进不去，需要长按复位再试。
- 进度条卡住：多为串口线路不稳定，或者目标板供电不足，换一根好的USB线，外接稳定电源，多半能解决。
- 烧完无法启动：SDK版本和烧录工具版本不匹配，或者固件地址不对，回到出厂demo重新验证。
烧录这事看似简单，但连线质量差会严重浪费时间，建议直接买个官方调试底座，省下的时间足够回本。
4.2 编译和链接阶段的异常处理
新手最容易卡在编译阶段。如果你在Windows命令行里用make编译，先确认环境变量里能找得到arm-none-eabi-gcc。常见报错：
arm-none-eabi-gcc: command not found：环境变量没配好，把工具链bin目录加到PATH。undefined reference to ...：有源文件没参与编译，或者链接脚本里面缺了库文件。No space on device：Flash或者RAM超了，精简代码，关闭不必要的调试打印和协议栈特性。
在SDK工程里，各功能模块是通过宏开关控制的。比如你用不到安全管理、用不到多连接，就把对应宏关掉，既省Flash又省RAM，还能降低功耗。
4.3 手机连不上设备，怎么排查
手机扫描不到设备时，按从软件到硬件的顺序排查：
- 确认广播真的在发，用另一个手机或抓包器看空中数据。
- 检查广播类型，如果改成了不可连接广播，手机当然没法连接。
- 检查设备是否已经处于连接状态，单连接芯片连了一个设备后，通常不会再广播。
- 检查硬件天线匹配，PCB天线如果离地、或者参考层切开，信号强度会急剧下降。
如果“扫描得到、连不上”，重点看广播数据里的连接间隔参数，以及协议栈是否允许从机发起连接参数更新请求。部分旧手机对连接参数宽容度低，可以从机侧主动把间隔调整为30ms~50ms的常见档位。
4.4 功耗偏高的排查思路
很多人的低功耗设备实测电流比理论值高一个数量级，通常跑不出这几个原因：
- GPIO悬空：未使用的GPIO没配置成输入下拉或者输出低电平，悬空脚导致漏电。
- 外设未关闭：传感器、LED、SPI Flash这类外设在进入睡眠前没断电。
- 协议栈仍处于活动状态：广播没停，或者定时器频繁唤醒。
- 调试口在输出数据：串口如果开着且不断打印，功耗自然降不下来。
其中GPIO悬空是最隐蔽的坑，项目实测中，一个悬空的GPIO可能导致漏电流增加十几微安，对纽扣电池供电的产品来说影响很大。
4.5 量产阶段容易忽略的几点
如果项目准备量产，下面几个问题建议在产品定型前就考虑清楚：
- MAC地址管理：PB03支持自定义MAC地址，量产出货前建议用工具统一配置MAC号段，方便售后追踪。
- 固件升级方案：如果产品要OTA，需要提前在Flash规划里预留Bootloader和App分区，否则后期改动成本极高。
- 产测流程：功能测试至少覆盖“广播正常”、“功耗达标”、“传感器上报正确”这几项，效率最高的方式是设计一个专门的产测固件和一台产测治具。
我当时就是在量产阶段才发现MAC地址全是一样的，被迫加班写了个批量配置工具，那个教训记忆犹新。
5. 最后再分享几个容易被忽略的细节
如果你手上有PB03的开发板，我建议先别急着写业务，把官方例程完整烧一遍，尤其是那个带RTOS的例程。因为PB03的很多应用都是基于RTOS的，任务优先级、消息队列、事件标志这些机制不提前熟悉，后面做复杂业务时会被各种“不按预期执行”折磨到怀疑人生。
我喜欢PB03 SDK的一个点是它的回调机制写得很干净，基本上所有事情都是事件驱动，没有乱七八糟的全局状态。只要你遵循它的套路，代码维护起来非常舒服。但这也意味着你的业务逻辑必须拆散到各个回调里，不要试图用一个大循环去轮询所有状态。
如果做的是数据采集类产品，再提一句：写Flash要慎重，PB03的内部Flash擦写次数有限，高频日志记录不要直接写Flash，建议外扩一颗SPI NOR Flash或者走蓝牙直接上行到网关。
最后，动态修改广播数据其实是个很好用的技巧。比如设备可以广播当前电量、设备状态、甚至传感器读数，这样手机端即使不连接设备，也能在扫描列表里看到关键信息。苹果和安卓对广播数据的解析方式有差异，做跨端产品时建议同时用两个系统的手机实测一下。
本文还有配套的精品资源，点击获取
