企业官网建设流程全解析

这块板子我拿到手第一反应是：Microchip终于把PIC32和蓝牙凑到一块儿了。以前做蓝牙产品，要么用8位MCU挂个HC-05，要么直接上nRF52重新学一套工具链，两种路子都别扭。PIC32 Bluetooth Starter Kit算是给PIC32老用户开了一条顺路的蓝牙开发通道，不用换平台，不用啃陌生的SDK，用熟MPLAB的人基本半天就能把第一个BLE透传跑起来。这篇就说说我在这块板子上从拆封到跑通实测的完整过程，包括踩过的坑、试错的经验，以及蓝牙开发时最容易忽略的几个细节。

本文适合的手头情况：有一点PIC32或MPLAB基础，想快速评估Microchip蓝牙方案；或者在嵌入式平台上做BLE透传、蓝牙串口调试、GPS数据无线输出这类项目，想找一个“MCU+蓝牙模块”快速验证路径的工程师。如果你完全没摸过MPLAB，也没关系，下面环境和配置部分我都会说得细一点。

1. 板卡硬件拆解：这块套件到底塞了哪些东西

1.1 主控选型：PIC32MZ2048EFH144到底强在哪

套件核心是PIC32MZ2048EFH144这颗MCU，144引脚封装，Cortex-M系列之外少见的MIPS内核。这颗芯片主频能跑到252MHz，2MB Flash加512KB RAM，在Microchip的32位产品线里属于中高端定位。对蓝牙应用来说，这个规格其实是“过剩”的——BLE协议栈在模块里跑，PIC32只负责应用逻辑，所以真正用到的资源不会太多。

但资源多有个实际好处：你可以同时在板子上跑USB调试、FAT文件系统、简易GUI或传感器融合算法，不用像8位MCU那样抠Flash。我做蓝牙GPS记录仪的时候，除了蓝牙透传，还要在本地记日志到SD卡，PIC32MZ的2MB Flash用来缓存数据完全够用，这在PIC16F上想都不敢想。

1.2 板载蓝牙模块：BM70的定位和连接方式

板子上的蓝牙部分用的是Microchip BM70模块，支持Bluetooth 4.2 BLE（部分型号兼容BR/EDR），板载天线，走UART或者BSC接口。这块模块出厂就烧好了协议栈，对外提供透明的串口数据通道，你不需要了解BLE的GATT、ATT这些细节，只要按协议发AT命令配置，然后像操作普通串口一样收发数据就行。

这里有个关键认知：BM70是一只“蓝牙黑盒”，不是让你在模块内部跑应用代码的可编程方案。它的工作就是负责把串口数据变成BLE通知（Notification）发出去，再把手机发来的写请求变成串口数据吐出来。相比nRF52那种“全可编程BLE SoC”，BM70的优势是开发快、不需要处理蓝牙协议细节，劣势是灵活度低，没法自定义很复杂的GATT服务（当然大部分场景用默认服务就够了）。选型时你要先想清楚自己要的是“快速出透传”还是“深度定制协议”。

1.3 板载外设和扩展接口

除了主控和蓝牙模块，板子上还有RGB LED、两个机械按键、USB接口（可作串口或调试口），以及两个 mikroBUS 扩展插座。mikroBUS这个设计挺实用，可以直接插Microchip自家或者第三方Click board，比如GPS Click、温湿度Click，我后面做GPS输出实验就用了一块GPS Click插上去，免了飞线。

扩展接口需要注意供电。mikroBUS的3.3V和5V引脚都是板子上的LDO输出的，如果外接的Click board功耗稍大，建议外接电源，别全靠USB口供电。我试过同时插GPS Click和WiFi Click板载供电就有点吃紧，蓝牙偶尔会出现连接不稳定的现象，后来改外接5V供电就好了。

2. 环境搭建中最容易翻车的几个环节

2.1 MPLAB X IDE与XC32编译器的版本匹配

先说结论：务必使用MPLAB X IDE v6.x以上搭配XC32 v4.x，如果还在用老版本的MPLAB X 5.x，Harmony 3的很多组件会加载失败。这个匹配问题是我第一次搭建环境时遇到的最大坑，因为Microchip官网的下载页会把IDE和编译器分开，新手容易各装各的，结果代码生成后编译报一堆莫名其妙的错误。

一个更稳妥的办法是安装MPLAB X IDE后，在工具选项里通过“Plugins”下载Harmony 3 Launcher，然后在IDE内直接创建Harmony工程。我实测下来，这种方式自动匹配的版本组合比自己手动下载靠谱得多，至少减少了90%的版本冲突问题。

2.2 XC32编译器路径与License

XC32编译器安装时会让你选License类型，有免费版和评估版。免费版不开优化，但对学习开发足够。注意安装完成后要在MPLAB X里设置编译器路径：Tools > Options > Embedded > Build Tools，如果编译时报“找不到xc32-gcc”，基本就是这里没配对。

我遇到过一次奇怪情况：编译器路径显示正常，但编译报错说“Invalid compiler”。最后发现是XC32装了32位版本，而MPLAB X是64位，路径指向混乱了。卸载后统一安装64位版本解决。建议遇到编译器怪问题时先统一位数再排查别的。

2.3 Harmony 3配置器的组件加载

Harmony 3（MCC）是Microchip现在的图形化配置工具，用来生成外设初始化代码。BLE应用通常只需要配置UART和GPIO，理论上很简单，但MCC有个毛病：首次加载组件库需要联网下载，网络不好时会一直转圈。我的建议是直接去GitHub或者Microchip官网下载Harmony 3完整包，本地解压后再在MCC里指定路径，这样加载组件几乎秒开。

配置UART时要注意，BM70的默认串口参数是115200、8N1。如果你在MCC里把波特率设成9600而不修改模块配置，手机端会收不到任何数据。这个“两边波特率不一致”的问题每个人基本都会遇到一次，后面专门细说。

2.4 电脑端蓝牙驱动的特殊情况

开发过程中我经常会用电脑的蓝牙连BM70做调试，Windows 10和11自带蓝牙协议栈，但对某些USB蓝牙适配器，系统有时显示“Generic Bluetooth Radio”而不是具体型号，这种情况下使用串口服务（SPP）或BLE的虚拟串口可能不稳定。

解决方法就是打开设备管理器，把蓝牙设备更新为官方最新驱动，或者用芯片原厂（CSR、Realtek、Broadcom）的驱动包。我自己用的是一个老款CSR 4.0适配器，装完官方驱动后连接稳定很多。如果你在用“Generic Bluetooth Radio”状态下连接失败，多半不是板卡问题，而是电脑端驱动和协议栈匹配不够好。

3. 蓝牙协议栈跑在哪一端：搞懂BM70的工作模式

3.1 BM70是“蓝牙黑盒”还是“可编程SoC”

很多初学者会误以为蓝牙Starter Kit里的BM70模块和nRF52一样，能在模块内部跑代码，其实不是。BM70内部确实有一颗CPU和协议栈固件，但你无法在模块上编译烧录自己的应用代码，它只提供两种操作模式：命令模式和数据模式，以及HCI透传模式（用于外接主机跑协议栈）。大多数情况下我们用的是前两种。

理解这个架构很重要：BLE连接的所有核心逻辑，包括广播、扫描、连接参数协商、服务发现、加密配对，全部是BM70内部的协议栈固件自动完成的。你做的事情只是通过AT命令做一次初始配置（设备名、广播间隔、连接间隔等），然后数据就像串口一样流进流出。用久了你会发现，它更像一个“无线串口模块”，而不是一个“可编程蓝牙SoC”。

3.2 命令模式与数据模式的切换机制

BM70上电以后默认处于哪个模式，取决于模块的配置引脚状态和AT命令里的设置。默认情况下，模块上电后处于数据模式，可以直接透传。要进入命令模式，常见做法是通过串口发送特定前缀（比如$$$），或者拉高/拉低某个GPIO引脚进入。这块Starter Kit板上有对应的引脚通过跳线连接，查看原理图就能确认。

我实际测试中比较推荐使用GPIO方式切换模式，因为串口前缀方式在数据流中容易被误触发。如果数据内容里恰好包含$$$三个字符，模块会退出数据模式进入命令模式，导致数据中断。这个坑在传输二进制数据时特别容易踩，我见过有人传固件升级包时，每传几百字节就“掉线”，其实就是数据里出现了命令前缀。

3.3 流控引脚RTS/CTS的正确接法

BM70的串口支持硬件流控，Starter Kit上默认把RTS/CTS接好了，但如果你自己飞线扩展蓝牙模块，一定要接流控。BM70内部数据缓冲不大，如果主控连续高速发送超过缓冲容量，模块会丢数据。开启硬件流控后，模块的RTS引脚可以在缓冲区满时拉低，通知主控暂停发送。

我在做GPS数据记录时深有体会。GPS模块通常以1Hz频率输出NMEA语句，每条大约几十字节，这个量级可能不需要流控；但如果GPS换成10Hz输出，或者你从SD卡读文件通过蓝牙发数据，瞬间数据量一大，没有流控就会丢字节。所以我现在的习惯是：只要接BM70的串口，一律把RTS/CTS都连上，在MCC里配置UART时也开启硬件流控，宁可多占两根IO，不给自己留丢数据的隐患。

3.4 连接参数与数据吞吐的取舍

BLE的数据传输不像串口那样连续，它依赖连接事件（Connection Event）周期性地传输。BM70的AT命令里可以设置连接间隔（Connection Interval），比如15ms、30ms、50ms等。连接间隔越短，单位时间内能传的数据越多，但功耗越大；间隔越长，省电，但延迟越高。

我实测的经验值：如果传文本指令或传感器数据（每次几十字节），30ms连接间隔够用；如果要传音频流或大文件，就得设到7.5ms到10ms，并且关闭省电模式。改这些参数时要注意手机对连接参数协商的限制——Android和iOS会根据自己的策略拒绝某些过激的参数，比如Android有的机型不允许连接间隔小于某个值，表现为“能连上，但数据量一大就断”。这种情况下，建议把间隔设置在15ms以上，并关闭所有“跳频”优化，稳定性优先。

4. 第一个完整应用：串口蓝牙透传实战

4.1 硬件连接与跳线确认

Starter Kit出厂时BM70与PIC32的UART已经连好了，但还是建议看一眼板子上的跳线，确认UART的TX/RX方向。BM70的TX接PIC32的RX，BM70的RX接PIC32的TX，交叉连接，别搞反。板子上一般会用丝印标出UART_TX、UART_RX两个测试点，方便你用示波器或逻辑分析仪直接观察。

如果你想用外部的USB转串口工具直接调试BM70模块本身（不经过PIC32），也可以从板子上找到BM70的测试点飞线出来。我经常这么干，先把模块的AT命令配置好，再接回PIC32，能省不少排查时间。

4.2 Harmony 3（MCC）的配置步骤

打开MPLAB X，新建Harmony工程，选择PIC32MZ2048EFH144。在MCC中需要配置的内容如下：

1. Clock Configuration：设置系统时钟252MHz，外设时钟可以保持默认，UART时钟要确保能精确产生115200波特率。
2. UART配置：选择一个空闲的UART外设（比如UART2），波特率115200、8位数据、无校验、1位停止位、开启硬件流控（如果接线支持）。
3. GPIO配置：把BM70的复位引脚（RST）和唤醒引脚（WAKEUP）配置为输出，初始电平按模块手册设置。
4. BLE配置：在MCC里搜索BM70或BLE，部分Harmony版本有BM70的驱动组件，把它添加进来，没有的话就用“Bare Metal”方式直接在应用层通过UART发AT命令。

生成代码后，在APP_Initialize里先对BM70做初始化序列：拉低RST复位模块，等待100ms，拉高，再等待模块启动就绪（至少200ms），然后通过串口发送AT命令配置设备名和广播参数。这里有个细节：复位后不能立刻发AT命令，BM70需要几百毫秒启动时间，我一开始只等了50ms，结果第一条AT命令老是没响应，后来改成300ms就好了。

4.3 手机端串口蓝牙终端的联调

手机端我用过好几个串口蓝牙终端App，比如Serial Bluetooth Terminal、BLE Terminal、nRF Connect。对于BM70这种透传型BLE模块，推荐用支持收发自定义数据的APP，例如nRF Connect（可以看GATT服务和收发明文数据）和Serial Bluetooth Terminal（直接收发字符串，体验类似串口助手）。

联调步骤大概是这样：

1. 板子上电，App开启扫描，找到BM70设备（默认设备名是“BM70”开头，可以在AT命令里改名）。
2. 点击连接，nRF Connect里可以看到一个自定义的串口服务（通常包含TX、RX两个characteristic）。
3. 手机往RX characteristic写入字符串，板子收到后通过串口打印出来；板子串口收到数据后，会以Notification形式发送到手机。
4. 用串口蓝牙终端App时，直接输入文本回车发送，收到的数据实时显示在屏幕上。

我建议第一次联调时先用nRF Connect这种能看到GATT细节的工具，因为如果数据没到，你可以检查是服务UUID匹配问题、还是通知开关（CCCD）没打开。Serial Bluetooth Terminal这类工具会自动处理，但出了问题不好定位。

4.4 多字节数据分包与丢字节问题

联调时最容易遇到的怪异现象：数据不是丢，而是“分包”——明明发了一条20字节的指令，手机端收到两三条，每条几字节到十几字节不等。这个表面上是App显示问题，实际是BLE的MTU限制和连接间隔共同作用的结果。BLE单个通知的最大字节数受MTU限制，默认情况下只有23字节，扣掉协议头，实际有效载荷只有20字节。超过20字节就要拆成多个Notification，而每个Notification只能在不同的连接事件里发，所以App收到的就是多个包。

应对办法有两个：

一是把MTU改大：在BM70的AT命令里启用长MTU（比如AT+MTU=247），手机端也支持协商的话，单包最大就能发到244字节。实测大多数现代手机支持，只有一些老安卓设备会跑回默认值。二是自己定义简单的分包协议，在数据帧头加长度字段，接收端拼接。如果你做的是可靠文件传输，建议两种都做，线上加校验，线上加校验，保证完整性。

还有一个很隐蔽的丢字节原因：BM70的UART RX缓冲溢出。当你用printf大量打印调试信息时，PIC32的UART发送速率超过BM70处理速度，如果没开流控，就可能丢字节。我一般把调试打印的波特率降到38400，或加一个1ms延时，数据完整率明显提升。

5. 进阶实战：蓝牙GPS输出与NMEA数据流解析

5.1 为什么选择GPS数据做蓝牙测试样例

GPS模块输出的NMEA 0183协议数据流非常适合作为蓝牙透传的测试素材：数据是纯ASCII文本、速率稳定（通常1Hz）、单帧长度在几十字节左右，能很好地检验透传链路的完整性和分包行为。这个场景还有实际工程价值——很多便携式设备需要把位置信息无线发到手机或平板，比如车载追踪器、户外运动记录仪、共享设备的定位模块。

5.2 NMEA语句格式与波特率匹配

GPS模块的上电默认波特率常见的是9600，也有4800和115200的型号。BM70的数据通道波特率固定需要和PIC32 UART保持一致。我在MCC里把PIC32的UART1（接GPS）配成9600，UART2（接BM70）配成115200，然后在应用层做了一组“协议转换”：从UART1收数据，原封不动地写到UART2。

这里有个值得注意的细节：两个串口的波特率不同，会导致字节在时间轴上“压缩”或“拉伸”。GPS的NMEA帧进入UART1的缓冲区后，如果你用简单的中断方式逐字节转发到UART2，由于UART2波特率高于UART1，原本慢速到达的数据会快速发出去，TCP/IP里说的“背压”概念在这里也适用——下游发送速度大于上游接收速度，缓冲区不会堆积，反而要小心上游数据还没到齐就发送的情况。实际测试下来，1Hz的GPS数据量很小，这种转发方式完全够用，但如果GPS刷新率调到10Hz，建议用DMA和环形缓冲区来做，避免中断开销太大导致丢字符。

5.3 实测数据完整性与App解析差异

我用GPS Click模块做了一组测试：GPS天线放在窗边，等GPS锁定后，用下面这段代码逻辑转发数据：从UART1读NMEA字符，缓存到环形缓冲区；UART2发送状态允许时，从缓冲区读一字节发往BM70；手机端用支持NMEA解析的蓝牙App显示经纬度。

实测结果：GPS锁星后数据流很稳定，但App上偶尔显示解析失败。排查发现不是数据丢失，而是部分App要求以$开头且以\r\n结尾的完整NMEA帧，如果数据在帧中间开始接收，或者因为MTU分包导致帧被拆到两条BLE通知里，App的解析器可能跳过或报错。

解决思路是在PIC32端做“帧同步”：只发送以$开头的完整NMEA帧，每帧以\r\n结尾，一帧一个通知包（通常不超过20字节，如果超过就拆分并在App端拼帧）。我在板子上实现了一个小状态机：等待$，收到后开始缓冲，直到\n结束，然后一次性发给BM70。这样一来，手机端收到的每条Notification都是完整的一帧，解析率几乎100%。

5.4 手机端解析NMEA的App选择

如果你也想复现这个GPS蓝牙输出场景，App端的选型很重要。我试过的几个方案：

• GPS Test / GPS Status：主要读手机内置GPS，不支持从蓝牙设备接收NMEA。
• Bluetooth GPS（Android平台）：可以把蓝牙串口收到的NMEA数据注入系统的GPS位置服务，让不支持的App也能使用外置GPS位置源。这类App在测量和测绘场景很常用。
• Serial Bluetooth Terminal：纯显示原始数据，不加解析，适合看数据流完整性，不适合直接看经纬度。
• nRF Connect：可以看GATT服务，也能显示原始数据，但没法直接解析NMEA成地图坐标。

所以如果你在Windows/Mac上调试，建议用串口工具+GPS解析软件的组合：蓝牙做虚拟串口，GPS解析软件读那个串口；如果纯用手机，就用Bluetooth GPS类App，实际操作时记得在系统设置里开启“位置模拟”或“允许GPS注入”权限，不同Android版本权限路径不一样，这点容易被忽略。

6. 调试蓝牙连接时的常见异常与定位手段

6.1 手机扫描不到设备：广播参数与缓存问题

扫描不到设备是蓝牙开发最高频的烦恼，常见原因有三类：

1. 广播没开启：检查BM70是否处于广播状态，需要确认AT命令里广播使能参数（如AT+ADV=ON），以及PIC32初始化时是否配置了广播使能引脚。
2. 广播间隔过长：如果广播间隔设置到500ms以上，手机扫描时可能需要多扫几轮才能发现，甚至有些手机扫描窗口太短扫不到。
3. 手机蓝牙缓存：iOS和Android都有蓝牙缓存，设备改名或改广播内容后，手机端可能仍显示旧设备。Android上的处理方式是关蓝牙再开，或进“开发者选项”里关闭“蓝牙扫描过滤”。

我遇到过一个诡异场景：用自己手机扫不到板子，旁边同事手机却能扫到。后来发现是我手机上装了太多蓝牙设备，系统扫描结果被过滤了一部分。清掉不用的配对设备后恢复正常。

6.2 BLE广播风暴（Bluetooth LE Spam）现象与解决

搜索网络热词时看到“bluetooth le spam”，这个说法在BLE开发圈里特指广播包刷屏现象：周边大量低功耗设备持续广播，或者某台设备广播包速率过高，导致扫描端无法及时处理其它设备的广播包。

在调试中我确实遇到过类似的体验：办公区蓝牙设备非常多，手机扫描列表里塞满各种设备，延迟很大甚至刷不出BM70。这种情况下可以试试：把手机靠近板子减少射频衰减；把BM70的广播间隔调短（比如100ms或50ms），这样每个扫描窗口都能命中广播；在电脑或手机上用带RSSI排序的扫描工具（如nRF Connect）按信号强度从高到低排列，优先找它。但这里要提醒一点：广播间隔调短意味着功耗显著上升，如果做电池供电产品，发布前要记得调回200ms以上。

6.3 连接后频繁断连的完整排查链路

我在透传调试中遇到过“连上后十几秒就断开，反复重连”的问题。排查过程大概是这样：

1. 先看RSSI：手离板子越远信号越差，如果RSSI低于-80dBm，断连就很正常，靠近或调整天线位置。板载天线对周围环境很敏感，手摸到天线附近都会导致信号波动。
2. 再看供电：BM70广播和连接瞬间会有电流尖峰，如果供电质量差，电压跌落会导致模块重启。Starter Kit用USB供电没问题，但如果你自己飞线，线太细或LDO余量不足就会有隐患。我用示波器测过，连接瞬间的电压跌落超过100mV，就值得怀疑。
3. 确认连接参数：有些App在连接后会请求修改连接间隔，如果请求的值超出BM70支持范围，模块会拒绝，某些手机可能因此断开。BM70的AT命令可以设置连接参数上限和下限，把范围放宽一些（比如间隔允许7.5ms到50ms）能提高兼容性。
4. 关键一步：看串口日志。BM70在命令模式下支持打印连接状态事件，比如连接建立、断开原因等。把模块日志打开后，能看到断开原因码（如0x08表示连接超时、0x13表示远端断开等）。针对原因再逐项排查，比盲猜高效得多。

经验是：80%的断连问题源于供电或距离，10%源于连接参数协商，剩下10%才是固件和协议栈的锅。所以排查顺序永远是：距离 → 供电 → 参数 → 日志，反着查会很浪费时间。

6.4 蓝牙连上了但收不到数据：GATT服务与通知开关

一个经典场景：手机连接成功，nRF Connect能看到服务列表，但在RX characteristic上订阅了通知（开启CCCD），板子发数据时手机还是收不到。我在BM70上就遇到过这种情况，最后发现原因有两类：

• 使错了characteristic：BM70通常有TX、RX两个特征，板子往手机发数据走的是TX特征（手机订阅它的Notification），手机往板子发走的是RX特征（手机写入）。如果你在RX特征上订阅通知自然收不到。
• 连接模式没配对：部分BM70固件在安装连接时，设备对端是可以配对的和通信的，需要先绑定配对。如果硬件加密要求（如AT+IOCAP=...）没配对，某些手机在配对过程中会暂停数据通道。

解决建议是：用nRF Connect查看每个characteristic的属性，TX属性的属性列表里应该有Notify和Read，RX属性里应该有Write或Write Without Response，别搞反了。

7. 功耗实测与低功耗优化经验

7.1 手册电流数据与实际测量的差距

BM70的低功耗宣传值是广播状态大概十几到几十微安，连接状态看连接间隔几毫安到几十毫安，但这些数字在实际板子上往往没那么乐观。Starter Kit板上有调试LED、稳压器、电平转换电路，整板待机电流会明显高于模块单体的手册数值。

我实测整板工作电流是这样的：BM70进入deep sleep后，整板电流大概2~3mA，比模块单体的几个µA高太多。因为PIC32MZ本身功耗就不低，还有板载LDO和LED漏电。如果你想做超低功耗产品，最终肯定要自画板子，精简外围电路。

7.2 几个能立刻见效的降功耗调整

如果你用这块板子做原型，想把功耗压一压，有几个调整可以在不改硬件的前提下做：

1. 关掉不用的LED：板上RGB LED通过GPIO驱动，代码里把不用的LED引脚配成输入或输出低电平，能省几百微安到毫安级电流。别看LED小，三色全亮时电流很容易到10mA以上。
2. 蓝牙广播间隔调大：广播状态是功耗大头。开发调试时广播间隔用100ms方便发现设备，但做功耗验证时改回500ms甚至1s。广播功耗和间隔大致呈反比，比如100ms间隔平均电流能到几百µA，1s间隔则降到几十µA。
3. 用MCU睡眠调度：PIC32MZ进入睡眠模式后功耗很低。如果你的应用是周期性的（比如每分钟采一次传感器然后通过蓝牙发送），可以让PIC32大部分时间睡在睡眠里，用定时器或外部唤醒，只在需要传输时唤醒BM70。这套流程在Harmony里有现成的“Power Manager”组件，只是初始配置时要把唤醒源、时钟切换设清楚，否则容易一睡醒不来。
4. BM70的深度睡眠控制：AT命令里配置BM70的睡眠模式，再把BM70的WAKEUP引脚接到PIC32的GPIO。需要发送数据时先唤醒模块，发送完成后让它继续睡。这里的坑在于：唤醒后模块需要几十毫秒重新准备就绪，如果你一唤醒立刻发数据，前几字节会丢。我一般会在唤醒后等待100ms再发送。

7.3 测量功耗时别踩的坑

测量低功耗电流要用串联电流表而不是并联电压表。板子在广播时会周期性产生毫秒级的电流脉冲（峰值可达几十毫安），普通万用表在这种脉冲电流下会严重低估平均值，最好用带统计功能的万用表或示波器电流探头，配合采样电阻来看平均电流。我自己用Fluke的TrendCapture功能测平均值，比单纯看瞬时读数可靠得多。

还有一点：测量时把USB拔掉，改成电池或稳压电源供电。USB供电时板子一直处于在线状态，串口调试接口也在耗电，测出来的根本不是真实功耗。

8. 写在最后：一个小技巧和一点选型建议

最后分享两个个人经验。

第一个小技巧：在用BM70做透传时，把PIC32的UART RX中断缓冲从默认的1字节改成64字节，可以显著减少高波特率下中断触发频率，降低CPU占用。具体在MCC里可以调UART驱动的RX_BUFFER_SIZE参数，默认值往往偏小。

第二个建议：如果你只是做纯透传类项目，不一定非要买Starter Kit。PIC32 + BM70这种组合的开发板更多是评估平台，帮你验证方案可行性，最终产品大概率会用更小的模块直接画板。但如果你还在学习阶段或者想快速验证一个蓝牙产品想法，Starter Kit的价值在于省去了焊接模块和搭建最小系统的麻烦，上电就能跑，非常适合用来建立对“MCU + BLE”整套体系的感觉。

我个人在实际项目中用这套组合做了GPS数据记录仪和两个传感器透传节点，稳定运行了大半年，没有掉过链子。如果你也在考虑PIC32平台上的蓝牙方案，希望这篇能从硬件选型、环境搭建、调试方法和功耗优化几个方面帮你少走一些弯路。有不同意见或者踩到新坑也欢迎一起交流。