杰理AC63串口收发实战：从初始化、中断到环形缓冲区与协议解析

简介面向嵌入式开发者的杰理AC63串口收发实例围绕SDK事件机制与底层UART驱动给出从消息预定义、SYS_DEVICE_EVENT事件响应到串口接收中断回调及DMA内存配置的完整实现思路适合需要快速上手杰理平台或移植串口通信逻辑的软硬件工程师参考。压缩包仅5KB包含3个文件其中有工程配置类文件、HTML说明页面和Git忽略规则文件结构精简适合在网页端或现有工程中快速查看要点。目前已有236人学习/下载。示例覆盖了my_rx_handler自定义接收解析、my_uart_init参数与DMA内存设置以及my_uart_putbyte、my_uart_write两种发送函数的实际用法并展示了直接在串口回调中处理数据包的灵活方式可帮助理解杰理SDK从硬件中断到系统事件通知的数据流转路径为二次开发提供可迁移的框架参考。 直接开整。干了这么多年嵌入式杰理这颗料是真没少玩。最近项目里用 AC63 做了一套从机通信模块把串口收发从头到尾捋了一遍。这芯片的 SDK 封装得挺隐蔽很多坑不踩一遍根本发现不了。这篇东西就是把我实际调通的代码和心路历程记录下来给后面接手 AC63 的朋友们做个参考。1. 项目背景与串口初始化前的准备工作1.1 AC63 平台的基本认知AC63 系列是杰理面向蓝牙音频市场推出的一颗 RISC-V 内核 SoC片上集成了蓝牙、音频 Codec、USB 和多个 UART。我最早接触这颗芯片是拿它做 TWS 耳机的充电仓方案后来发现它的 UART 资源够用就把它用在了一个需要和 MCU 通信的物联网网关里。要上手 AC63 的串口得先懂它的 SDK 框架。杰理提供的 SDK 里外设驱动被封装在dev_io和hal层不是说打开数据手册对着寄存器写就行而是要先搞清楚它的设备管理机制。和其他家芯片不一样AC63 的串口初始化不是直接调用uart_init而是先要配置dev_manager里的设备信息在某些 SDK 版本里还需要先注册设备。这个设计初看很绕但好处是后续可以用一套统一的接口去操作不同类型外设。另外一个要提前了解的点是 AC63 的时钟树。它的串口时钟源来自系统 APB 时钟APB 时钟又由系统 PLL 分频而来。SDK 默认把 CPU 频率跑在 120MHz 或 96MHz 左右但这不代表 APB 时钟就是同样的频率。我在配置波特率时发现如果直接按常见 ARM 芯片的做法去算分频值串口出来的波形频率会偏得离谱。后来我去翻了 SDK 里的clock.h才找到apb_clk的实际值。所以建议接手的兄弟拿到 SDK 后第一件事就是去board.c或者clock_config.c里确认系统时钟和 APB 时钟的频率配置。1.2 串口引脚复用与硬件连接AC63 的多组 UART 引脚并不是固定绑定而是通过 GPIO 复用映射。硬件上 UART0 默认接到了特定的 GPIO 上但如果你需要在别的引脚上引出串口就要改复用关系。我这里用的方案是 UART0但把 TX 和 RX 接到了自己扩展板上的两个引脚上。硬件工程那边一开始直接按照 SDK 默认引脚画的板子后来发现引脚冲突不得已改了一版。这里有个经验画板子之前SDK 里查引脚复用表确认好了再定网络名。连接方面要注意AC63 是 3.3V 逻辑电平虽然芯片支持 5V 容忍但串口通信对方如果也是 3.3V 就最稳。我之前试过直接对接 5V 的 TTL 串口模块短时间没事但长时间工作芯片发热明显。后来老老实实加了电平转换芯片或者用分压方式把 RX 引脚电压拉低这才彻底放心。如果是调试用的 USB 转串口工具选 CP2102 或者 CH340 都行但要注意共地不共地就会出现随机乱码的怪问题。2. 串口初始化配置细节与 CPU 中断关联2.1 UART 初始化配置参数SDK 里初始化串口的函数封装得比较深但核心参数是这几个波特率、数据位、停止位、校验位、流控。我用的配置是 115200、8 位数据、1 位停止位、无校验、无流控这是串口调试最通用的组合也是大部分上位机工具的默认参数。在 AC63 的 SDK 里初始化流程大概是先把设备 ID 和参数填到某个结构体里然后调用对应接口去打开设备。我用的是 SDP 工程里的接口直接调uart_baudrate_set和uart_configure。这里有个特别容易踩的坑就是初始化顺序。如果你先设波特率再设管脚复用有可能会因为管脚被别的外设占用而失败。我的建议是先配置 GPIO 复用为 UART 功能再设置波特率和其他参数最后打开终端使能收发。另外要注意的是AC63 SDK 里uart_init并不是一个全局唯一的初始化接口。在某些分支版本里你要先调用dev_io_ctl或uart_dev_open之类的接口先把设备“拉起来”然后再配置参数。网上有不少同学直接把其他平台串口配置代码搬过来结果编译不过去就是这个原因。这里的底层寄存器是 UART 控制寄存器组的组合配置。虽然 SDK 不鼓励我们直接写寄存器但在调试时通过 SDM 工具读取 UARTx_BAUDR 寄存器查看分频值有没有正确写入。实际测试发现当你设置 115200 波特率时寄存器里的分频值是 13余数是相应的小数部分。如果分频值计算有误波形频率就会偏。2.2 中断优先级与系统时钟的绑定性串口收发的中断处理是 AC63 工程里最容易被忽略的一块。SDK 的中断控制器把 UART 中断挂在某个中断线路上你要有对应的中断处理入口。不少新手在初始化串口时只开了收发但没在plic_irq_enable里使能 UART 中断导致程序没反应。申请中断优先级时要注意AC63 的中断优先级影响着蓝牙协议栈的实时性。我把 UART 中断优先级设成了比蓝牙栈任务略低一档防止串口中断频繁抢占导致蓝牙音频出现断断续续的现象。如果是纯数据转发场景优先级可以设高一些但也要给系统调度留出空间。芯片内部的中断处理是向量化的RISC-V 内核的中断跳转过程比较快但中断服务函数里尽量不要做耗时操作。我一开始在中断里直接调了系统打印函数结果一进中断就死机。后来把中断里的处理改成只写 FIFO其余逻辑全部丢到主循环去跑就稳定多了。这种设计思路是所有嵌入式平台通用的但在 AC63 这种低主频、单核处理器上尤其重要。3. 源码解析与收发逻辑实现3.1 最简单的查询式收发实现做项目验证功能时先写一个最朴素的查询式收发。这段代码能通基本就说明硬件连接和初始化没问题了。#include uart.h #include gpio.h #include clock.h // UART0 引脚复用配置具体引脚需根据实际硬件连接修改 void uart_gpio_init(void) { gpio_set_fun(GPIOA5, GPIO_FUN_UART0_TX); gpio_set_fun(GPIOA6, GPIO_FUN_UART0_RX); } void uart_query_loop(void) { u8 ch; uart_baudrate_set(0, 115200); uart_configure(0, UART_CONFIG_8N1); uart_open(0); while (1) { if (uart_get_byte(0, ch) 0) { uart_put_byte(0, ch); } } }这个循环的本质是不断去查询接收 FIFO 是否有数据。uart_get_byte返回值是 0 表示成功拿到一个字节。这个接口在底层会去判断数据寄存器非空标志位如果标志没置位就直接返回错误码。这是典型的“查询接收”模式好处是逻辑简单坏处是 CPU 全被占住了什么别的活都干不了。如果是调试用问题不大。如果是真实产品里的通信功能建议看下面的中断加缓冲区方案。在测试这段代码时还有一个体验很关键的是波特率要匹配。上位机用 115200 打开串口如果发“hello”收到“ello”或者乱码基本就两个方向波特率不匹配或者 RX/TX 接反了。先用示波器看 TX 脚有没有正常波形再用逻辑分析仪看波形的实际波特率这是排查手法的第一步。3.2 中断加环形缓冲区的高效收发实现实际产品里串口数据往往是突发式的频率不定、长度不定。查询方式不仅浪费 CPU还容易丢数据。我在 AC63 上采用的是“中断接收 环形缓冲区”的方案。#define UART_RX_BUF_SIZE 256 static volatile u8 uart_rx_buf[UART_RX_BUF_SIZE]; static volatile u16 rx_head 0; static volatile u16 rx_tail 0; // 中断服务函数不同 SDK 版本的注册方式不同 void uart0_irq_handler(void) { u8 dat; u16 next; while (uart_get_byte(0, dat) 0) { next (rx_head 1) % UART_RX_BUF_SIZE; if (next ! rx_tail) { uart_rx_buf[rx_head] dat; rx_head next; } // 如果 next rx_tail说明缓冲区满了直接丢弃新数据 } } // 从缓冲区读取一帧数据返回实际读取的字节数 u16 uart_rx_read(u8 *dest, u16 len) { u16 cnt 0; while (rx_tail ! rx_head cnt len) { dest[cnt] uart_rx_buf[rx_tail]; rx_tail (rx_tail 1) % UART_RX_BUF_SIZE; } return cnt; }这个代码里面有个关键设计是环形缓冲区的头尾指针。rx_head指向下一个要写入的位置rx_tail指向下一个要读出的位置。当两者相等时缓冲区是空的。当(rx_head 1) % SIZE rx_tail时缓冲区是满的。这里故意留了一个空位来区分“空”和“满”这是经典做法。在中断处理函数里我用了while循环连续读取 FIFO。这样做的好处是只要 FIFO 里还有数据就一次性全部搬进缓冲区内。如果不这样做而是每次中断只收一个字节那么在高速连续发数据时频繁进出中断会占用大量 CPU 时间而且有可能在退出中断前又有新数据进来产生重复触发。用这种一次性耗尽 FIFO 的方式能有效降低中断频率。这段代码能稳定工作的前提是中断服务函数里不能有任何阻塞操作。我见过有的同事在中断里调用printf做调试结果系统直接卡死。原因很简单printf在 AC63 的 SDK 里可能没有做重入保护一旦在中断上下文被调用就会和主循环里的打印产生竞争最终死锁。所以调试输出放到主循环里做或者用一个专门的调试标志位把从缓冲区读到的数据带出来打印。3.3 主循环里的协议帧解析缓冲区解决了“数据不丢”的问题但串口收到的字节流如果没有帧格式还是没法用。通信双方得约定好一帧数据的起始标志、长度信息和校验方式。项目里我用了最简单的协议格式帧头0xAA 0x55 长度1 字节 数据N 字节 校验1 字节累加和。#define FRAME_HEADER1 0xAA #define FRAME_HEADER2 0x55 #define MAX_FRAME_DATA_LEN 64 typedef struct { u8 data[MAX_FRAME_DATA_LEN]; u8 len; u8 sum; } frame_t; static frame_t rx_frame; static u8 frame_index 0; static u8 expect_len 0; // 返回1表示解析到一帧完整数据 u8 protocol_parse_byte(u8 byte, frame_t *out_frame) { u8 i; if (frame_index 0) { if (byte FRAME_HEADER1) { frame_index 1; } return 0; } else if (frame_index 1) { if (byte FRAME_HEADER2) { frame_index 2; } else { frame_index 0; // 没等到第二个帧头重新同步 } return 0; } else if (frame_index 2) { expect_len byte; if (expect_len 0 || expect_len MAX_FRAME_DATA_LEN) { frame_index 0; // 长度非法重新同步 return 0; } frame_index 3; return 0; } else if (frame_index 3 expect_len) { rx_frame.data[frame_index - 3] byte; frame_index; if (frame_index 3 expect_len) { // 最后一个字节是累加和先暂存等下一字节校验 frame_index; } return 0; } else if (frame_index 3 expect_len) { rx_frame.sum byte; // 校验累加和从长度字节开始累加 rx_frame.len expect_len; { u8 check 0; for (i 0; i rx_frame.len; i) { check rx_frame.data[i]; } if (check rx_frame.sum) { *out_frame rx_frame; frame_index 0; return 1; } else { frame_index 0; return 0; } } } return 0; }这段状态机解析的代码用了frame_index来标记当前处在帧的哪个位置。每收到一个字节就喂进这个状态机。如果返回 1说明收完整的一帧了可以交给业务层去处理。协议设计里有个细节是校验和的范围要写明确。我这里的累加和是从长度字节到数据末尾全部加起来不包含帧头两边保持一致即可。对于异常处理当第二个帧头没匹配上时直接把状态机重置让下一个字节重新作为帧头候选。这是最简单的“字节级同步”复位方法。如果想做更强壮的容错可以在第二个帧头不匹配时把当前字节回退到第一个帧头的判断逻辑里这样能避免字符丢失导致的整帧不同步。不过对于大多数传感器上报、控制指令场景直接复位已经够用。3.4 实际联调效果与代码占用量把上面这些代码整合到 AC63 工程后我做了个简单的回环测试上位机每 100ms 发送一帧 10 字节的随机数据AC63 解析后把数据原样返回。测试跑了一整夜统计了丢帧率是 0波特率 115200 下接收 256 字节突发数据也没有溢出。这个结果说明了中断加环形缓冲区方案的稳定性也说明 AC63 在 115200 波特率下的处理能力绰绰有余。内存方面这段代码在 AC63 上整体占用很小。UART 的 FIFO 本身有硬件缓冲我的软件环形缓冲区占 256 字节再加上几个全局变量和解析用的结构体总共不到 400 字节 RAM对于 AC63 的 RAM 容量来说完全是九牛一毛。Flash 占用主要来自 UART 驱动和中断向量这部分是 SDK 固定开销代码本身只增加了几百字节。4. 调试工具链与疑难问题排查实录4.1 调试波形与数据格式验证串口调不通时光看逻辑代码是不够的必须用工具验证物理层的波形。我手头的调试设备是逻辑分析仪和示波器推荐至少备一个逻辑分析仪几十块钱的那种就能用。用逻辑分析仪抓串口波形时采样率要设置成波特率的 4 倍以上比如 115200 波特率建议采样率至少 500k不然恢复出来的波形会变形。分析仪抓出来的波形应该能看到低电平起始位、8 个数据位、高电平停止位。如果波形宽度不对算一下实际波特率。比如协议分析仪测出实际波特率是 115385差异在 0.16% 以内没问题。如果测出来是 115200说明分析仪采样率不够或者触发设置有问题。示波器看波形就更加直观重点看 TX 引脚在空闲时是不是高电平发送数据时有没有明显的拉低脉冲。我遇到过一次波形显示 TX 一直为低原因是 GPIO 复用配置没有生效引脚被内部下拉了。这种问题光靠看代码很难发现用示波器一眼就能定位。4.2 Vofa 等上位机工具的配合使用热词里提到的 Vofa 是个很好用的串口波形上位机工具很多做电机控制、传感器采集的同事常用。它直接读取串口数据然后以波形方式显示也可以当成普通串口调试助手来发送十六进制帧。和我写的协议解析代码配合验证工作变得很直观。用 Vofa 的 FireWater 协议时上位机会按value1,value2,value3\n这样的 ASCII 行来解析数据。如果串口发的是二进制数据要先用“串口透传”功能或者改成 JustFloat 协议不然显示出来的就是乱码。所以在协议设计阶段就要想清楚上位机用的是哪种格式我就是一开始没注意二进制帧被 Vofa 按 ASCII 解析折腾了好一阵。Vofa 对于调试波形类数据特别好使但我这里做的是帧格式通信还是更依赖逻辑分析仪来验证底层时序。工具选型要看场景不是越智能越好。4.3 常见问题速查表我在实际调试中遇到的问题总结成一张速查表后面遇到类似情况直接对着查。现象可能原因排查方法串口完全无输出GPIO复用未配置或配置错误检查引脚复用函数用示波器测TX脚电平变化数据乱码波特率不匹配、APB时钟频率不对核对APB时钟值用逻辑分析仪测实际波特率偶尔丢字节未用中断接收、缓冲区溢出改用中断加环形缓冲区方案一进中断就死机中断里调了阻塞函数或打印中断里只做数据搬运不做逻辑处理首个字节收不到帧同步逻辑太严格检查帧头设计适当放宽同步策略长时间运行后卡死缓冲区头尾指针越界确认取模逻辑检查是否在中断里修改了尾指针4.4 波特率偏差的进阶排查还有一个值得单独拎出来讲的问题就是波特率偏差。AC63 的 UART 波特率生成器是从 APB 时钟分频得到的如果 APB 时钟不是整数倍关系最后得到的波特率会有偏差。比如 APB 时钟是 60MHz想要 115200 波特率分频系数应该是 520.833但硬件只能取整数实际的波特率就有偏差。这个偏差在短帧传输时问题不大但传长帧时累加误差会导致最终字节错位。排查时不要只看首字节对不对要发一串长数据比如 100 字节然后看中间和末尾的字节对不对。如果越到后面越乱基本就是波特率偏差问题。解决办法有几个方向一是换一个能整除的 APB 时钟源二是在 SDK 的uart_baudrate_set里传入微调参数三是调整通信协议把单帧长度控制在合理范围内。我用的是第三种方案把协议的最大数据长度限制在 64 字节这样即使有轻微偏差在 115200 波特率下也不至于出错。4.5 Flash 读写与串口交互的联动避坑项目里串口收发不是单独工作的我还碰到了串口和 Flash 读写叠加的任务。比如上位机下发一段升级数据AC63 收到后要写入 Flash。这里有个容易踩的坑是 Flash 写入耗时较长在此期间如果串口中断还在接收数据缓冲区可能溢出。解决思路是在 Flash 擦写期间关掉串口接收中断或者先把数据整帧收到 DDR 里的另一个缓冲区再统一写入 Flash。我采用的方式是先收完一整帧CRC 校验通过后再关中断进入 Flash 擦写。擦写结束后再开中断继续接收后面的数据。这里要注意的是关中断时间不能太长否则一直发数据的一方会判断超时。另外Flash 写入后读取校验也是必须的。我在写入完成后把刚才写的内容整体读出来和原始数据比对不一致就返回错误码提示上位机。这个做法虽然多花了点时间但能避免“以为写成功、实际断电丢数据”的问题。5. 关键操作要点与避坑心得5.1 核心经验总结把这次 AC63 串口收发做完有几个核心经验值得记下来第一拿到陌生 SDK先看系统时钟配置再看外设驱动接口最后才是功能逻辑。顺序搞反了后面会花大量时间在错误方向上排查。第二中断服务函数里只做数据搬运别做逻辑判断和阻塞操作。这是嵌入式开发的铁律在 AC63 上尤其明显因为它的整体架构面对蓝牙音频任务时 CPU 资源很紧张。第三环形缓冲区是实现稳定串口收发的地基。不管协议怎么变这个结构都能兜住底层数据流不会因为上层处理慢而丢数据。缓冲区大小要根据最大突发数据量来定宁可多留一点也不要卡着边界算。第四通信协议一定要有帧头、长度、校验三个要素。简单场景用累加和就够了复杂场景可以换 CRC16。没有校验的通信就是裸奔数据错了都不知道。5.2 串口收发扩展场景的延伸串口收发这层打通之后能做的事情就很多了。AC63 的蓝牙能力加上串口可以直接做蓝牙透传模块手机通过 BLE 发送数据给 AC63AC63 通过串口转给外部 MCU。反过来外部 MCU 通过串口发数据给 AC63AC63 再通过 BLE 上报给手机。这种应用在智能家居、运动器材、医疗设备里都很常见。从串口数据量上看BLE 的传输速率上限大约是几十 Kbps和 115200 波特率串口差不多所以中间基本没有瓶颈。关键是要做好流量控制不能让串口数据往蓝牙侧灌太快否则蓝牙缓存会溢出。可以在串口解析到完整一帧后通过一个“可发送”标志位来控制蓝牙发送节奏。另外AC63 的多个 UART 是可以同时使用的。比如一路 UART 接蓝牙模块一路 UART 接传感器通过一个任务把两路数据互相转发。这就像搭积木一样底层驱动做好了上层应用就是自由组合的事了。如果你手头的项目正好有这类需求建议先把单路串口收发彻底调通再扩展第二路不要一开始就搞多路并行否则排查问题时会无从下手。本文还有配套的精品资源点击获取