企业官网建设流程全解析

1. 从STM32到国产替代：一个嵌入式老兵的年度观察

去年这个时候，我手里同时开着三个项目：一个基于STM32F103的工业采集板、一个用GD32F303做的电机控制方案，还有一个客户指定要评估的CH32V103R8T6开发板。说实话，刚开始我对后两款芯片是带着"试试看"的心态——毕竟过去十年，STM32几乎是我所有嵌入式项目的默认选项，从标准库到HAL库，从F1到F4再到H7，闭着眼睛都能把工程搭起来。但一年下来，这三个平台我都完成了从原型到小批量交付的完整流程，踩过的坑、积累的经验、对国产芯片的真实感受，远比网上那些"国产替代"的口号要复杂得多。

这篇文章不打算给你灌什么"国产崛起"或者"还是进口香"的结论，我只想把这十二个月里，在STM32、GD32、CH32V103这三个平台上实际遇到的技术细节、选型逻辑、迁移成本、调试技巧，原原本本地摊开来讲。如果你正在做嵌入式项目选型，或者被供应链逼着考虑国产方案，又或者单纯想了解RISC-V内核的MCU到底能不能打，那这篇内容应该能帮你省下不少试错时间。

先给个整体印象：STM32依然是那个"最不会出错"的选择，生态成熟到令人发指，但价格和交期在过去两年确实让人头疼；GD32作为最像STM32的国产替代，在硬件引脚和软件库层面做到了近乎无缝迁移，但在某些外设细节和低功耗表现上有自己的脾气；CH32V103则是完全不同的技术路线——RISC-V内核、自研工具链、全新的开发习惯，它不适合所有人，但在特定场景下能给你惊喜。下面我分几个维度，把这一年的实战经验拆开来讲。

2. 三个平台的核心架构与选型逻辑拆解

2.1 为什么是这三款芯片：选型背后的真实考量

先说说我为什么选这三款。STM32F103C8T6是经典中的经典，Cortex-M3内核，72MHz主频，64KB Flash，20KB RAM，用来做工业数据采集和简单控制绰绰有余。它的价值在于"确定性"——你知道它能做什么，知道代码怎么写，知道出了问题去哪里找答案。我手上这个采集板需要同时跑ADC多通道采样、UART与上位机通信、定时器捕获测频率，还要留出CAN总线接口做备份，F103的资源刚好卡在够用线上。

GD32F303CBT6是客户指定的替代方案，原因很简单：当时STM32F103的采购周期拉到了26周以上，而GD32F303有现货，价格还便宜三成。GD32F303是Cortex-M4内核，主频120MHz，128KB Flash，32KB RAM，性能比F103强不少。客户的需求是电机控制，需要跑FOC算法，对运算能力有要求，M4内核带FPU和DSP指令集，理论上比M3更合适。但问题在于，客户原有的代码是基于STM32标准库写的，迁移到GD32需要评估工作量。

CH32V103R8T6则是另一个客户的产品预研项目，要求"全国产化BOM"，主控必须用RISC-V内核。CH32V103是沁恒微电子的产品，RISC-V内核，80MHz主频，64KB Flash，20KB RAM，外设资源跟STM32F103基本对标。选它的理由很直接：这是当时市面上少数能买到现货、有完整中文文档、且价格控制在10元以内的RISC-V MCU。

2.2 内核差异对实际开发的影响

从Cortex-M3到Cortex-M4再到RISC-V，内核差异到底意味着什么？我用一个具体场景来说明。在电机控制项目中，FOC算法需要做大量的乘加运算和三角函数计算。STM32F103的M3内核没有硬件FPU，浮点运算靠软件模拟，跑一遍FOC大概需要80微秒；GD32F303的M4内核带单精度FPU，同样的算法只需要25微秒左右。这个差距在低速运行时影响不大，但当电机转速拉到每分钟3000转以上，控制周期被压缩到50微秒以内时，M3就力不从心了，而M4还能留出余量做电流环和速度环的双环控制。

CH32V103的RISC-V内核在整数运算上表现不错，但浮点性能是短板。我实测下来，同样的FOC算法在CH32V103上跑一遍需要120微秒左右，比STM32F103还慢。所以这款芯片我最终没有用在电机控制上，而是转去做了一个数据采集网关——那里主要是整数运算和通信协议处理，RISC-V内核完全够用。

这里有个经验：选芯片不要只看主频和内核型号，一定要把实际算法跑一遍。我见过太多项目在选型时只看参数表，结果代码写完了才发现算力不够，那时候换芯片的成本就大了。

2.3 工具链与开发环境的迁移成本

STM32的开发环境不用多说，Keil MDK、IAR、STM32CubeIDE、PlatformIO，甚至用VSCode加插件都能搭起来。我习惯用Keil MDK加STM32CubeMX的组合，图形化配置引脚和时钟树，生成初始化代码，然后手写业务逻辑。这套流程我用了快八年，闭着眼睛都能操作。

GD32的迁移成本比我预想的低。GD32官方提供了GigaDevice.GD32F30x_DFP芯片包，可以直接装在Keil里，新建工程时选GD32F303CBT6就行。更关键的是，GD32的标准库函数名和STM32几乎一模一样，比如GPIO_Init()、USART_Init()、TIM_TimeBaseInit()，连参数结构体的成员名都相同。我把STM32的工程直接复制过来，把启动文件换成GD32的，把库文件替换掉，编译居然一次通过，只有几个中断向量表的名称需要调整。

但这里有个坑：GD32的SystemInit()函数默认把主频设到120MHz，而STM32F103的SystemInit()是72MHz。如果你直接移植代码，延时函数的时间基准会全部错乱。我当时的串口通信直接乱码，排查了半天才发现是时钟频率变了，延时函数的循环次数没跟着改。后来我养成了一个习惯：每次迁移平台，第一件事就是用一个GPIO翻转加示波器测实际延时，确认时钟配置无误后再往下做。

CH32V103的工具链则是完全不同的体验。它不能用Keil MDK开发，官方推荐的是MounRiver Studio，一个基于Eclipse的IDE，集成了RISC-V GCC工具链和WCH-Link调试器驱动。刚开始我很不适应——Eclipse的界面逻辑和Keil差别很大，编译速度也慢一些，而且中文资料虽然多，但英文资料少，遇到问题搜索范围有限。不过用了一周之后，我发现MounRiver Studio其实挺好用的，尤其是它的代码补全和函数跳转功能，比Keil的默认配置要顺手。而且它支持直接导入STM32的工程模板，虽然不能直接编译，但可以参考它的工程结构来组织代码。

3. 外设实操对比：GPIO、串口、ADC与定时器

3.1 GPIO与引脚映射的差异处理

GPIO操作是嵌入式开发中最基础的部分，但三个平台在这上面的差异却不小。STM32F103的GPIO配置很直观：使能时钟、设置模式、设置速度，然后就可以读写。GD32F303的GPIO配置流程完全一样，但有一个细节需要注意——GD32的GPIO输出速度等级和STM32的对应关系不同。STM32有2MHz、10MHz、50MHz三档，GD32有2MHz、10MHz、50MHz、120MHz四档。如果你从STM32移植代码，把速度参数直接照搬，可能会发现GPIO翻转速度比预期慢，因为GD32的默认速度档位对应的实际频率和STM32不一样。

CH32V103的GPIO配置则有自己的风格。它的库函数叫GPIO_Init()，但参数结构体是GPIO_InitTypeDef，成员包括GPIO_Pin、GPIO_Mode、GPIO_Speed。看起来和STM32很像，但模式枚举值不同——STM32的GPIO_Mode_Out_PP在CH32V103里叫GPIO_Mode_Out_PP，但复用功能的配置方式不一样。CH32V103需要先调用GPIO_PinRemapConfig()来设置复用功能，而且重映射的选项比STM32少一些。

我遇到过一个具体问题：在STM32上，USART2的默认引脚是PA2和PA3，如果要重映射到PD5和PD6，需要开启AFIO时钟并调用GPIO_PinRemapConfig(GPIO_Remap_USART2, ENABLE)。在GD32上，这个操作完全一样。但在CH32V103上，USART2的重映射选项只有部分引脚可用，而且配置函数是GPIO_PinRemapConfig()，参数格式也不同。我当时想把USART2映射到PD5和PD6，查了手册才发现CH32V103不支持这个映射，只能换到其他引脚。这个教训告诉我：国产芯片的外设复用功能往往比STM32少，选型时一定要先确认引脚映射表。

3.2 串口通信的稳定性与波特率误差

串口是嵌入式项目中最常用的通信接口，三个平台在这方面的表现差异主要体现在波特率精度和中断响应上。STM32F103的USART波特率发生器精度很高，在72MHz主频下，115200波特率的误差不到0.1%，长时间通信很稳定。GD32F303在120MHz主频下，波特率误差同样很小，但我发现它在高波特率（比如921600）下的误码率比STM32略高，尤其是在电磁干扰较强的电机控制环境中。后来我在GD32的串口引脚上加了RC滤波电路，问题才解决。

CH32V103的串口在常规波特率下表现正常，但在使用内部RC振荡器作为时钟源时，波特率误差会明显增大。我实测过，用内部RC振荡器跑115200波特率，误差大概在2%左右，短帧通信没问题，但连续传输大量数据时偶尔会出现帧错误。后来我换成了外部8MHz晶振，误差降到0.3%以内，通信就稳定了。所以如果你用CH32V103做串口通信，强烈建议外接晶振，不要图省事用内部RC。

还有一个细节：STM32和GD32的串口中断标志位清除方式一样，都是先读SR寄存器再读DR寄存器。但CH32V103的串口中断标志清除需要调用专门的函数USART_ClearITPendingBit()，如果你直接照搬STM32的中断服务程序，可能会遇到中断反复触发的问题。我第一次移植时就踩了这个坑，串口接收中断一直进不去，后来查了CH32V103的参考手册才发现中断标志清除方式不同。

3.3 ADC多通道采样的精度与切换速度

ADC是我在工业采集板上最关注的外设。STM32F103的ADC是12位逐次逼近型，最高采样率1MHz，支持16个外部通道。我用它做多通道采样时，通常用DMA搬运数据，规则组扫描模式，每个通道采样时间设为55.5个周期，这样在72MHz的ADC时钟下，单通道转换时间大概1.17微秒，8个通道轮询一遍不到10微秒，完全满足我的采集需求。

GD32F303的ADC参数和STM32F103基本一致，也是12位、1MHz采样率，但我在实际使用中发现它的通道切换速度比STM32慢一点。具体表现是：当我在两个通道之间快速切换时，GD32的ADC需要更长的稳定时间，否则第二个通道的采样值会偏高。后来我把采样时间从55.5个周期增加到71.5个周期，问题就消失了。这个差异在数据手册里没有明确写，是我用标准电压源反复测试才发现的。

CH32V103的ADC是12位，但最高采样率只有1MHz，而且它的通道切换逻辑和STM32不同。STM32的ADC在扫描模式下会自动按顺序转换所有配置的通道，而CH32V103需要手动触发每个通道的转换，或者用DMA配合定时器触发。我刚开始用CH32V103做多通道采样时，发现通道之间的数据会串扰，后来仔细看手册才知道，CH32V103的ADC在切换通道后需要插入一个延时，等采样电容稳定后再启动转换。这个延时大概需要1微秒左右，我在代码里加了一个__NOP()循环，问题就解决了。

3.4 定时器捕获与PWM输出的实测对比

定时器捕获测频率是我在采集板上用到的功能，用来测量外部传感器的脉冲信号。STM32F103的定时器捕获功能很成熟，我配置TIM2为输入捕获模式，上升沿触发，捕获值减去上一次捕获值就是周期，换算一下就是频率。在72MHz主频下，捕获分辨率是13.9纳秒，测1kHz到100kHz的信号都很准。

GD32F303的定时器捕获功能同样好用，而且因为主频更高（120MHz），捕获分辨率提升到8.3纳秒，测高频信号更有优势。但我在使用中发现，GD32的定时器在捕获溢出时的中断处理需要注意——它的溢出标志清除方式和STM32略有不同，如果不清除干净，会导致捕获值计算错误。我当时的症状是频率读数偶尔跳变，后来在中断里加了溢出标志清除代码，问题就解决了。

CH32V103的定时器捕获功能让我有点意外。它的定时器资源比STM32少，TIM1和TIM2是高级定时器，TIM3和TIM4是通用定时器，但捕获通道的分配不如STM32灵活。我原本想用TIM3的通道1和通道2同时捕获两路信号，结果发现CH32V103的TIM3只有通道1支持捕获，通道2只能做PWM输出。后来我改用TIM1和TIM2各捕获一路，才实现了双路频率测量。这个限制在选型时一定要提前确认，否则硬件设计完了才发现引脚不够用，那就麻烦了。

PWM输出方面，三个平台都能满足常规需求。STM32F103的TIM1和TIM8是高级定时器，支持互补输出和死区插入，适合驱动电机。GD32F303的高级定时器功能类似，但死区时间的计算公式不同，需要重新计算。CH32V103的高级定时器也支持互补输出，但死区时间的最小分辨率比STM32大，如果你需要很精确的死区控制，可能需要外接死区生成电路。

4. 从零搭建工程的完整实操流程

4.1 STM32标准库工程的搭建与配置

虽然现在HAL库和STM32CubeMX很流行，但我还是习惯用标准库搭建工程，因为代码量小、执行效率高、对底层寄存器掌控更直接。下面是我搭建STM32F103标准库工程的完整步骤。

首先准备材料：STM32F10x标准外设库（我从官网下载的V3.5.0版本）、Keil MDK5、STM32F103的芯片包。新建工程文件夹，在里面创建四个子文件夹：Start放启动文件和内核文件，Library放标准外设库的.c和.h文件，User放main.c和中断服务程序，Project放Keil工程文件。

在Keil里新建工程，选STM32F103C8T6芯片，然后把启动文件startup_stm32f10x_md.s添加到Start组，把stm32f10x.h、system_stm32f10x.c、core_cm3.c也加进去。Library组里添加stm32f10x_gpio.c、stm32f10x_rcc.c、stm32f10x_usart.c等我用到的外设文件。User组里添加main.c、stm32f10x_it.c。

接下来配置头文件包含路径：在Keil的Options for Target里，C/C++选项卡的Include Paths中添加..\Start、..\Library、..\User。然后在Define里加上USE_STDPERIPH_DRIVER, STM32F10X_MD，这两个宏定义很关键，前者告诉编译器使用标准外设库，后者指定芯片型号是中容量产品。

最后写main函数。我通常先写一个GPIO翻转的测试代码，确认时钟配置和引脚输出正常，然后再逐步添加串口、ADC、定时器等外设。这个顺序很重要——先确保最基础的GPIO能工作，再往上叠加功能，出了问题也容易定位。

4.2 GD32工程从STM32迁移的详细步骤

GD32的工程搭建可以完全复用STM32的框架，只需要替换几个关键文件。我以GD32F303CBT6为例，说说具体的迁移步骤。

第一步，下载GD32F30x固件库，里面包含启动文件、外设驱动和示例代码。把STM32工程里的启动文件startup_stm32f10x_md.s替换成GD32的startup_gd32f30x_hd.s，注意文件名里的hd表示高密度产品，对应GD32F303的128KB Flash。

第二步，替换外设驱动文件。GD32的库文件名和STM32不同，比如STM32的stm32f10x_gpio.c对应GD32的gd32f30x_gpio.c。把Library文件夹里的文件全部替换掉，然后在Keil工程里重新添加这些文件。

第三步，修改头文件包含。把#include "stm32f10x.h"改成#include "gd32f30x.h"，把#include "stm32f10x_gpio.h"改成#include "gd32f30x_gpio.h"，以此类推。这一步工作量不大，但很繁琐，我建议用编辑器的全局替换功能批量处理。

第四步，修改时钟配置。GD32的SystemInit()默认把主频设到120MHz，如果你需要其他频率，要修改system_gd32f30x.c里的PLL配置参数。我通常保持120MHz不变，因为GD32的Flash等待周期配置已经适配了这个频率。

第五步，修改中断向量表。GD32的中断向量表名称和STM32略有不同，比如STM32的USART1_IRQHandler在GD32里叫USART1_IRQHandler，看起来一样，但有些外设的中断名称有变化。我建议直接参考GD32的示例代码，把中断服务函数的名称核对一遍。

完成这五步之后，编译工程，如果报错就根据错误信息逐个解决。我迁移一个中等复杂度的工程（大概5000行代码）用了半天时间，主要时间花在核对中断向量表和修改时钟配置上。

4.3 CH32V103在MounRiver Studio中的工程创建

CH32V103的工程创建流程和STM32、GD32完全不同，因为它用的是RISC-V工具链和MounRiver Studio IDE。下面是我从零创建CH32V103工程的步骤。

首先下载MounRiver Studio，安装完成后打开，选择"New Project"，然后选"CH32V103"系列，再选具体型号CH32V103R8T6。IDE会自动生成一个包含启动文件、链接脚本和基本外设驱动的工程模板。

工程模板里有一个Startup文件夹，里面是RISC-V的启动文件startup_ch32v103.S，这个文件用汇编编写，负责初始化堆栈、设置中断向量表、跳转到main函数。还有一个Ld文件夹，里面是链接脚本Link.ld，定义了Flash和RAM的地址范围。CH32V103R8T6的Flash起始地址是0x08000000，大小64KB，RAM起始地址是0x20000000，大小20KB。这些信息在链接脚本里都要正确配置，否则程序无法正常运行。

接下来配置外设。CH32V103的库函数风格和STM32标准库很像，但函数名和参数略有不同。比如GPIO初始化，STM32是GPIO_Init(GPIOA, &GPIO_InitStructure)，CH32V103是GPIO_Init(GPIOA, &GPIO_InitStructure)，看起来一样，但GPIO_InitStructure的成员顺序不同。我建议直接参考CH32V103的示例代码，不要凭记忆写。

编译工程时，MounRiver Studio会调用RISC-V GCC工具链，生成.elf和.hex文件。下载程序需要用WCH-Link调试器，在IDE的下载配置里选择WCH-Link，然后点击下载按钮。我第一次下载时遇到了连接失败的问题，后来发现是WCH-Link的驱动没有正确安装，重新安装驱动后就正常了。

4.4 三个平台的调试工具与下载方式对比

调试工具方面，STM32我用的是ST-Link V2，配合Keil MDK的调试功能，可以单步执行、查看寄存器、设置断点，体验很流畅。GD32可以用GD-Link，也可以用ST-Link，因为GD32的SWD接口和STM32兼容。我通常直接用ST-Link调试GD32，省得再买一个调试器。

CH32V103必须用WCH-Link，不能兼容ST-Link。WCH-Link的价格很便宜，大概二十块钱，但它的调试功能比ST-Link弱一些，比如不支持实时变量查看，单步执行的速度也慢一点。不过对于常规调试来说够用了。

下载方式上，STM32和GD32都支持SWD和串口下载。SWD下载速度快，适合开发阶段；串口下载需要配置BOOT引脚，适合量产阶段。CH32V103支持SWD下载和串口下载，但它的串口下载工具是沁恒自己提供的，叫WCHISPTool，使用起来还算方便。

这里分享一个经验：无论用哪个平台，我都建议在PCB上预留SWD接口和串口接口。SWD用于调试，串口用于下载和通信。有时候调试器不在手边，用串口下载也能应急。

5. 常见问题与排查技巧实录

5.1 STM32工程常见问题速查

STM32的生态太成熟了，大部分问题都能在网上找到答案。但我发现一个规律：很多新手遇到的问题其实是基础问题，比如忘记使能外设时钟、中断优先级配置错误、堆栈大小不够。我的建议是，遇到问题先检查这三个地方，能解决80%的故障。

5.2 GD32迁移过程中的典型故障

GD32迁移过程中我遇到的最典型故障是串口通信失败。症状是：程序能下载，GPIO能翻转，但串口就是没输出。排查过程如下：先用示波器测TX引脚，发现没有波形，说明串口外设没有工作。然后检查USART的初始化代码，发现时钟使能函数写的是RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1, ENABLE)，这个在STM32里是对的，但在GD32里，USART1的时钟使能函数是rcu_periph_clock_enable(RCU_USART1)。原来GD32的库函数命名规则和STM32不同，我直接照搬STM32的代码，编译能通过，但实际没有使能时钟。

这个问题的教训是：GD32虽然兼容STM32，但库函数的命名和参数并不完全一致。迁移时不能只替换文件名，还要仔细核对每个函数的调用方式。我后来养成了一个习惯：每迁移一个外设，就先跑一个最简单的测试程序，确认外设能工作后再集成到主工程里。

另一个典型故障是GD32的Flash写入问题。我在做参数存储时，发现写入Flash后读出来的数据不对。排查后发现，GD32的Flash编程需要先解锁，再擦除，再写入，最后锁定。STM32的流程也是这样，但GD32的擦除时间比STM32长，如果擦除后立即写入，可能会失败。我在擦除和写入之间加了一个延时，问题就解决了。

5.3 CH32V103开发中的坑与解决方案

CH32V103的坑主要集中在工具链和中断处理上。第一个坑是中断向量表的重定位。CH32V103的启动文件里定义了中断向量表，默认放在Flash起始地址。如果你用了Bootloader，需要把应用程序的中断向量表偏移到Bootloader之后。STM32里用NVIC_SetVectorTable()函数来设置，CH32V103里需要修改链接脚本和启动文件，把向量表的起始地址改到应用程序的Flash地址。

第二个坑是RISC-V的中断处理机制和ARM不同。ARM Cortex-M的中断是硬件自动保存现场，而RISC-V需要软件保存现场。CH32V103的启动文件里已经写好了中断入口的汇编代码，但如果你自己写中断服务函数，要注意函数名和中断号的对应关系。我刚开始写串口中断时，把函数名写成了USART1_IRQHandler，但CH32V103的中断服务函数名是USART1_IRQHandler，看起来一样，但实际的中断号不同，导致中断无法触发。后来查了CH32V103的中断向量表，才发现USART1的中断号是25，而STM32里是37。

第三个坑是CH32V103的Flash编程。它的Flash编程流程和STM32类似，但需要先调用FLASH_Unlock()解锁，然后FLASH_ErasePage()擦除，再FLASH_ProgramWord()写入，最后FLASH_Lock()锁定。我遇到的问题是擦除后写入的数据偶尔会丢失，后来发现是擦除和写入之间的延时不够，CH32V103的Flash擦除需要大概20毫秒，我在代码里加了50毫秒的延时，问题就解决了。

5.4 跨平台代码移植的通用避坑指南

经过这一年的跨平台开发，我总结了几条通用的避坑经验。第一，不要假设库函数的行为一致。即使函数名相同，参数含义和返回值也可能不同。每次移植一个外设，都要先看目标平台的库函数文档，确认调用方式。

第二，时钟配置是移植中最容易出问题的地方。不同平台的默认时钟频率不同，PLL配置不同，外设时钟的使能方式也不同。我建议在移植完成后，第一件事就是用示波器测一下GPIO翻转频率，确认系统时钟正确。

第三，中断处理要重新核对。中断向量表、中断优先级、中断标志清除方式，这三个地方在跨平台时几乎一定会出问题。我通常会把中断服务函数单独拿出来测试，确认能正常触发和退出后，再集成到主程序里。

第四，Flash和RAM的地址范围要确认。不同芯片的Flash和RAM大小不同，链接脚本要相应修改。如果RAM不够用，程序可能会跑飞或者数据出错。我习惯在工程里加一个内存使用统计，编译完成后看一下RAM占用了多少，留出至少20%的余量。

第五，调试工具要提前准备好。STM32用ST-Link，GD32可以用ST-Link或GD-Link，CH32V103必须用WCH-Link。如果调试器不兼容，开发效率会大打折扣。我建议每个平台都配一个专用调试器，省得来回换。

6. 一年使用后的真实评价与选型建议

6.1 性能、成本与生态的综合对比

用了一年之后，我对这三个平台的评价可以总结成一张表：

从性能上看，GD32F303凭借M4内核和120MHz主频，在运算密集型任务中优势明显。STM32F103胜在均衡和稳定，适合大多数常规控制场景。CH32V103的RISC-V内核在整数运算上表现不错，但浮点性能是短板，适合通信和逻辑控制类应用。

从成本上看，CH32V103最便宜，GD32次之，STM32最贵。但成本不能只看芯片价格，还要考虑开发成本、迁移成本和维护成本。如果你的团队已经熟悉STM32，迁移到GD32的学习成本很低，一两天就能上手；迁移到CH32V103则需要重新学习工具链和中断处理机制，大概需要一到两周。

从生态上看，STM32的生态优势依然无法撼动。无论是官方文档、社区论坛、第三方库还是开源项目，STM32的资源都是最丰富的。GD32的生态在快速追赶，官方文档质量不错，社区也在壮大。CH32V103的生态相对薄弱，但沁恒提供了完整的中文文档和示例代码，对于中文用户来说够用了。

6.2 什么场景选什么芯片：我的实际建议

基于这一年的使用经验，我给出以下选型建议。

如果你的项目对稳定性要求极高，团队熟悉STM32生态，且预算充足，那就继续用STM32。它的确定性是其他平台暂时无法替代的。尤其是工业控制和医疗设备领域，STM32的长期供货记录和可靠性验证是重要加分项。

如果你需要更高的运算性能，同时想降低成本，GD32F303是很好的选择。它的M4内核和FPU在电机控制、数字信号处理等场景下优势明显，而且迁移成本低，适合从STM32升级的项目。但要注意GD32在某些外设细节上和STM32有差异，迁移时要仔细测试。

如果你对成本极度敏感，或者项目要求全国产化，CH32V103值得考虑。它的价格优势明显，RISC-V内核也符合自主可控的趋势。但你要做好心理准备：工具链需要适应，中断处理需要重新学习，外设资源比STM32少。适合通信网关、数据采集、简单控制等对算力要求不高的场景。

如果你在做毕业设计或者学习嵌入式，我建议从STM32F103开始。它的资料最多，遇到问题最容易找到答案。等熟悉了嵌入式开发的基本流程，再尝试GD32和CH32V103，你会发现不同平台的设计思路各有千秋。

6.3 国产芯片的未来展望与个人体会

这一年的使用让我对国产芯片有了更客观的认识。GD32和CH32V103都不是简单的"仿制"，它们在兼容STM32的同时，也在探索自己的技术路线。GD32选择了Cortex-M4内核，在性能上超越STM32F103；CH32V103选择了RISC-V内核，在自主可控上迈出了一步。

但差距依然存在。最明显的差距不在硬件参数，而在生态建设。STM32的生态是十几年积累的结果，国产芯片要在短时间内追上并不现实。不过我看到GD32和CH32V103的官方文档在持续更新，社区也在慢慢壮大，这个趋势是好的。

我个人在实际操作中的体会是：国产芯片已经能满足大部分常规应用的需求，但在一些细节上还需要打磨。比如GD32的ADC通道切换速度、CH32V103的中断响应延迟，这些在数据手册里不会写，只有实际用过才知道。所以我的建议是：选型时不要只看参数表，一定要拿样片实际测试，把关键功能跑一遍，确认能满足需求后再批量采购。

最后分享一个小技巧：如果你在多个平台之间迁移代码，建议把硬件相关的代码抽象成一层接口，比如hal_gpio_init()、hal_uart_send()，这样换平台时只需要重写接口层的实现，业务逻辑不用动。这个习惯我从STM32迁移到GD32时就开始用了，后来迁移到CH32V103时省了很多时间。这个内容后续还可以这样扩展：把三个平台的HAL层做成一个统一的库，支持通过宏定义切换平台，这样一套代码就能在三个平台上编译运行。