GD32 IAP实战：串口Ymodem固件升级与Bootloader设计指南

GD32 IAP实战：串口Ymodem固件升级与Bootloader设计指南

发布时间：2026/9/27 2:48:44
GD32 IAP实战：串口Ymodem固件升级与Bootloader设计指南 1. IAP到底是个什么玩法先搞懂bootloader和App的分工做嵌入式开发多年我越来越觉得IAPIn-Application Programming是量产产品绕不开的坎。前几天一个朋友做GD32F303的项目样机都发给客户试用了结果发现一个协议bug只能寄回来用J-Link重新烧来来回回折腾了好几天。那一刻他就问我能不能直接在设备上通过串口升级固件我说这就是典型的IAP应用场景。IAP说白了就是让设备自己在运行过程中更新自己的Flash程序区。固件被划分成两个部分一个是bootloader一个是真正的应用App。bootloader负责启动和接收新固件App才是干正经活的程序。系统上电先跑bootloader由它决定是直接跳转App还是进入升级流程这个机制和电脑上的BIOS非常像。电脑装系统要先进入BIOS引导再从U盘安装Windows嵌入式设备就是这个思路的缩小版。GD32是国产ARM Cortex-M系列主力芯片之一和STM32引脚兼容、库函数风格接近但在Flash烧写细节、启动文件、选项字节这类底层操作上和ST是有差异的。直接用STM32那套代码移植过来极有可能踩坑。我在后面会讲到GD32独有的坑点。这个项目适合什么人参考正在做GD32产品开发、想给设备加上远端升级能力的工程师或者刚接触bootloader、想系统理解IAP机制的同学。我们的目标是看完整篇文章之后你能自己写出一个可用的串口Ymodem升级方案知道每一步在干什么出了问题知道怎么排查。我先给整个系统画个逻辑蓝图不用工具你在脑子里理解即可芯片上电 → 进入bootloaderbootloader检查是否有升级请求比如串口收到固定命令、某个按键按下、某个标志位被置位有升级请求通过串口Ymodem协议接收固件 → 写入App区Flash → 校验通过后跳转App无升级请求直接检查App区是否有有效程序有则跳转无则原地等待升级这个流程决定了bootloader必须短小精悍、稳定可靠因为一旦bootloader坏了整个设备就变砖了。2. 为什么选串口Ymodem协议选型的逻辑和依据2.1 先聊聊Ymodem是什么以及它和Xmodem的区别串口传输文件业界最经典的协议族是Xmodem/Ymodem/Zmodem。Xmodem是128字节一包协议简单但要每包都确认吞吐量低下。Zmodem功能最全、支持断点续传但实现复杂度高而且很多串口工具对Zmodem的支持不如Ymodem顺手。Ymodem是中间平衡点单包最大1024字节支持文件名的传输CRC校验强度足够大部分串口调试助手都内置支持。我选Ymodem的原因很实在。第一几乎所有串口工具都带Ymodem发送功能SecureCRT、Xshell、Mobaxterm、SSCOM、XCOM都有现场工程师不需要额外学习就能操作。第二Ymodem在STM32/GD32生态里的参考实现很多出了问题容易找到资料。第三1024字节包传输效率比Xmodem的128字节高很多实测下来115200波特率传100KB固件也就十几秒完全能接受。2.2 Ymodem协议帧格式看懂这个代码就有了一半Ymodem是半双工、握手式协议。它有两类帧数据帧和结束帧EOT通知。数据帧的格式如下SOH/STX0x01表示128字节包0x02表示1024字节包序号1字节从0x00开始每发一包加1循环256后归零序号反码1字节0xFF - 序号数据128或1024字节不足部分用0x1A填充满CRC16高字节、低字节校验前面所有字节含SOH/STX、序号、序号反码、数据段传输的完整流程是这样接收方我们的bootloader先发送字符C表示准备好了要求对方用CRC校验发送方收到C后先发送一个包含文件名的数据帧块号0接收方校验通过后回复ACK发送方开始发送块号1、2、3……的数据帧所有数据发送完成后发送方发送EOT接收方回复NAK表示等第二个EOT发送方再次发送EOT接收方回复ACK然后发送C发送方发送一个结束帧块号0数据长度0接收方回复ACK后整个传输结束注意第6步和第7步的二次EOT确认机制很多新手栽在这里只处理一次EOT就直接判断结束结果最后一包数据还没落盘就跳走了。2.3 波特率怎么选不是越高越好我在115200和460800之间都做过测试。115200传128KB固件大约15~20秒虽然不算快但稳定性最好稍微有点干扰也不会断。460800速度快了三倍但对环境噪声、USB转串口硬件质量的要求明显提高我曾经在一块劣质USB转TTL模块上测试460800波特率几乎必出CRC错误。我的建议是量产产品保守起见用115200现场升级时间多等几秒不是问题稳定压倒一切。如果确实要快至少用FTDI或者CP2102这类有口碑的USB转串口芯片不能用那些几块钱的CH340山寨货跑高速。3. GD32的IAP工程分区与内存规划3.1 Flash布局bootloader、App、标志位要各归其位GD32F303系列的主Flash起始地址是0x08000000容量最高可达256KB页大小2KB不同型号有差异务必查对应的数据手册。我的分区规划如下区域起始地址大小说明Bootloader区0x0800000032KB0x8000存放bootloader程序App区0x08008000最大192KB存放应用程序标志位区0x0803F8002KB存放升级标志、升级结果状态Bootloader给32KB其实是偏保守的。Ymodem接收Flash写操作代码量大约10~15KB就搞定留32KB是为了后续扩展方便比如增加多协议支持、双bank切换等高级功能。App偏移0x08008000这个值不是随手拍的。GD32F303的页大小为2KB0x8000就是16页既满足了bootloader空间又对齐Flash页边界擦除操作都是以页为单位对齐边界可以避免意外的越界擦除。App区最大限制在192KB这个边界确保了标志位区不会被App的代码所覆盖。3.2 为什么需要标志位区升级控制的入口很多初学IAP的人把升级请求做成“上电后先等1秒看看串口有没有命令”这种做法简单但有两个问题一是每次上电都延时影响启动速度二是如果串口被占用做别的功能逻辑会互相干扰。我的方案是单独分配2KB的Flash页作为标志位区。bootloader启动后先读这个区域如果发现有升级标志就进入升级流程如果没有直接跳转App。这个标志位可以使用一个固定的魔数比如0xA5A5A5A5每次升级前把魔数写入标志位区升级完成后清除。实际使用中触发升级的方式有几种都指向同一个动作写入魔数软复位App内通过串口命令触发升级配合手机App通过蓝牙/WiFi下发升级指令甚至在设备上增加一个物理按键或拨码开关3.3 中断向量表最容易踩的坑STM32有SCB-VTOR寄存器来重定位向量表GD32F303同样具备。但我在网上看到很多GD32教程直接照搬STM32代码把中断向量表重定向后App就是跑不起来就是因为没注意到GD32库函数的差异。GD32标准固件库中中断向量表重定位的代码是这样的nvic_irq_enable(USART0_IRQn, 0, 0); // 你需要先开启某个中断才会初始化VTOR准确说关键操作是设置VTOR寄存器地址SCB-VTOR APP_START_ADDR; // APP_START_ADDR 0x08008000但这个操作必须在App启动的极早期完成最好在main函数的第一行就做。如果你用了GD32的启动文件startup_gd32f30x.s启动流程里会先调用SystemInit再调用main。SystemInit里会初始化中断向量表基址所以App里需要检查一下SystemInit有没有把VTOR改掉。在IAR开发环境下还可以通过在icf链接脚本里定义__ICFEDIT_intvec_addr__来直接指定向量表地址这样能够确保上电后第一件事就是从正确的位置取向量。但Keil MDK没有这么直接的工具需要额外在启动文件里定义一段位置无关的向量表拷贝代码。4. Bootloader代码实战从框架到实现4.1 Bootloader主流程框架整个bootloader结构并不复杂我把核心代码框架写出来然后逐一解释每一部分的作用。#include gd32f30x.h #include ymodem.h #include flash_iap.h #define APP_START_ADDR 0x08008000 #define APP_FLAG_ADDR 0x0803F800 #define UPGRADE_FLAG 0xA5A5A5A5 void check_and_jump_app(void); void jump_to_app(uint32_t app_addr); void clear_upgrade_flag(void); int main(void) { // 1. 初始化系统时钟、串口等外设 systick_config(); uart0_init(115200); // 2. 检查升级标志 if (*(volatile uint32_t *)APP_FLAG_ADDR UPGRADE_FLAG) { // 有升级请求开始Ymodem接收 ymodem_receive(); // 接收完成清除升级标志 clear_upgrade_flag(); } else { // 无升级请求直接跳转App check_and_jump_app(); } // 3. 如果App无效会回到这里继续等待升级 while (1) { // 反复向串口发送C等待主机开始Ymodem发送 ymodem_receive(); } }这个流程的逻辑很清晰。上电读取标志位有则进入升级没有就尝试跳转App。ymodem_receive()内部是个阻塞式的状态机一直接收直到整个文件传完或超时退出。4.2 跳转App的细节寄存器、堆栈和中断要处理干净跳转App是整个IAP里最微妙的操作代码很短但每一个微小的失误都会导致系统崩溃。这里给出一个经过车间多轮测试的跳转函数typedef void (*app_entry_t)(void); void jump_to_app(uint32_t app_addr) { uint32_t app_sp; app_entry_t app_entry; uint32_t i; // 1. 从App的0地址读取初始堆栈指针从地址4读取复位中断入口 app_sp *(volatile uint32_t *)app_addr; app_entry (app_entry_t)(*(volatile uint32_t *)(app_addr 4)); // 2. 检查堆栈地址是否在RAM范围内防止野指针跳飞 // GD32F303 RAM从0x20000000开始192KB/256KB不等 if ((app_sp 0x2FFE0000) ! 0x20000000) { return; // 无效App不要跳转 } // 3. 跳转前关闭全局中断并清除中断标志防止残留中断跳到旧的中断服务函数 __disable_irq(); // 4. 重新设置系统时钟为默认状态避免App工作在不同时钟配置下出错 // (这一步由你的具体时钟树决定很多App会自己重新配置时钟) // 5. 设置主堆栈指针为App的初始堆栈 __set_MSP(app_sp); // 6. 跳转到App的复位向量 app_entry(); // 7. 正常情况下永远到不了这里 while (1); }这里有几个关键的细节别人写文章很少讲但每个都能让App跑飞第一全局中断必须关。跳转瞬间如果来一个中断PC已经切到App环境但中断向量表还没来得及切过去就会跳到bootloader的地址去执行必死。第二堆栈地址检查。App区的第一个32位字是初始堆栈地址正常范围应该在RAM区间内。加个检查能防止App区没烧录全0xFF时跳到一个疯狂地址。第三最好在跳转前把所有的外设复位一下。因为bootloader初始化了串口、定时器等跳转过去后这些外设可能还保留中断请求App并不知道这些状态极容易出现串口进中断死循环或者别的诡异现象。简单粗暴的做法是调用系统复位函数让MCU重新跑一遍NVIC_SystemReset();复位之后从bootloader重新启动依然按照标志位判断此时升级标志已经被清除就会自然跳转App。这个方案我实际测试过稳定性比“直接改PC”还要高缺点是多花几十毫秒的复位时间完全可以接受。4.3 Ymodem核心状态机代码示例与逐行解析Ymodem接收端的状态机是整个bootloader的灵魂。我直接给一个精简但可用的实现并标注关键分支#include ymodem.h #include flash_iap.h #include bsp_uart.h #define PACKET_SIZE_128 128 #define PACKET_SIZE_1024 1024 #define ACK 0x06 #define NAK 0x15 #define EOT 0x04 #define SOH 0x01 #define STX 0x02 #define CRC_REQUEST 0x43 // C static uint8_t rx_buf[1100]; static uint32_t flash_write_addr; static uint32_t file_size 0; static uint32_t total_recv 0; static uint8_t crc16_high(uint8_t *ptr, uint32_t len) { uint16_t crc 0; for (uint32_t i 0; i len; i) { crc crc ^ ((uint16_t)ptr[i] 8); for (uint8_t j 0; j 8; j) { if (crc 0x8000) crc (crc 1) ^ 0x1021; else crc crc 1; } } return (crc 8) 0xFF; } static uint8_t crc16_low(uint8_t *ptr, uint32_t len) { uint16_t crc 0; for (uint32_t i 0; i len; i) { crc crc ^ ((uint16_t)ptr[i] 8); for (uint8_t j 0; j 8; j) { if (crc 0x8000) crc (crc 1) ^ 0x1021; else crc crc 1; } } return crc 0xFF; } void ymodem_receive(void) { uint8_t ch; uint8_t seq 0; uint32_t len 0; uint8_t state 0; uint8_t eot_count 0; flash_write_addr APP_START_ADDR; total_recv 0; file_size 0; // 发送CRC请求进入等待状态 uart_send_byte(CRC_REQUEST); while (1) { if (uart_receive_byte_timeout(ch, 1000) 0) { // 超时处理重置状态机 state 0; seq 0; uart_send_byte(CRC_REQUEST); continue; } switch (state) { case 0: // 等待SOH/STX if (ch SOH) { len PACKET_SIZE_128; state 1; } else if (ch STX) { len PACKET_SIZE_1024; state 1; } else if (ch EOT) { // 收到EOT第一次回复NAK等第二个EOT eot_count; if (eot_count 1) { uart_send_byte(NAK); } else if (eot_count 2) { uart_send_byte(ACK); uart_send_byte(CRC_REQUEST); state 3; // 等待最后的结束帧 } } break; case 1: // 接收序号和序号反码 // 忽略了序号反码校验简化处理实际工程强烈建议检查 seq ch; state 2; break; case 2: // 接收数据 CRC for (uint32_t i 0; i len 2; i) // 数据2字节CRC { if (uart_receive_byte_timeout(ch, 2000) ! 0) { // 接收失败复位状态 state 0; break; } rx_buf[i] ch; } // 只剩CRC校验未验证这里检查 { uint8_t crc_h crc16_high(rx_buf, len 2 1); // 注意偏移 uint8_t crc_l crc16_low(rx_buf, len 2 1); if (crc_h rx_buf[len] crc_l rx_buf[len 1]) { // CRC校验通过 if (seq 0) { // 处理文件名或其他附加信息 // 实际的Ymodem首包前128字节包含文件名和文件大小 // 下面的file_size是从数据里解析出来的 parse_filename_packet(rx_buf, file_size); uart_send_byte(ACK); uart_send_byte(CRC_REQUEST); state 0; continue; } else { // 数据包写入Flash flash_write(flash_write_addr, rx_buf, len); flash_write_addr len; total_recv len; uart_send_byte(ACK); state 0; } } else { // CRC错误回NAK请求重发 uart_send_byte(NAK); state 0; } } break; case 3: // 等待结束帧块号0数据长度0 if (ch SOH) { // 收到结束帧头一次性读完一个128字节的包 // 完整检测序号为0且数据全空然后回ACK表示完成 state 4; } break; case 4: // 读完整结束帧回ACK并结束 uart_send_byte(ACK); // 此时整个文件接收完成 // 可以做一个总文件大小的校验 goto done; break; } } done: // 接收完成设置App的有效性标志或者直接返回 return; }这段代码做了一些简化比如没有严格校验序号反码没有做每包超时的精确计时但整体框架是完整可跑的。实际工程上我会在这个基础上增加以下细节序号反码校验出现不一致立即发NAK文件大小的校验接收完成后对比file_size和total_recv不一致则报错超时计数器连续N次超时后跳出升级流程并给出错误指示灯4.4 GD32 Flash驱动编写擦写函数时必须知道的寄存器细节GD32F303内部Flash驱动标准固件库里提供了fmc_erase_page、fmc_word_program等接口但在IAP场景中直接调用有几个需要注意的地方第一擦写Flash时要先解锁。GD32的Flash控制器有锁机制需要执行fmc_unlock();第二擦除以页为单位。GD32F303一页2KB计算要擦除哪些页时注意边界对齐。比如App从0x08008000开始256KB型号的最后地址是0x0803FFFF所以Bootloader要擦除0x08008000到0x0803F800之前的所有页。第三写操作按32位字写入。写一个字节需要读改写效率低还容易出错。我在写Ymodem接收的缓冲区时直接把缓冲区凑成32位对齐然后用word方式写入速度和正确性都更好void flash_write_buf(uint32_t addr, uint8_t *buf, uint32_t len) { uint32_t i; uint32_t word_data; // 确保len是4的倍数Ymodem包长128或1024天然满足 for (i 0; i len; i 4) { word_data (uint32_t)buf[i] | ((uint32_t)buf[i1] 8) | ((uint32_t)buf[i2] 16) | ((uint32_t)buf[i3] 24); fmc_word_program(addr i, word_data); } }第四FMC操作完后要锁定fmc_lock();5. App侧改造配合bootloader让固件能自适应升级App程序的改动没有bootloader那么大但有一个地方不改就不能正常工作中断向量表。以GD32F303标准库工程为例App工程需要做三件事第一修改编译链接配置把代码起始地址改为0x08008000。在Keil中Options for Target → Target → IROM1里把起始地址Start改成0x8000大小改成0x38000或者你的App最大编译结果。如果是IAR则在icf链接脚本里修改ROM起始地址。第二在main函数最开始重定位中断向量表int main(void) { SCB-VTOR 0x08008000; // 指向App自己的向量表 // 然后才是余下的初始化时钟、GPIO、串口、外设等 ... }注意这句代码必须在任何中断使能之前执行否则中断有可能在向量表还没切换的时候就来了。最好的位置是在SystemInit之后、所有外设初始化之前。第三是软件触发升级的机制。我将它设计成一个串口命令协议上位机发送$UPGRADE#App收到命令后在标志位区写入0xA5A5A5A5然后执行NVIC_SystemReset()复位后bootloader检测到标志自动进入升级流程这个命令的实现实际上就是void enter_bootloader_mode(void) { uint32_t regs[8]; // 写标志位 fmc_unlock(); fmc_word_program(APP_FLAG_ADDR, UPGRADE_FLAG); fmc_lock(); // 复位 NVIC_SystemReset(); }这里给个实际调试经验写标志位时建议在写之前先检查当前值是不是已经是魔数如果是就不用重复写了因为Flash写操作对同一地址重复写即使数据相同也有可能触发状态寄存器告警。6. 编译烧录与整体联调从烧录Boot到最终实现整机升级6.1 编译环境选择GD32 Embedded Builder还是Keil MDKGD32官方主推的IDE是GD32 Embedded Builder基于Eclipse内置GCC工具链配合官方提供的库函数模板建工程很快。但个人建议是如果公司已有的工程都是Keil ADC工程那就直接继续用Keil MDK通过GD32官方Pack包支持F303系列这样IAP改造的差异集中在Flash分区和链接脚本。我实际测试过同一个bootloader工程Keil编译后大约11KBGCC编译后约13KB差异不大。关键是启动文件不同。Jedec风格启动文件稍有差异跳转函数要适配。使用标准库的老工程启动文件一般已经适配好了不用动。6.2 第一次联调先烧Boot再烧App步骤一编译bootloader工程生成HEX文件用GD-Link或者J-Link烧写到芯片。默认烧写地址就是0x08000000开始无需额外配置。步骤二烧App。这里有一个大坑如果直接在Keil里按F8下载App默认是按0x08000000地址下载的会把bootloader覆盖掉。必须把Keil里的Flash Download的起始地址改成0x08008000或者直接通过命令行工具生成App的HEX文件再单独烧写。我推荐的方案是调试阶段bootloader用调试器烧App同样用调试器烧但把起始地址改为App偏移。出厂阶段用一个合并脚本把bootloader和App的HEX合并成一个完整HEX一次性烧录。步骤三先用串口助手发$UPGRADE#指令测试远程升级。App收到命令后复位进入bootloader然后串口助手里选择XMODEM/YMODEM发送功能选择编译好的App bin文件观察升级过程。6.3 烧录地址和偏移量的常见错误最终可能导致变砖联调时最容易犯的错误就是地址错乱。常见情况如下只改了IROM1起始地址没有改中断向量表重定位。结果App上电后发生HardFaultbootloader和App地址重叠。比如bootloader是32KB0x8000但App编译结果超过了192KB超出了分区边界合并HEX时两个文件在地址上有空洞生产烧录后App区全空或部分为空这些问题我全都踩过。我的建议是在bootloader里加入App区CRC或者简单的栈指针有效性检查。发现无效就反复等待串口升级而不是盲目跳转把“变砖”概率降到最低。7. 实战中遇到的典型问题与排查速查表最后把这几年做IAP调试踩过的坑系统整理一下。这些问题是群里面被问得最多的每一个都对应真实案例。现象可能原因排查思路上电后串口不输出C串口初始化失败、时钟配置不对、bootloader没烧进去先确认烧录地址再查芯片晶振是否起振能收到C但发送文件后一直NAKCRC算法不一致、波特率过高有误码用逻辑分析仪抓串口波形确认bit时序Ymodem传完但是跳转App后黑屏App中断向量表没重定位、跳转前外设没处理干净在App的main函数里点亮LED调试确认是否进入了main传文件中途经常超时串口缓冲区太小、波特率过高、上位机工具卡顿换SecureCRT重新测试扩大接收缓冲区App可以正常运行但触发升级后卡死标志位没写成功、App中断向量表与bootloader冲突bootloader里加LED指示确认是否进入升级分支烧录之后整个芯片无法连接调试器Flash地址重叠导致boot或App区损坏用J-Link连接时按住复位键或使用GDLINK强制连上执行全片擦除7.1 案例复盘跳转App后死机的排查全过程我自己的一个实际经历是在GD32F303上做完IAP后跳转App总是不到一秒钟就HardFault。排查过程是这样第一步我在App的main函数最开始点亮一个LED发现灯能亮说明跳转成功进入了App的main。第二步我在App里初始化了一个定时器中断。灯刚亮打开中断的一瞬间就死了连配置打印都没走到。第三步检查SCB-VTOR发现是0x08000000。问题确认App编译器在main函数之前使用了标准库函数把VTOR又重置回默认值了。解决办法有两个一是直接在启动文件的复位向量里第一行就把VTOR改写二是把VTOR重定位写在main函数的最开头并且在链接脚本里确保所有中断向量都映射到App区。最终我在启动文件的Reset_Handler里加了一句LDR R0, 0xE000ED08 LDR R1, 0x08008000 STR R1, [R0]这样跳转过来后第一件事就是切向量表后续任何中断进来都是走App的向量问题彻底解决。7.2 使用虚拟串口和串口监听辅助调试联调时我强烈建议在你和目标板之间串一个“串口监听工具”比如用PC的VSPD虚拟串口或者硬件方案用USB转双串口转接把上行和下行的数据全部记录下来。很多时候你以为Ymodem的CRC计算出了问题实际上查看监听数据发现是上位机发的包长度不对、或者包序号重复了。当你看到双方交互的帧数据之后协议层面的错误90%都能定位到。记住看不到数据流的调试都是盲人摸象。7.3 批量生产时的升级策略产品进入量产阶段IAP的玩法就不只是“电脑连串口升级”这么简单了。常见的扩展方向有三个配合WiFi模块做局域网OTA后台推包设备对接MQTT服务器通过云平台远程下发指令进行升级手机上通过蓝牙/串口调试App完成升级无论哪一种底层Ymodem收包和Flash写入逻辑都是完全一样的变的只是数据来源。我这边已经把这些代码封装成了一个独立的层串口、蓝牙、WiFi只需要提供读写字节的函数上层协议完全不用管。这个思路建议你在实际项目中参考一开始就把传输层和协议层解耦后面省事得多。8. 写在最后GD32 IAP的经验沉淀整套系统跑通之后有几点体会特别深第一IAP的关键难点不是“跑通”而是“跑稳”。跑通只需要实现Ymodem、写Flash、跳转三件事而跑稳意味着你要考虑跳转前的中断清理、App区有效性检查、Ymodem超时重传、Flash擦写保护、升级失败回退这些东西才是量产产品真正需要的。第二Ymodem协议看起来简单但实际调试时CRC表的位数、处理EOT的时机、缓冲区溢出的边界条件这些小细节能消耗你一整天。建议先在PC上用串口助手自带功能收发小文件验证协议再去处理App的实现。第三生产环境一定要做“升级失败自动重试”。我的实现里如果App区校验失败bootloader不会跳转而是清掉App区重新进入Ymodem等待状态同时点亮一个红色的指示灯提示现场人员重新发送固件。这个兜底机制极大降低了售后成本。最后分享一个小技巧在bootloader里打印版本号通过串口输出版本信息遇到现场问题时可以直接看出bootloader和App的搭配情况。我遇到过好多次“固件升级不成功”的报告一问才知道现场手滑烧了个老版本Appbootloader和App地址不匹配。在启动阶段打印两个区间的关键信息真能省掉大半的沟通成本。这套方案从原理到代码到量产策略整体的经验已经全部在这里了有问题的朋友可以参考这个框架按自己的芯片平台去适配核心思路是通用的。