企业官网建设流程全解析

简介：面向嵌入式AI开发者，这份基于GD32H737的多目标实时识别系统资源，完整提供了无人机视角下车辆识别与跟踪的工程方案。系统以OV2640采集240×240图像，经模型推理后在LCD上实时显示识别结果，并通过UART接口与外部设备交互，实测识别精度达95%，多目标跟踪识别速度最高9fps。包内共795个文件，以447个C头文件、79个C源文件及固定库.a为核心，辅以工程配置文件、链接脚本和编译生成的axf/hex等，整体约27.55MB，可直接导入Keil MDK构建运行。实验部分详细记录了VisDrone数据集下小目标mAP较原模型提高122%、mAP50提高73%的对比数据，并附带500张车辆图片的训练集与模型配置，便于复现与二次开发。已有76人学习下载，适合具备嵌入式C语言基础、希望在低成本芯片上落地轻量级AI视觉算法的开发者。

1. 基于GD32的多目标实时识别：不只是把模型塞进MCU

很多人在拿到“基于GD32的多目标实时识别系统”这个方向时，第一反应是找个人脸识别或者YOLO的库，然后往GD32里硬塞。实际上GD32这种Cortex-M内核的MCU，主频最多两三百兆赫兹、RAM也就几百KB，跑不动动辄几十MB的深度学习模型。真正能落地的多目标实时识别，往往是用传统图像处理算法（色彩阈值、轮廓分析、连通域标记）或者极轻量的CNN在MCU上做检测，再用帧间匹配的办法实现多目标跟踪。这篇文章会按我自己做项目的顺序，把硬件选型、启动文件配置、算法取舍、实时性优化和调试中踩过的坑拆开讲，让你从零开始也能照着搭出一套能稳定跑多目标识别的GD32系统。

2. 选型与启动文件：为什么GD32的vector table base offset直接决定你能不能跑APP

2.1 GD32家族怎么选：F1/F3/F4系列与RAM、算力的最低门槛

GD32家族里做视觉相关项目，最常碰到的是三个系列：GD32F103（F1）、GD32F303（F3）和GD32F450（F4）。F1系列主频在108MHz到120MHz左右，适合做颜色识别、单目标跟随这类计算量小的活；多目标识别一旦需要处理多个轮廓、多路连通域标记，F1的算力会非常吃紧。F3系列是GD32F303，主频能达到120MHz，部分型号有硬件加速单元，做中等复杂度的图像处理勉强能跑。F4系列，比如GD32F450，主频最高到200MHz，带浮点单元和DCI数字摄像头接口，这才是做多目标实时识别的首选。

选择具体型号时要看三个硬指标：RAM大小决定能缓存几帧图像，Flash大小决定算法代码和查表数据能不能放得下，外设资源决定摄像头数据能不能用DMA直接搬运。常见做法是选GD32F450IGT6这一类，RAM有256KB甚至更高，配合DCI接口可以直接把摄像头数据流到内存，省掉CPU逐字节拷贝的负担。如果项目成本卡得紧，GD32F303VCT6也可以做，但分辨率要压到160x120以下，算法要尽量用定点运算。

需要特别提醒的是，市面上很多教程默认你用的是STM32，直接拿过来改芯片型号就用是不行的。GD32的内核虽然也是Cortex-M，但外设寄存器地址、时钟树配置、库函数命名都跟STM32有差异。GD32官网提供了自己的标准外设库，对应的配置工具有GD32 Cube，用它生成工程模板比自己手写启动文件可靠得多。

2.2 跑APP程序必须处理的VTOR中断向量表偏移

如果你准备在GD32上做多目标识别，多半会有一个Bootloader先启动，然后跳转到APP程序运行。这里有个新手最容易忽略的问题：APP程序的中断向量表默认放在0x08000000，而你的APP实际烧录在0x08004000或者更后面的地址。一旦任何中断触发，CPU去0x08000000查向量表，要么跳进Bootloader区域执行乱码，要么直接HardFault。GD32上处理这个问题靠的是Cortex-M内核的VTOR寄存器，也就是vector table base offset。

/* main.c APP程序入口 */ /* 根据实际APP烧录地址修改，常见是0x08004000或0x08008000 */ #define APP_BASE_ADDRESS 0x08004000U /* 中断向量表偏移函数，必须在任何外设中断使能之前调用 */ static void vtor_relocate(void) { /* 把向量表基地址设为APP所在Flash区域 */ /* VTOR寄存器的低5位保留，地址按32字节对齐 */ SCB->VTOR = APP_BASE_ADDRESS & 0x1FFFFF80U; } int main(void) { /* 第一步就要重定位向量表，否则后续所有中断全部跑飞 */ vtor_relocate(); /* 然后才能初始化外设、开启中断 */ system_clock_config(); gpio_config(); dci_config(); // ... 其他初始化 }

这段代码的逻辑很简单但顺序极其关键：重定位向量表必须在任何中断使能之前完成。如果你先初始化了定时器或者串口，中断一旦触发，CPU拿到的向量地址还是错的，表现就是程序莫名其妙死机，或者进入HardFault_Handler。另外要注意VTOR寄存器不是所有GD32型号都完全一致，个别早期型号的系统初始化文件里已经做了一次向量表处理，你在APP里再设一遍不会冲突；但如果是在Bootloader里跳转过来的，APP里必须自己设置。

2.3 用GD32 Cube或工程模板初始化外设的最小配置

GD32 Cube是官方提供的图形化配置工具，类似大伙儿熟悉的STM32CubeMX。用它生成工程时，有几个点要特别留意：首先是时钟树配置，GD32F450的最高主频200MHz不是默认值，需要在时钟配置里把PLL倍频系数调好；其次是DCI接口要把摄像头像素时钟的极性、同步信号极性配对，否则采出来的图全是花的；最后是DMA通道分配，不同的外设请求映射到固定的DMA通道，这跟STM32的映射规则不一样。

/* dci_config.c -- 摄像头接口初始化片段 */ /* DCI接口配置 */ void dci_config(void) { /* 使能DCI时钟和对应GPIO时钟 */ rcu_periph_clock_enable(RCU_DCI); rcu_periph_clock_enable(RCU_GPIOA); rcu_periph_clock_enable(RCU_GPIOB); rcu_periph_clock_enable(RCU_GPIOC); /* 配置DCI数据引脚和同步引脚复用功能 */ gpio_af_set(GPIOA, GPIO_AF_13, GPIO_PIN_4); /* DCI_HSYNC */ gpio_af_set(GPIOA, GPIO_AF_13, GPIO_PIN_6); /* DCI_PCLK */ gpio_af_set(GPIOB, GPIO_AF_13, GPIO_PIN_7); /* DCI_DATA0 */ // ... 更多数据引脚配置 /* 使能DCI外设 */ dci_enable(); }

这里为什么要强调用GD32 Cube生成工程而不是自己手写？原因是GD32某些型号的复用功能映射编号跟同管脚的STM32不一定一样，比如同一个引脚在STM32上是AF13，在GD32上可能映射到另一个AF编号。手写这些映射要对着Datasheet逐一核对，非常容易翻车；用GD32 Cube选好芯片型号后，它会自动给出正确的复用编号。

3. 把多目标识别算法压进MCU：从颜色阈值到轻量CNN的取舍

3.1 MCU适合的算法选型：颜色阈值、轮廓聚类与轻量CNN

在GD32上做多目标识别，首先要接受一个现实：你不可能跑YOLO、SSD这类需要GPU的模型。常见做法是把图像处理任务分成两级。第一级是传统CV方案，适用于目标颜色特征明显、背景相对简单的场景，比如识别红绿蓝三种颜色的乒乓球、区分不同颜色的料盒。第二级是轻量CNN方案，适用于目标纹理复杂、颜色相近但形状有区别的场景，比如识别不同型号的齿轮。轻量CNN在MCU上通常指的是参数量在几十KB到几百KB的模型，配合ARM的CMSIS-NN库做推理加速。

传统CV方案的核心流程是三步：色彩空间转换、阈值分割、连通域标记。摄像头拿到的通常是RGB565数据，但人眼和算法对亮度变化最鲁棒的是HSL或HSV空间。在MCU上做色彩空间转换要避免浮点运算，全部用整数运算或者查表法。阈值分割把目标像素置1、背景置0，然后做连通域标记，找出每一块独立的区域，再计算每块的质心、面积、外接矩形，这就是多目标的原始数据。

3.2 多目标目标去重与帧间关联：用IOU和卡尔曼当土办法

多目标识别系统里有个经典问题：这一帧检测到了3个目标，下一帧还是3个，但你怎么知道当前帧的第一个目标就是上一帧的第一个目标？如果不做帧间关联，画面里每个目标都没有稳定的ID，下游逻辑就没法用。帧间关联最常用的指标是交并比IOU，也就是两个目标外接矩形的重叠面积除以合并面积。当当前帧的某个目标和上一帧的某个目标IOU超过阈值（比如0.3），就认为是同一个目标，继承上次的ID。这个方法实现简单、算得快，适合目标移动速度不太快的场景。

/* target_track.c -- 帧间目标匹配 */ typedef struct { uint16_t x, y, w, h; /* 外接矩形 */ uint16_t area; /* 像素面积 */ uint8_t label; /* 目标类别 */ uint8_t id; /* 目标ID，0表示未分配 */ } target_t; /* 计算两个矩形的IOU，返回值范围0~100 */ uint8_t calc_iou(target_t *a, target_t *b) { uint16_t x1 = a->x > b->x ? a->x : b->x; uint16_t y1 = a->y > b->y ? a->y : b->y; uint16_t x2 = (a->x + a->w) < (b->x + b->w) ? (a->x + a->w) : (b->x + b->w); uint16_t y2 = (a->y + a->h) < (b->y + b->h) ? (a->y + a->h) : (b->y + b->h); uint16_t inter_w = x2 > x1 ? x2 - x1 : 0; uint16_t inter_h = y2 > y1 ? y2 - y1 : 0; uint32_t inter_area = (uint32_t)inter_w * inter_h; uint32_t union_area = (uint32_t)a->w * a->h + (uint32_t)b->w * b->h - inter_area; if (union_area == 0) return 0; return (uint8_t)(inter_area * 100 / union_area); } /* 用IOU阈值做帧间匹配 */ void match_targets(target_t *prev, uint8_t prev_cnt, target_t *curr, uint8_t curr_cnt) { for (uint8_t i = 0; i < curr_cnt; i++) { uint8_t best_iou = 0; uint8_t best_idx = 0xFF; for (uint8_t j = 0; j < prev_cnt; j++) { uint8_t iou = calc_iou(&prev[j], &curr[i]); if (iou > best_iou) { best_iou = iou; best_idx = j; } } if (best_iou >= 30) { /* 超过30%重叠就认为是同一个目标，继承ID */ curr[i].id = prev[best_idx].id; } else { /* 否则分配一个新ID */ curr[i].id = next_available_id(); } } }

这段代码里的关键词是“IOU阈值”和“ID继承”。阈值设得太低，比如10%，两个靠近的独立目标容易被误判成同一个，ID会跳变；设得太高，比如70%，目标只要稍微动一动就会丢失ID，造成闪烁。30%是我在多数室内场景下用下来比较折中的值。如果目标运动速度很快，单纯靠IOU匹配会丢帧，可以考虑加入卡尔曼滤波预测目标下一帧的位置，再用预测框和实际检测框做匹配，这是很多商用跟踪方案的土办法。

3.3 在GD32上跑通一个最小识别管道

一个完整的最小识别管道应该包含五步：采图、预处理、阈值分割、连通域标记、输出结果。下面以识别彩色小球为例，给出一个能直接在GD32工程里跑的框架，重点关注内存规划和循环结构。

/* image_proc.c -- 多目标识别主处理流程 */ #define IMG_W 160 /* 图像宽度 */ #define IMG_H 120 /* 图像高度 */ #define MAX_TARGETS 8 /* 最大目标数量 */ uint16_t img_rgb[IMG_W * IMG_H]; /* 原始RGB565帧缓冲区 */ uint8_t img_mask[IMG_W * IMG_H]; /* 阈值分割后的二值图 */ uint8_t img_label[IMG_W * IMG_H]; /* 连通域标记结果 */ target_t targets[MAX_TARGETS]; /* 目标数组 */ void process_frame(void) { /* 第1步：从DCI的DMA缓冲区取最新一帧 */ dma_buffer_get(img_rgb, sizeof(img_rgb)); /* 第2步：遍历每个像素，提取HSL并做颜色阈值判断 */ for (uint32_t i = 0; i < IMG_W * IMG_H; i++) { /* 把RGB565拆成RGB分量，再整数化转HSL */ uint8_t h = rgb565_to_hue(img_rgb[i]); uint8_t s = rgb565_to_sat(img_rgb[i]); uint8_t l = rgb565_to_lum(img_rgb[i]); /* 红球的H分量在0~15或225~255区间 */ if ((h < 15 || h > 225) && s > 50 && l > 30 && l < 220) { img_mask[i] = 1; } else { img_mask[i] = 0; } } /* 第3步：两遍扫描连通域标记 */ uint8_t cnt = connected_components(img_mask, img_label, IMG_W, IMG_H); /* 第4步：对每个连通域计算面积、质心和外接矩形 */ uint8_t valid = 0; for (uint8_t i = 0; i < cnt; i++) { if (region_area[i] < 50) continue; /* 过滤噪声小区域 */ if (region_area[i] > 3000) continue; /* 过滤大面积背景 */ targets[valid].x = region_min_x[i]; targets[valid].y = region_min_y[i]; targets[valid].w = region_max_x[i] - region_min_x[i]; targets[valid].h = region_max_y[i] - region_min_y[i]; targets[valid].area = region_area[i]; targets[valid].label = 0; /* 0代表红色目标 */ valid++; } /* 第5步：帧间匹配，给每个目标分配ID */ match_targets(prev_targets, prev_valid, targets, valid); /* 保存当前帧结果用于下一帧匹配 */ memcpy(prev_targets, targets, sizeof(target_t) * valid); prev_valid = valid; }

这里有个很实际的设计细节：整幅二值图img_mask和img_label各占160x120字节，即每幅19KB左右，两张就是38KB。加上原始RGB帧缓冲区38KB，以及DMA双缓冲可能再加38KB，总共需要100多KB的RAM。这已经逼近GD32F303的RAM上限，所以在选型时RAM至少要到256KB才从容。如果你硬要在RAM小的型号上跑，只能把分辨率压到QVGA以下，或者牺牲双缓冲改为单缓冲。

4. 实时性从哪来：图像采集、DMA双缓冲与帧率三档配置

4.1 DCI+DMA双缓冲怎么调才能不丢帧

多目标识别系统的实时性瓶颈通常不在算法本身，而在图像采集环节。摄像头以固定帧率输出图像，比如OV2640输出30fps，每帧到来时如果CPU还在处理上一帧，那么新一帧数据只能覆盖缓冲区，导致花屏或丢帧。解决这个问题的标准做法是DMA双缓冲：图像数据先由DMA搬运到缓冲区A，搬完一整帧后产生传输完成中断，CPU在中断服务函数里切换到缓冲区B继续接收下一帧，同时CPU开始在缓冲区A上做识别算法。这样采集和处理并行，每一帧都不会丢。

/* dma_double_buffer.c -- DMA双缓冲初始化 */ #define FRAME_SIZE (160U * 120U * 2U) /* RGB565一帧字节数 */ /* 两个帧缓冲区，必须放在连续内存区域 */ uint8_t frame_buf[2][FRAME_SIZE]; void dma_double_buffer_init(void) { dma_parameter_struct dma_para; /* 清空DMA配置 */ dma_deinit(DMA0, DMA_CH6); /* 从外设读取，写入内存 */ dma_para.direction = DMA_PERIPHERAL_TO_MEMORY; dma_para.periph_addr = (uint32_t)&DCI_DATA; dma_para.memory_addr = (uint32_t)frame_buf[0]; dma_para.number = FRAME_SIZE; dma_para.periph_inc = DMA_PERIPH_INCREASE_DISABLE; dma_para.memory_inc = DMA_MEMORY_INCREASE_ENABLE; dma_init(DMA0, DMA_CH6, &dma_para); dma_circulation_enable(DMA0, DMA_CH6); /* 开启传输完成中断，在中断里切换缓冲区 */ dma_interrupt_enable(DMA0, DMA_CH6, DMA_INT_FTF); nvic_irq_enable(DMA0_Channel6_IRQn, 0, 0); } /* 中断服务函数 */ void DMA0_Channel6_IRQHandler(void) { if (dma_interrupt_flag_get(DMA0, DMA_CH6, DMA_INT_FLAG_FTF)) { /* 当前缓冲已经收满，切到另一块 */ static uint8_t cur_idx = 0; uint8_t next_idx = cur_idx ^ 1; /* 让DMA下一轮写到另一块缓冲区 */ DMA0->CH6MADDR = (uint32_t)frame_buf[next_idx]; /* 让主循环处理已经收满的这块 */ frame_ready = 1; current_frame_index = cur_idx; cur_idx = next_idx; dma_interrupt_flag_clear(DMA0, DMA_CH6, DMA_INT_FLAG_FTF); } }

GD32的DMA双缓冲跟Cortex-M内核里真正的双缓冲模式有所不同，这里用的是切换内存地址的土办法，效果一样。这种方法的坑在于主循环处理完一帧之前，下一帧可能已经又写完了，所以必须在主循环里加一个计数判断：如果连续两帧都没来得及处理，就要主动丢弃旧帧，保证图像永远是新的，而不是处理陈旧的队列。

4.2 分辨率、帧率、识别窗口三者的平衡参数

实时识别系统要回答一个问题：多少fps算实时？对机械臂抓取、AGV避障这类场景，10fps以上就有可用性；对高速分拣产线，需要20fps以上。在GD32上实现20fps意味着每帧处理时间必须小于50毫秒。这会逼着你做三档典型配置。

第一档是高帧率抢拍模式：分辨率160x120，帧率30fps，只用颜色阈值和连通域标记，不跑CNN。这一档在GD32F450上每帧处理时间可以压到15毫秒以内。第二档是平衡模式：分辨率320x240，帧率15fps，在阈值分割后用简单的模板匹配识别目标类别。第三档是低帧率高精度模式：分辨率640x480，帧率5fps左右，跑轻量CNN做分类。这个配置要避免一个常见误区：图像分辨率越高识别越准。MCU上的识别算法依赖于阈值分割质量，如果光照不均，高分辨率反而放大了阴影和反光干扰，导致目标破碎成多块。

参数调整方面，一个截图切分的小技巧值得试：先把处理窗口限制在ROI区域而不是全图。比如只对画面中央320x240区域做识别，外围的120像素直接忽略。这样既减少了处理时间，又避免了画面边缘目标进入又离开造成的ID抖动。

4.3 性能分析：怎么知道瓶颈在外设还是CPU

做完一版后你要能回答“每一毫秒都去哪了”。常见做法是开三个GPIO引脚作为调试探针：采图开始拉高，采图完成拉低；算法开始拉高，算法完成拉低；串口发送开始拉高，发送完成拉低。用逻辑分析仪或者示波器看这三个方波，一眼就能分辨瓶颈。我遇到过的情况是算法只用了8毫秒，串口发送却占了25毫秒——因为用了阻塞式串口输出。解决办法是改用DMA发送，或者降低串口波特率的上位机显示频率，比如每5帧才输出一次。

/* perf_check.c -- 性能统计辅助代码 */ volatile uint32_t frame_count = 0; volatile uint32_t algo_start_us = 0; volatile uint32_t algo_end_us = 0; /* 在算法前后记录时间戳，用SysTick或DWT时钟 */ void algo_run(void) { algo_start_us = dwt_get_us(); process_frame(); algo_end_us = dwt_get_us(); frame_count++; }

DWT时钟是Cortex-M内核自带的一个计数器，精度比SysTick高，非常适合做这种微秒级的性能统计。如果在GD32上发现DWT没有工作，多半是忘了使能调试时钟，在系统初始化时调用CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk就能解决。这也是gd32调试问题里很常见的怪现象。

5. 你大概率会翻车的5个GD32调试坑：现象、原因与解法

5.1 程序跳进HardFault，看不出哪里出错

现象：APP程序一上电或者一打开某个外设中断就进去HardFault_Handler，用调试器单步看汇编也找不到头绪。原因有两个方向：一是向量表没有重定位，中断跳错；二是外设时钟没有使能，访问了未开时钟的外设寄存器。解决：先把vtor_relocate()放到main第一行，再检查RCU时钟使能是否覆盖了所有用到的外设。仍解决不了就在HardFault_Handler里牵出R0、R1、R2、R3和LR寄存器，用初值法回溯到故障代码位置，具体做法是查看R0到R3和LR的值，它们能定位到出错的函数调用位置。

5.2 摄像头图像花屏，画面有斜纹或撕裂

现象：DCI接口采集的图像上半部分是正常的，下半部分偏移了，或者整体有规律的条纹干扰。原因：这是典型的同步信号配置问题。DCI的HSYNC和VSYNC极性、像素时钟PCLK的采样边沿跟摄像头输出的时序不匹配。解决：把DCI配置里的同步极性参数逐项翻转测试，同时检查摄像头是否工作在正确的时钟频率下。OV2640给24MHz主时钟，输出PCLK可能达到24MHz，如果GD32的DCI被配置成下降沿采样而摄像头输出的是上升沿有效，就会花屏。这种调参要靠二分法，一次只翻一个参数，不要同时改多个。

5.3 目标闪烁，ID不断跳变

现象：画面里只有一个球静止不动，但上位机显示的目标ID却每隔几秒就重新分配一次。原因：阈值分割抖动了目标的边界，导致外接矩形在几像素之间波动，IOU计算值刚好落在阈值边缘。解决：给目标匹配加一个连续丢失帧计数，如果目标连续5帧都能匹配上，就把它标记为“稳定”；稳定后的目标允许IOU降到15%仍然算同一个。这个逻辑很简单但很实用，能消除大部分工业场景的ID抖动问题。另外还有一种可能性是图像帧率低导致目标移动量超过自身尺寸，IOU直接归零，这时候只能调高帧率或者降低目标提取的灵敏度。

5.4 gd32调试问题：调试器连不上芯片，识别不了设备

现象：Keil或者OpenOCD提示找不到目标设备，或者“Could not connect to target”。原因：GD32的SWD引脚被复用成GPIO了，或者芯片进入了低功耗模式；更常见的是芯片烧录口有外部电容造成电平不稳。解决：先强制复位核心再连接，Keil里设置成Connect under Reset模式。如果是自己画的板子，检查SWDIO和SWCLK上有没有并联电容，一般不要超过10pF。GD32调试问题还有个冷门原因是JTAG引脚被用作普通GPIO输出，需要在代码里加上禁止JTAG复用的操作，否则调试器很可能连不上。

5.5 APP程序能跑但越跑越慢，最终卡死

现象：系统运行一段时间后实时性下降，帧率逐渐降低，最后完全卡死。原因：内存碎片或DMA缓冲区溢出覆盖了关键变量。多目标识别系统里有大量数组和结构体，如果用malloc频繁分配释放，堆碎片会越来越严重。解决：全部改成静态分配，所有缓冲区在编译期就固定位置；DMA缓冲区单独放在一个大数组中，用__attribute__((aligned(32)))保证对齐，同时检查DMA传输长度是否和缓冲区大小严格一致。

6. 一个能让系统真正被信任的收尾：串口输出目标ID与性能指标

走到这一步，系统已经能跑通多目标识别了，但我做项目时最后还要加一个环节：串口输出一份结构化的状态帧，包含每一帧的帧号、耗时、目标数量、每个目标的ID和坐标。这不仅仅是为了给上位机展示，更是为了验证系统的“实时性”不是靠感觉，而是靠数据说话。

/* uart_report.c -- 输出性能与目标信息 */ void report_frame_status(void) { static uint8_t tx_buf[32]; uint16_t len = 0; /* 帧头 */ tx_buf[len++] = 0xA5; tx_buf[len++] = 0x5A; /* 帧号低16位 */ tx_buf[len++] = (uint8_t)(frame_count & 0xFF); tx_buf[len++] = (uint8_t)((frame_count >> 8) & 0xFF); /* 本帧处理耗时，单位毫秒 */ uint16_t cost_ms = (algo_end_us - algo_start_us) / 1000; tx_buf[len++] = (uint8_t)(cost_ms & 0xFF); tx_buf[len++] = (uint8_t)((cost_ms >> 8) & 0xFF); /* 目标数量 */ tx_buf[len++] = valid_target_count; /* 后续按固定格式填充每个目标的ID和中心坐标 */ for (uint8_t i = 0; i < valid_target_count; i++) { tx_buf[len++] = targets[i].id; tx_buf[len++] = (uint8_t)((targets[i].x + targets[i].w / 2) & 0xFF); tx_buf[len++] = (uint8_t)((targets[i].y + targets[i].h / 2) & 0xFF); } /* 使用DMA发送，不阻塞CPU */ uart_dma_send(tx_buf, len); }

这个输出格式设计成固定长度的二进制帧，上位机解析简单，MCU端发送也快。如果你在上位机里画一条帧耗时的曲线，就会发现它是一条上下波动的折线，峰值出现在目标数量最多的帧上。这时候可以再做几轮针对性的算法裁剪，把峰值压下去。

做完这一步，我的习惯是把整套工程的编译警告清零，同时把每个外设的初始化代码拆成独立文件，方便以后移植到其他GD32型号。这套系统的价值在于用MCU实现了“看得见、数得清、跟得住”的多目标实时识别，对那些不需要深度语义理解、只关心目标位置和数量的场景，已经是工程上够用且成本可控的方案。希望这篇基于实战的整理能帮你在GD32上少走几步弯路。

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