简介：中科蓝讯TWS蓝牙耳机开发实践指南是一份以AB32VG1评估板为核心的嵌入式开发教程，适合希望基于RT-Thread操作系统进行RISC-V蓝牙耳机及物联网外设开发的初学者和进阶工程师。资源以单个docx文档形式提供，大小约32.21MB，内容覆盖UART、GPIO、I2C、SPI、Timer、ADC、PWM、WDT、RTC、SDIO、Flash、SD、IRDA、Audio、MIC及WiFi模块配置等十余个实战主题，并附带智慧门禁系统、遥控台灯、智能灯控、WAV音频播放四个完整项目案例。文档由多名工程师联合编写，配有清晰的模块原理、环境搭建与工程操作说明，可帮助读者从零掌握RT-Thread Studio下的开发流程。目前已有5121人学习该资料，适合用于快速上手AB32VG1平台、完成蓝牙耳机周边功能开发或作为相关课程与毕业设计的参考资料。

1. TWS 蓝牙耳机开发入门：一块评估板怎么串起整套音频方案

做TWS蓝牙耳机开发最磨人的一点，不是声学设计，也不是配对协议，而是主控芯片的资料和工具链长期处于半封闭状态。这份基于中科蓝讯 AB32VG1 的实践指南，把一颗 120MHz 主频、板载蓝牙/FM/音频接口的 RISC-V 芯片，连同 RT-Thread 物联网操作系统的十六个外设例程和四个完整项目拆开摆在你面前。它适合两类人：一类是想在蓝牙音频产品里换国产 RISC-V 主控的开发者，另一类是刚接触 RT-Thread、想从板级例程抄作业入门的新手。整份指南从环境搭建一路讲到音频链路和 Wi-Fi 模块配置，照着跑一遍，基本能把一颗音频 SoC 的常用外设摸个遍。

这颗芯片的定位很有意思：中科蓝讯本身就是做蓝牙音频芯片的，AB32VG1 是它面向通用市场开放的第一颗 RISC-V MCU，保留了蓝牙模块、FM 模块、音频接口和 mic 采集这一整套音频相关外设。所以这份指南名义上是外设例程合集，实际上倒更像一份“从零做蓝牙耳机/蓝牙音箱主控”的落地手册——后面四个实战项目也在教你怎么把外设组合成产品功能。

2. 环境与工程：RT-Thread Studio 建工程、编译、下载全流程

先说硬件，再装工具，最后跑通一个空工程。这个顺序不能乱，因为 AB32VG1 的下载器、驱动和 IDE 之间有耦合，跳步容易卡在莫名其妙的驱动问题上。我见过有人在串口助手上一通乱试，结果只是少装了一个 BSP 资源包。

2.1 硬件资源盘点：接口与扩展

AB32VG1 芯片本身是 LQFP48 封装，主频 120MHz，片上集成 192KB RAM 和 8Mbit Flash，同时带 ADC、PWM、USB、UART、IIC 等常见外设。指南里开头写 Flash 8Mbit，后文硬件介绍部分又写成 4Mbit，这种文档不一致在国产芯片手册里很常见，实际容量以芯片数据手册为准——这一点建议先记住，后面避坑章节会专门说。

开发板的板载资源整理成了一张表，做方案选型时可以直接照这个清单对需求：

I/O 口全部通过 2.54mm 标准间距引出，同时兼容 Arduino Uno 扩展接口。这个设计对二次开发非常友好——你想先拿面包板搭个外部传感器验证逻辑，直接按 Arduino 的引脚定义接线就行，完全不用动 PCB，这在音频类评估板里算少见的。

2.2 安装 RT-Thread Studio 与 AB32VG1 资源包

先下载 RT-Thread Studio 安装包，同时把 Downloader 下载软件和配套的 USB 转串口驱动也一并下载。安装完成后打开 IDE，第一步不是急着建工程，而是去工具栏的 SDK 管理器里装板级支持包：

1. 打开 SDK 管理器，找到 Board_Support_Packages 分类。
2. 勾选 Bluetrum_AB32VG1-ab-prougen，点击安装。
3. 在 SDK 管理器中安装 RISC-V 工具链，否则无法编译。
4. 全部装完后重新打开 IDE，确保环境变量生效。

注意第 3 步。RISC-V 工具链如果不装，IDE 编译时会直接报找不到编译器，很多新手在这一步卡半天，其实只是少勾了一个包。装完资源包后，你在 Studio 里就能基于 AB32VG1 直接建项目了，RT-Thread 丰富的软件包也可以正常拉取，开发门槛比裸机编程低不少。

2.3 Downloader 与 USB 转串口驱动

编译出来的固件后缀是 .dcf，位于工程 Debug 目录下，Downloader 负责把这个固件下载到板子。Downloader 软件需要安装自己的 USB 转串口驱动，如果驱动不匹配，下载时会直接报错，这是新手上路最常见的翻车点。

V2 版本的开发板串口芯片是 CH340，系统自动安装驱动就能用。V1 版本用的是 CP2102，需要手动切换到配套驱动。我一般会建议拿到板子先看一下背面的版本丝印，再决定要不要折腾驱动。如果希望编译后自动下载，在 Downloader 的下载下拉窗中选择“自动”即可，省去每次手动点下载的重复劳动。

Downloader 驱动不匹配报错 -> 安装配套 USB 转串口驱动 -> 重新插拔板子 -> 再次下载

这里有个容易忽略的细节：切换驱动后必须重新插拔 USB 线，让 Windows 重新枚举设备，否则驱动不会生效。我在第一块 V1 板子上就吃过这个亏，驱动装好了但没重插，白折腾了二十分钟。

2.4 新建工程与编译

打开 Studio 后，按“文件 -> 新建 -> RT-Thread 项目”进入创建向导。选择“基于开发板”，填写工程名字，开发板选 AB32VG1-AB-PROUGEN，BSP 版本选 1.0.8，其他保持默认，点完成，一个新项目就建成了。

单击编译按键，IDE 会调用刚才装好的 RISC-V 工具链完成编译，生成 .dcf 固件到 Debug 目录。这个流程和 STM32 的 CubeMX 类似，但因为是国产 IDE，界面和日志更直白一些。编译成功后，用 Downloader 把 .dcf 烧进去，板子上的烧录指示灯会跟着闪，跑起来就能在终端看到 RT-Thread 的启动日志。

3. 通信与存储实践：UART、I2C、模拟 SPI、Flash 与 SD

这一章是整个指南的核心部分。通信外设决定你能不能和设备对话，存储外设决定音频文件放哪、参数存哪。我按“调试 -> 挂外设 -> 存数据”的顺序来讲，这也是一个蓝牙耳机方案里外设逐个点亮的自然路径。

3.1 UART：串口 0 调试、串口 1 通讯

AB32VG1 的串口 0 被用作系统调试串口，串口 1 使用 PA3 和 PA4，可以用作通讯端口。RT-Thread 里已经做好了 UART0 和 UART1 的驱动，你不需要碰寄存器，只要打开对应设备即可。下面这个例程导出了 uart_sample 命令到控制终端，功能是先输出字符串，然后把收到的每个字符加一后返回。

/* 程序清单：这是一个串口设备使用例程 * 命令调用格式：uart_sample uart1 * 命令解释：命令第二个参数是要使用的串口设备名称，为空则使用默认串口设备 * 程序功能：通过串口输出字符串"hello RT-Thread!"，然后错位输出输入的字符 */ #include <rtthread.h> #define SAMPLE_UART_NAME "uart1" /* 用于接收消息的信号量 */ static struct rt_semaphore rx_sem; static rt_device_t serial; /* 接收数据回调函数 */ static rt_err_t uart_input(rt_device_t dev, rt_size_t size) { /* 串口接收到数据后产生中断，调用此回调函数，然后发送接收信号量 */ rt_sem_release(&rx_sem); return RT_EOK; } static void serial_thread_entry(void *parameter) { char ch; while (1) { /* 从串口读取一个字节的数据，没有读取到则等待接收信号量 */ while (rt_device_read(serial, -1, &ch, 1) != 1) { /* 阻塞等待接收信号量，等到信号量后再次读取数据 */ rt_sem_take(&rx_sem, RT_WAITING_FOREVER); } /* 读取到的数据通过串口错位输出 */ ch = ch + 1; rt_device_write(serial, 0, &ch, 1); } } static int uart_sample(int argc, char *argv[]) { rt_err_t ret = RT_EOK; char uart_name[RT_NAME_MAX]; char str[] = "hello RT-Thread!\r\n"; if (argc == 2) { rt_strncpy(uart_name, argv[1], RT_NAME_MAX); } else { rt_strncpy(uart_name, SAMPLE_UART_NAME, RT_NAME_MAX); } /* 查找系统中的串口设备 */ serial = rt_device_find(uart_name); if (!serial) { rt_kprintf("find %s failed!\n", uart_name); return RT_ERROR; } /* 初始化信号量 */ rt_sem_init(&rx_sem, "rx_sem", 0, RT_IPC_FLAG_FIFO); /* 以中断接收及轮询发送模式打开串口设备 */ rt_device_open(serial, RT_DEVICE_FLAG_INT_RX); /* 设置接收回调函数 */ rt_device_set_rx_indicate(serial, uart_input); /* 发送字符串 */ rt_device_write(serial, 0, str, (sizeof(str) - 1)); /* 创建 serial 线程 */ rt_thread_t thread = rt_thread_create("serial", serial_thread_entry, RT_NULL, 1024, 25, 10); /* 创建成功则启动线程 */ if (thread != RT_NULL) { rt_thread_startup(thread); } else { ret = RT_ERROR; } return ret; } /* 导出到 msh 命令列表中 */ MSH_CMD_EXPORT(uart_sample, uart device sample);

这段代码的逻辑很清晰：先通过 rt_device_find 按名字查找串口设备，找不到就直接返回错误；找到后初始化信号量，以中断接收模式打开设备，注册回调函数。回调函数里只做一件事——释放信号量，这样串口线程被唤醒后去读取数据，实现“中断通知 + 线程处理”的解耦结构。主线程创建了一个 1024 字节栈、优先级 25、时间片 10 的 serial 线程，线程里循环读字节，读不到就阻塞等信号量。

几个关键参数值得注意：

由于初始化串口时默认波特率是 1500000，你需要在 libraries->hal_drivers->drv_usart.c 的 rt_hw_usart_init 函数里做修改。文档给的改法是遍历初始化时单独判断串口 1，把波特率改成 115200：

for (int i = 0; i < obj_num; i++) { uart_obj[i].config = &uart_config[i]; uart_obj[i].serial.ops = &ab32_uart_ops; uart_obj[i].serial.config = config; uart_obj[i].serial.config.baud_rate = 1500000; /* 如果是串口 1，修改波特率为 115200 */ if (i == 1) { uart_obj[i].serial.config.baud_rate = 115200; } result = rt_hw_serial_register(&uart_obj[i].serial, uart_obj[i].config->name, RT_DEVICE_FLAG_RDWR | RT_DEVICE_FLAG_INT_RX | RT_DEVICE_FLAG_INT_TX | uart_obj[i].uart_dma_flag, NULL); RT_ASSERT(result == RT_EOK); }

这里有个隐含的经验：1500000 是给调试器的高速波特率，你用普通串口助手去连肯定是乱码。所以拿到例程第一步就是把波特率改成 115200，否则后面所有调试都建立在错误的基础上。改完之后重新编译下载，在 finsh 终端输入 uart_sample uart1，再用串口调试助手往串口 1 发数据，板子会把每个字符加一后返回，这个回环测试通过就说明 UART1 链路完全打通了。

3.2 I2C：总线上挂外设的常规套路

I2C 在蓝牙音频方案里最常见的用途是挂传感器和音频编解码器。AB32VG1 有一路 IIC 接口引出，RT-Thread 的设备框架里已经把 I2C 封装成标准设备，你不需要关心底层时序，直接调用 API 即可。

#include <rtthread.h> #include <rtdevice.h> #define I2C_BUS_NAME "i2c1" static void i2c_sample(void) { struct rt_i2c_bus_device *i2c_bus = RT_NULL; struct rt_i2c_msg msgs[2]; rt_uint8_t reg_addr = 0x00; rt_uint8_t reg_val = 0; i2c_bus = (struct rt_i2c_bus_device *)rt_device_find(I2C_BUS_NAME); if (i2c_bus == RT_NULL) { rt_kprintf("find %s failed!\n", I2C_BUS_NAME); return; } /* 读寄存器：先写寄存器地址，再读一字节数据 */ msgs[0].addr = 0x1A; /* 从机地址，7 位模式，不含读写位 */ msgs[0].flags = RT_I2C_WR; msgs[0].buf = &reg_addr; msgs[0].len = 1; msgs[1].addr = 0x1A; msgs[1].flags = RT_I2C_RD; msgs[1].buf = &reg_val; msgs[1].len = 1; if (rt_i2c_transfer(i2c_bus, msgs, 2) == 2) { rt_kprintf("reg[0x%02x] = 0x%02x\n", reg_addr, reg_val); } } MSH_CMD_EXPORT(i2c_sample, i2c device sample);

这段代码用的是 RT-Thread 标准的 i2c_transfer 接口，把“写寄存器地址”和“读数据”组合在一个事务里完成。参数上要注意从机地址是 7 位模式，不包含读写位；msgs 数组里几个消息的顺序代表总线上的一次完整操作序列，返回值等于消息个数才算成功。实际项目中我一般会把寄存器地址也封装一层，这样应用层只关心“读谁的值”。

3.3 模拟 SPI：不占用硬件资源的备选方案

硬件 SPI 外设被占用或者引脚冲突时，模拟 SPI 就是救命稻草。做法很直接：用 GPIO 翻转模拟时钟和数据线。指南里单独列了一章来讲，说明这颗芯片上确实有场景需要这么做。

#define SPI_CLK_PIN 21 #define SPI_MOSI_PIN 22 #define SPI_MISO_PIN 23 #define SPI_CS_PIN 24 void spi_init_pins(void) { rt_pin_mode(SPI_CLK_PIN, PIN_MODE_OUTPUT); rt_pin_mode(SPI_MOSI_PIN, PIN_MODE_OUTPUT); rt_pin_mode(SPI_MISO_PIN, PIN_MODE_INPUT); rt_pin_mode(SPI_CS_PIN, PIN_MODE_OUTPUT); rt_pin_write(SPI_CS_PIN, PIN_HIGH); } void spi_write_byte(rt_uint8_t data) { for (int i = 7; i >= 0; i--) { rt_pin_write(SPI_CLK_PIN, PIN_LOW); rt_pin_write(SPI_MOSI_PIN, (data >> i) & 0x01); rt_pin_write(SPI_CLK_PIN, PIN_HIGH); } }

注意这段代码是文档没有的常见补充做法。它的核心思想是高位先出，在时钟上升沿把数据位放到 MOSI 线上。好处是任意 GPIO 都能当 SPI 用，坏处是速率受限于 GPIO 翻转速度，所以一般只用来驱动低速的外设 Flash 或 LCD。如果你对速率有要求，还是优先走硬件 SPI，模拟 SPI 只做兜底方案。

3.4 Flash 与 SD/SDIO：音频文件放哪

存储这块要分清两个角色。片上 Flash 8Mbit（约 1MB）用来放固件和少量参数，比如设备名称、配对信息、音量设置。TF 卡通过 SDIO 接口接入，主要放 WAV 音频文件，蓝牙音箱播放 TF 卡音乐就是走这条链路。

在做 TWS 耳机或蓝牙音箱时，提示音（配对成功、电量低、开机音）一般放片上 Flash，音乐文件放 TF 卡。这样固件和用户数据分离，升级固件不会动到用户的音乐文件。SDIO 的高速模式适合连续读大文件，而模拟 SD 方式兼容性更好，代价是吞吐量低一些，具体用哪种要看产品对音频读取速度的要求。

4. 控制与音频实践：GPIO、Timer、ADC、PWM、Audio、mic

上一章解决的是“能不能通”的问题，这一章解决的是“能不能控、能不能播”的问题。蓝牙耳机最终要落到交互和音频上：按键控制、电量检测、声音播放、麦克风采集，全部由这一组外设承担。

4.1 GPIO：控制全彩 RGB 灯

板载一个三色 RGB 彩灯，原理图里三个引脚分别控制红绿蓝三色。GPIO 实践的目标就是通过拉高拉低引脚，让 RGB 灯完成简单的颜色变换。RT-Thread 里操作 GPIO 用统一接口：

#define LED_R_PIN 27 #define LED_G_PIN 28 #define LED_B_PIN 29 void rgb_set(rt_uint8_t r, rt_uint8_t g, rt_uint8_t b) { rt_pin_write(LED_R_PIN, r ? PIN_HIGH : PIN_LOW); rt_pin_write(LED_G_PIN, g ? PIN_HIGH : PIN_LOW); rt_pin_write(LED_B_PIN, b ? PIN_HIGH : PIN_LOW); }

GPIO 输出的本质就两个函数：rt_pin_mode 设置输入输出方向，rt_pin_write 设置电平高低。RGB 灯颜色变换的逻辑无非是排列组合三种电平状态。这个例程的意义不是灯本身，而是让你上手熟悉全套 GPIO 操作，后面做按键扫描、控制外部设备都基于同一套 API。

4.2 Timer 与 PWM：从定时调度到精确输出

Timer 实践对应的是周期性任务调度。比如按键扫描需要 20ms 轮询一次，LED 呼吸效果需要定时更新占空比，这些都离不开定时器。RT-Thread 里可以用硬件定时器驱动或软定时器，前者精度高，后者省资源。

PWM 实践则直接对应输出控制。AB32VG1 引出六路 PWM 输出引脚端子，常见的用法是驱动蜂鸣器、LED 调光，以及音频信号的辅助输出。PWM 的两个关键参数是频率和占空比：频率决定音调或闪烁速度，占空比决定亮度或音量。做遥控台灯项目时，调光就是通过改占空比实现的。

4.3 ADC：六路模拟采集

AB32VG1 板子上引出了六路 ADC 输入引脚端子。ADC 实践主要教你怎么读取模拟信号，在蓝牙耳机场景里，最典型的是电池电量检测——通过电阻分压把电池电压降到 ADC 量程内，再根据采样值反推电量百分比。

#include <rtdevice.h> #define ADC_DEV_NAME "adc1" #define ADC_DEV_CHANNEL 3 #define ADC_REF_VAL 3.3f #define ADC_FULL_SCALE 4096.0f static void adc_sample(void) { rt_adc_device_t adc_dev = RT_NULL; rt_uint32_t value = 0; float voltage = 0.0f; adc_dev = (rt_adc_device_t)rt_device_find(ADC_DEV_NAME); if (adc_dev == RT_NULL) { rt_kprintf("find %s failed!\n", ADC_DEV_NAME); return; } rt_adc_enable(adc_dev, ADC_DEV_CHANNEL); value = rt_adc_read(adc_dev, ADC_DEV_CHANNEL); voltage = value * ADC_REF_VAL / ADC_FULL_SCALE; rt_adc_disable(adc_dev, ADC_DEV_CHANNEL); rt_kprintf("adc channel %d = %d, voltage = %.2fV\n", ADC_DEV_CHANNEL, value, voltage); } MSH_CMD_EXPORT(adc_sample, adc device sample);

ADC 使用时先使能通道再读数据，读完立即禁用，这是个好习惯，能省电。电压换算公式里的 ADC_FULL_SCALE 取决于 ADC 位数，如果是 12 位就是 4096。注意参考电压 3.3V 只是理论值，实际以板子上 VREF 引脚输入为准，否则算出来的电压会有偏差。

4.4 Audio 与 mic：音频链路怎么搭

音频实践是这份指南的重头戏。板载音频接口采用的是美标 CTIA，四个触点分别是左右声道、地线和麦克风。AB32VG1 的 Audio 实践讲的是音频播放链路，mic 实践讲的是麦克风采集，两者合起来就是一个完整的通话或录音通道。

做 WAV 音频播放项目时，典型流程是：从 SD 卡读取 WAV 文件，解析文件头拿到采样率、位深等参数，然后循环读取音频数据送进 Audio 外设输出到耳机座。这个链路在蓝牙耳机里就是 A2DP 播放的本地版——先把文件读出来、解码、输出，验证通了之后再替换成蓝牙接收的数据流。

注意：CTIA 是美标，还有一种 OMTP 是国标，两者麦克风和地线的位置不同。如果你用国标耳机插这个板子的音频口，会听到声音但麦克风用不了。排查音频问题时先确认耳机标准。

mic 实践对应的是语音输入方向。蓝牙耳机的通话降噪、唤醒词检测都要靠 mic 采集。采集到的是原始 PCM 数据，后面接什么算法就看产品需求了——降噪、回声消除、语音识别都可以在这一层做。

4.5 IRDA 与 WIFI：遥控和联网

IRDA 是红外接收端口，配合外部红外遥控器可以实现远程控制。遥控台灯项目就是这么做的：遥控器发红外信号，IRDA 接收并解析，然后通过 GPIO 或 PWM 控制灯的状态和亮度。

WIFI 模块配置是文档新增的章节。给 AB32VG1 挂一个 WIFI 模块，RT-Thread 的 WIFI 框架会自动管理连接，之后就能做远程控制、固件 OTA 这类联网功能。对蓝牙耳机来说，WIFI 不是必备，但如果你做的是智能音箱或者带语音助手的耳机底座，WIFI 就是刚需。

5. 常见问题与排查：驱动、波特率、工具链的五个坑

这章把我在跑这份文档时真实踩过的坑集中列出来。每条都按现象、原因、解决三步写，后面再做类似项目可以直接对照排查。

5.1 下载器连不上板子，报驱动错误

现象：用 Downloader 下载 .dcf 固件时，软件提示无法连接或设备打开失败，点下载没反应。

原因：绝大多数情况是 USB 转串口驱动不匹配。V1 版 AB32VG1 开发板用的是 CP2102，V2 版用的是 CH340，两种芯片的驱动不通用。如果系统默认驱动的版本不对，Downloader 就认不到设备。

解决：先看板子背面丝印确认版本，V1 板安装配套的 CP2102 驱动，V2 板用 CH340 的系统自动驱动即可。装完驱动务必重新插拔 USB 线，让系统重新枚举设备。如果还不行，在电脑的设备管理器里手动更新驱动，指向 Downloader 安装目录下的驱动文件夹。

5.2 编译直接报错，找不到 RISC-V 编译器

现象：新建工程后点编译，控制台输出找不到 riscv gcc 工具链，或者提示 make 失败。

原因：SDK 管理器里只装了 BSP 板级支持包，没装 RISC-V 工具链。Studio 本身不自带交叉编译器，编译 AB32VG1 工程必须依赖独立的 RISC-V 工具链包。

解决：打开 SDK 管理器，在工具链或 SDK 分类下找到 RISC-V 工具链并安装，然后重启 Studio 让它重新加载环境变量。如果你在命令行环境手动配过 PATH，确认路径里没有和 Studio 内置工具链冲突的版本。

5.3 串口助手收到的全是乱码

现象：烧录成功后，用串口调试助手连接串口 1，收到的字符无法辨认，或者完全收不到数据。

原因：初始化代码里默认波特率是 1500000，而你的串口助手通常设置的是 115200 或 9600。两侧波特率不一致，收到的必是乱码。如果是完全收不到数据，还要检查是否连错了串口——串口 0 已经被系统调试占用，你只能使用串口 1，对应引脚是 PA3 和 PA4。

解决：按 3.1 节的改法，在 drv_usart.c 的 rt_hw_usart_init 里把 i == 1 的波特率改成 115200，重新编译下载。改完如果还是乱码，检查串口助手的波特率选择是否和代码一致，以及 USB 转串口线是否接触良好。

5.4 文档里 Flash 容量前后矛盾，不知道该信哪个

现象：指南开头写片上 Flash 8Mbit，硬件介绍部分写 4Mbit，两个数据对不上。

原因：文档版本迭代时遗漏了同步更新，这类问题在国产芯片用户手册里很常见。芯片可能改版过，但文档只更新了部分章节。

解决：以芯片官方数据手册为准，不要信整理文档。如果手边没有数据手册，可以在编译后看固件大小上限，或者直接跑一个 Flash 读写例程，写满地址空间看哪些地址能正常读回，实测最可靠。这个排查方法可以推广到所有国产芯片的规格参数核对。

5.5 例程运行后提示 find uart1 failed

现象：在 finsh 终端输入 uart_sample 命令，返回 find uart1 failed，串口设备找不到。

原因：串口 1 的设备没有在系统里注册成功。可能是 BSP 版本里串口驱动默认没使能 UART1，也可能是 SDK 管理器安装的板级支持包版本和工程 BSP 版本不一致，导致设备表不完整。

解决：先确认工程使用的 BSP 版本是 1.0.8，然后在 RT-Thread Studio 的配置工具里检查 UART1 是否被勾选使能。如果配置没问题，再检查是否有引脚冲突——PA3/PA4 有没有被其他外设占用，比如被配置成了 GPIO 或者复用给了别的功能。把引脚复用改回 UART 模式后重新编译即可。

6. 从例程到产品：四个实战项目的改造思路

文档最后给了四个可参考项目，它们的共性不是用什么高级算法，而是把前面十六个外设例程组合成产品功能。智慧门禁系统是 ADC + I2C + UART 的组合：I2C 挂读卡器模块，ADC 检测门磁状态，UART 输出日志和与上位机通信。遥控台灯是 IRDA + GPIO + PWM 的组合：红外接收解析命令，GPIO 控制开关，PWM 控制亮度。智能灯控偏场景联动，把 Timer、ADC 和 PWM 揉在一起做自动控制。WAV 音频播放则是 SD 卡 + Audio + 文件系统的经典链路。

拿到这类项目，我的改造习惯是先画一张“外设到功能”的映射表，再动手改代码。比如 UART 例程里的串口回环逻辑，在门禁系统里就改成收发自定义协议帧；PWM 例程里的固定占空比输出，在台灯项目里就映射到亮度等级。下面这个命令示例就是把 UART 例程改成蓝牙耳机调试通道的直观做法：

static int bt_debug_cmd(int argc, char *argv[]) { if (argc < 2) { rt_kprintf("usage: bt_debug <play|pause|volume>\n"); return RT_ERROR; } if (rt_strcmp(argv[1], "play") == 0) { audio_play_start(); } else if (rt_strcmp(argv[1], "pause") == 0) { audio_play_pause(); } else if (rt_strcmp(argv[1], "volume") == 0) { if (argc == 3) { audio_set_volume(atoi(argv[2])); } } return RT_EOK; } MSH_CMD_EXPORT(bt_debug_cmd, bluetooth audio debug command);

这个命令把调试入口直接挂进 finsh，开发时在串口终端敲 bt_debug play 就能播放，bt_debug volume 80 就能调音量，比单独写一个上位机省太多事。背后的套路是：调试通道先用串口打通，逻辑验证完再映射到蓝牙配对后的 A2DP 控制通道。

从那以后我每次拿到新板子，都强制先跑一遍文档里全部外设例程再动自己的业务逻辑——每个外设单独点亮花不了一小时，但能帮你避开至少一整天“外设没配好导致业务逻辑全错”的排查。做事先过一遍底层，这个习惯让我少踩了无数坑，希望这份实践指南也能帮你把蓝牙音频方案的开发周期缩短一半。

本文还有配套的精品资源，点击获取