如果你最近在做GPS定位类产品应该能明显感觉到STM32F103这颗芯片的压力——供货周期不在自己手里、价格也不再是当年那种“随便买”的状态遇到行情波动时BOM成本说涨就涨。我们手里的GPS定位器项目就是因为这些原因把主控从STM32F103整体迁移到了一颗国产32位MCU上具体是国芯思辰的32位高性能系列。这篇内容我会把这次替换的选型逻辑、硬件改动、固件移植过程、调试踩坑完整记录一遍。如果你在准备做车载定位、资产追踪、手持GPS终端或者只是想把老产品从F103平台挪到国产平台这篇文章应该能提供一套相对完整的迁移参考。提到GPS平台很多工程师第一反应是“STM32F103不是挺够用吗”对单纯从性能角度确实够用。但“够用”和“能用得安心”是两回事。下面先从选型说起。1. GPS平台替换选型为什么绕过STM32F103选择国产32位MCU1.1 从备货周期开始的真实动机GPS定位器的主控任务并不重上电初始化传感器、通过串口读取GPS模块的NMEA数据、定期上报位置、响应远程指令。STM32F103在性能上完全满足这些场景甚至有点过剩。可真正让我们决定换主控的是供应链和成本不是性能。我们之前的平台用的是STM32F103C8T6在2022年到2023年连续两次遇到原厂交期拉长。第一次还是等第二次干脆因为缺货导致整机停产风险。后来发现市场上流通的大多是翻新片或Remark过的料价格虽然能谈但质量没有绝对保障。对于一个要长年通电、甚至可能装在车上的设备来说这种不确定性比性能短板可怕得多。所以在选替代方案时我们定了三条硬指标第一引脚封装能直接兼容现有PCB最好是pin-to-pin这样硬件改版成本最小第二外设数量和功能不低于STM32F103至少要有3路UART、2路SPI、2路I2C软件串口方案尽量不用第三供货和原厂支持能落到纸面上不能像某些小品牌一样今天报价明天断货。国芯思辰的32位高性能MCU就是在这一轮筛选中留下的。另外还有一个现实因素产品做国产化替代之后采购可以报备双供应商BOM里有两颗可以互相替换的主控这对整机成本谈判也很有帮助。即使原厂以后价格上调我们也有足够的切换空间。1.2 国芯思辰MCU与STM32F103的兼容性对比先说结论国芯思辰的这颗MCU在“兼容STM32F103”这件事上做的是皮兼容、芯不同。它不是简单地把寄存器原样复制而是让引脚、封装、内核架构和标准库的开发方式尽量对齐让原有工程能够低成本迁移。但如果你心里想着“把STM32F103的程序直接下进去就能跑”那一定会踩坑。我拿手里这颗芯片和STM32F103C8T6做个直观对比内核方面两者都是Arm Cortex-M3主频都能跑到72MHz这个决定了绝大部分代码逻辑不需要改动。封装方面目前这颗国产MCU提供LQFP48、LQFP64等常见封装和STM32F103C8T6/CBT6的引脚定义基本一致。外设方面具备3路UART、2路SPI、2路I2C、多个16位定时器、1路USB从设备控制器对GPS平台来说完全够用。烧录调试方面SWD接口兼容用现有的J-Link、DAP-Link连接器座都能直接连上。不兼容的地方主要在外设寄存器细节和时钟树。比如USART的错帧标志位、RCC时钟配置寄存器里的PLL倍频位定义以及部分定时器的更新事件重装策略都要对照原厂数据手册重新核对。我的建议是把“兼容”理解成“可移植”而不是“可替换”。PCB可以不改但固件一定要重新过一次。特别是中断向量表、启动文件、系统初始化部分这三块是移植中最容易出问题的地方后续章节会逐个展开。对比项STM32F103C8T6国芯思辰32位MCU内核Cortex-M3Cortex-M3最高主频72MHz72MHz封装LQFP48LQFP48等SWD调试支持支持启动文件原厂定义需替换外设寄存器原厂定义兼容但需核对表格里“启动文件需替换”是最容易被忽略的一点。很多朋友拿到国产MCU后直接把原工程的startup文件一起编进去了编译不报错但下到芯片里就跑飞。这类问题后面第三章我会细讲。2. 硬件方案改造GPS定位器的供电、串口与天线设计2.1 整机框架MCU、GPS模块和外围电路的搭配GPS定位器是一个典型的“低运算量、高稳定性”嵌入式设备。整机框架可以拆成四大部分主控MCU、GPS接收模块、无线通信模组有的产品上是4G Cat.1有的只有蓝牙、电源管理。主控工作在串口任务的第一线GPS模块以1Hz或5Hz频率输出NMEA语句主控解析后把经纬度、速度、卫星数、UTC时间提取出来再通过另一路串口发给4G模组上传云平台。与此同时PPS秒脉冲信号可以用来给本地RTC校时保证断电上报时事件时间戳不漂移。硬件设计上这个项目最需要盯紧的是三件事GPS模块的供电和串口电平、有源天线的馈电网络、射频走线布板。这三点做不好后面固件调得再好也白搭。2.2 NEO-M8N GPS模块接线实测与电平匹配我们用的GPS模块是u-blox的NEO-M8N开发阶段常用性能稳定资料也多。它的串口是3.3V TTL电平默认波特率9600bps数据格式为8N1上电后会持续输出NMEA语句。接线方式非常固定模块引脚作用接到MCUVCC3.3V供电3.3V不能接5VGND地GNDTXDNMEA输出MCU的USART_RX交叉RXD指令输入MCU的USART_TX交叉我第一次在这个项目上用NEO-M8N时图省事直接拿5V电源模块的LDO输出给GPS模块供电结果模块虽然能工作但在冷启动时频繁出现搜不到星的情况。后来查资料才发现模块的VCC范围是2.7V到3.6V超压供电会让内部射频前端工作点偏移灵敏度下降。改成单独的3.3V LDO供电后定位恢复正常。还有一个小经验GPS模块TXD到MCU RX之间我建议串一个10Ω电阻。这个电阻不会影响信号但能在模块插拔、静电放电时保护MCU的串口引脚。MCU RX配置为浮空输入或上拉输入根据MCU的GPIO结构来选不要在RX上再挂大电容会拖慢边沿。2.3 天线走线是定位精度的隐形决定因素GPS这个场景里很多人换了MCU之后发现“怎么定位精度变差了”其实问题通常不在MCU而在PCB改版时天线走线被动了。GPS信号非常弱民用GPS的典型电平只有-130dBm左右而LNA的增益也就20到30dB任何噪声耦合进入射频路径都可能直接把底噪抬高几个dB。天线走线我总结了几条硬规矩GPS射频线做50欧姆阻抗控制。如果板厂不支持叠层阻抗至少保证顶层走线宽度和介质厚度近似匹配走线越短越好。RF走线下方第二层必须有完整的参考地不能有电源分割线穿过。RF走线周围包地但包地不要形成闭合环路在两端开一个小口避免地环路。远离DCDC电感、SPI时钟线、USB差分线、PWM输出脚。我在一个版本上把RF走线从DCDC电感下穿过搜星正常但定位漂移几十米调整主板布局后恢复正常。有源天线的馈电要从VCC通过磁珠或高频电感进入RF通路避免数字电源噪声直接灌进LNA。天线区域保持净空顶层和底层都不要铺铜天线下方不要走任何高速信号金属外壳会直接屏蔽GPS信号如果产品必须放金属壳里天线要外置。这块建议在做原理图阶段就提前规划不要等PCB回来再调。PCB板厂的标准层叠优先选4层板GPS射频走线放顶层第二层完整地电源和底层信号各用一层这是最稳的组合。3. 固件移植实录从STM32F103标准库迁到国芯思辰平台3.1 工程模板与启动文件的第一道坎先说明一下我们原工程的背景基于STM32F103标准库v3.5.0代码结构是老嵌入式工程师都熟悉的那套模板——stm32f10x_conf.h、stm32f10x_it.c、startup_stm32f10x_hd.s、system_stm32f10x.c主循环里跑一个状态机定时器做调度UART中断收数据。迁移到国芯思辰MCU后第一件事不是改业务代码而是把启动文件和系统文件换掉。原因很简单Cortex-M3内核相同但芯片的Flash大小、SRAM地址、中断向量表入口都可能不同。如果继续用STM32F103的startup_stm32f10x_hd.s向量表指向的地址可能落在未定义区域芯片一上电就会跑飞。我们当时的做法是确认国芯思辰原厂提供了配套的启动文件和标准库如果提供的库版本是基于STM32标准库改的先把原来项目的Device文件夹整体替换。检查启动文件里的向量表包括Stack_Size、Heap_Size是否正确中断向量名称是否和外设完整对应。system文件里的SystemInit函数确认它有没有把时钟切到目标频率。替换完成后再检查链接脚本里的ROM/RAM起始地址和容量要和芯片实际规格一致。这一步花了我们一个下午不算难但非常枯燥。最容易踩的坑是“启动文件换了工程也能编译但上电死在HardFault”。这种情况八成是向量表偏移没做或者堆栈设置得太大超出了RAM区域。3.2 重写时钟初始化与串口波特率发生器的细节时钟配置是移植过程中最容易被低估的环节。STM32F103原工程里可能直接用了SystemInit加RCC_PLLConfig这套代码在国产MCU上大概率不能完全照搬。我们在迁移时经历过一个很典型的故障GPS模块的数据是出来了但偶尔乱码。用逻辑分析仪抓模块TXD波形波特率是对的9600bps但MCU解析出来就是错位。后来发现是HSE晶振频率配置不对。原工程默认8MHz外部晶振而国芯思辰的评估板上用的是12MHzPLL倍频系数还是按8MHz算的实际系统时钟跑到了108MHz串口波特率自然偏了。正确的做法是// 以标准库风格重配系统时钟注意HSE_VALUE要和实际晶振一致 #define HSE_VALUE 12000000U void SystemClock_Config(void) { RCC_DeInit(); RCC_HSEConfig(RCC_HSE_ON); while (RCC_WaitForHSEStartUp() ERROR) {} RCC_PLLConfig(RCC_PLLSource_HSE_Div1, RCC_PLLMul_6); // 12M * 6 72M RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK); RCC_HCLKConfig(RCC_SYSCLK_Div1); // AHB 72M RCC_PCLK1Config(RCC_HCLK_Div2); // APB1 36M RCC_PCLK2Config(RCC_HCLK_Div1); // APB2 72M }RCC_PLLMul的取值和具体芯片手册有关不要只看函数名要对着数据手册把倍频系数和分频系数确认一遍。原理上串口波特率由USART_BRR寄存器生成BRR 总线时钟 /16 × 波特率。所以只要总线时钟不是72MHz波特率就会跟随偏移。核对完时钟串口初始化里仍然建议把波特率目标值写清楚然后用库函数重新初始化一遍USART_InitStructure.USART_BaudRate 9600; USART_InitStructure.USART_WordLength USART_WordLength_8b; USART_InitStructure.USART_StopBits USART_StopBits_1; USART_InitStructure.USART_Parity USART_Parity_No; USART_InitStructure.USART_HardwareFlowControl USART_HardwareFlowControl_None; USART_InitStructure.USART_Mode USART_Mode_Rx | USART_Mode_Tx; USART_Init(USART1, USART_InitStructure);这段代码在国产库兼容标准库API时可以直接用但初始化前的RCC外设时钟使能、GPIO复用配置必须核对不能直接用F103的映射关系。3.3 用定时器外部中断扩展第二路软件串口GPS平台上串口数量经常不够用GPS模块占了一路硬件串口4G模组或蓝牙模组又占了一路想留一路给调试输出的话STM32F103通常只有3路USART分完基本见底。我们在这颗国产MCU上扩展了一路软件串口方案是用TIM加外部中断模拟。核心原理不复杂RX引脚配置成下降沿外部中断GPS或蓝牙数据帧起始位到来时触发中断此时启动定时器每隔一个位时间9600波特率下约104us采样RX电平一次连续采到一帧的停止位后把该字节写入FIFO。代码逻辑大概是这样// 软件串口接收状态机 #define SOFT_UART_BIT_TIME_US 104 // 9600baud void EXTI_SOFT_RX_IRQHandler(void) { if (soft_uart_state SOFT_UART_IDLE) { // 检测到起始位启动定时器准备采样 TIM_SetCounter(TIM3, 0); TIM_Cmd(TIM3, ENABLE); soft_uart_state SOFT_UART_START_BIT; soft_uart_bit_index 0; soft_uart_byte 0; return; } } void TIM3_IRQHandler(void) { uint8_t level GPIO_ReadInputDataBit(SOFT_RX_GPIO_PORT, SOFT_RX_GPIO_PIN); if (soft_uart_state SOFT_UART_START_BIT) { // 如果起始位采样不为低说明是毛刺重新等待 if (level ! 0) { soft_uart_state SOFT_UART_IDLE; TIM_Cmd(TIM3, DISABLE); return; } } else if (soft_uart_bit_index 8) { // 数据位LSB先来 soft_uart_byte 1; if (level) soft_uart_byte | 0x80; soft_uart_bit_index; } else { // 停止位 soft_uart_state SOFT_UART_IDLE; TIM_Cmd(TIM3, DISABLE); if (level ! 0) { soft_uart_push_fifo(soft_uart_byte); } } }上面是简化的骨架真正工程里还要处理位中点对齐和毛刺过滤但核心思路就是这样。需要提醒的是软件串口是拿CPU中断时间换外设数量9600波特率下每104us进一次中断CPU负载已经不小。适合用来接调试口、低速率传感器不适合跑高波特率通信。GPS主数据链路一定走硬件串口不要让软件串口担纲重要业务。4. GPS数据接收与解析背后的稳定性工程4.1 NMEA数据流的接收架构中断、FIFO与状态机GPS模块上电后会以突发方式输出一串NMEA语句常见的有GGA、RMC、GSA、GSV等。如果主程序用最简单的中断里逐字节解析逻辑虽然数据量不大但很容易因为某条语句处理时间稍长而丢掉后续字符。正确做法是“中断收数据、主循环做解析”。中断部分只做两件事从USART_DR读取一个字节把它写入环形FIFO。主循环检测FIFO非空时取出一个字符喂给解析状态机。这个架构在GPS和4G共存时依然稳定因为解析逻辑不会阻塞串口中断。FIFO实现可以用一个最简单的循环队列#define GPS_FIFO_SIZE 512 static volatile uint8_t gps_fifo[GPS_FIFO_SIZE]; static volatile uint16_t gps_fifo_head 0; static volatile uint16_t gps_fifo_tail 0; void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE) ! RESET) { uint8_t c (uint8_t)USART_ReceiveData(USART1); uint16_t next (gps_fifo_head 1) % GPS_FIFO_SIZE; if (next ! gps_fifo_tail) { gps_fifo[gps_fifo_head] c; gps_fifo_head next; } // 如果next tail说明FIFO满丢弃最老数据或立刻置溢出标志 } } uint8_t gps_fifo_read(uint8_t *c) { if (gps_fifo_head gps_fifo_tail) { return 0; } *c gps_fifo[gps_fifo_tail]; gps_fifo_tail (gps_fifo_tail 1) % GPS_FIFO_SIZE; return 1; }FIFO大小我建议至少512字节。别觉得GPS数据少就吝啬因为模块冷启动时会缓存一段时间的历史定位信息上电瞬间会一次性把多条语句吐出来。64字节的FIFO在这里肯定不够用。4.2 解析GGA/RMC的框架设计与校验逻辑NMEA 0183协议里最需要解析的是GGA和RMC。RMC包含经纬度、速度、日期基本是定位器上报的核心GGA包含卫星数和海拔适合辅助判断信号质量。解析前必须先做校验和验证。NMEA的校验和算法是从$之后到之前的所有字符按位异或结果以两位十六进制ASCII字符跟在后面。// msg指向$后的第一个字符遇到*结束 uint8_t nmea_checksum(const char *msg) { uint8_t sum 0; while (*msg *msg ! *) { sum ^ (uint8_t)(*msg); } return sum; }解析时不要用标准库的sscanf或printf走一遍浮点GPS平台的MCU资源不算充裕而且float转字符串的开销和精度都不理想。NMEA纬度格式是ddmm.mmmm经度是dddmm.mmmm可以用定点数方式处理把度分字符串拆开度部分乘1e6分部分转换成小数度后加到结果上。举个例子语句$GPGGA里纬度字段如果是“2232.12345”表示22度32.12345分。换算成以1e-6度为单位的整数大约是22乘1e6再加上32.12345除以60乘1e6得到约22535391。这样就能用int32_t做比较和传输不怕精度异常。RMC和GGA字段都算好分割点后用一个轻量级状态机按“字段序号”做解析。不要每个字符都调strstr找“GGA”那样在高频率解析时会浪费大量CPU周期。4.3 定位误差排查从天线净空到多径干扰移植完成后我们在测试场遇到一个“冷启动定位时间变长、定位后漂移几十米”的现象。一开始怀疑MCU主频有问题后来用替换法和实际测量一步步排查最后定位到有源天线馈电部分。GPS定位误差的来源很多但工程现场最常见的几个原因是天线净空不足被PCB铺铜、金属支架、锂电池外壳遮挡。GPS信号经过衰减后模块内部灵敏度再高也抵不过物理遮挡。有源天线供电不足。有源天线内置LNA需要稳定的3V到3.3V供电如果馈电点电压被拉低LNA增益会下降等效灵敏度变差。多径干扰。在城市峡谷或仓库里信号从建筑物反射后进入天线导致定位点来回漂移。这类问题很难靠固件完全解决更多是天线选型和安装位置的问题。供电纹波耦合。GPS模块和天线馈电共用DCDC输出且纹波大时会直接影响射频底噪。我们最后在馈电网络里加了磁珠后漂移现象明显缓解。排查定位误差的思路和排查普通硬件问题一样先固定一个开阔平地用同一颗模块接外置参考天线做基准再和产品上的GPS输出对比。如果基准很好而产品差问题就在天线、馈电和PCB布局如果基准也差就要检查模块本身或射频干扰。别一上来就调固件。5. 移植调试中的异常现场与修复方案5.1 串口丢包的真正元凶临界区与FIFO深度“STM32F103串口中断接收掉数据包”这个问题在网上很常见我们在迁移国芯思辰MCU后也碰到了。第一次现象是GPS模块连续输出NMEA时偶尔出现一整条语句缺失。排查下来不是波特率问题而是FIFO溢出。原因前面提过模块上电瞬间会缓存多条历史位置一次性涌出来64字节的小FIFO直接爆掉。第二次现象更隐蔽只要开启了4G模组的AT指令解析GPS串口就开始掉字。跟踪代码发现我们在AT指令处理的某个临界区里关闭了中断关闭期间GPS的中断被屏蔽FIFO没有及时填充等中断恢复后模块已经把数据发完了硬件FIFO被新数据覆盖。这个坑的本质是“临界区时间过长”。解决办法总结为三条中断里只做寄存器读取和FIFO写入不做解析、不做打印、不做延时。FIFO深度做够GPS这类突发数据建议512字节起。临界区保护范围要尽量小。如果临界区执行时间超过一个位时间的十倍就要考虑硬件DMA接收而不是中断接收。如果最终还是要追求极致可靠可以改DMA加IDLE中断方案串口配置为DMA循环接收收到空闲帧时触发一次空闲中断主循环再处理完整帧。这样CPU负载更低硬件FIFO溢出概率也小得多。国产MCU的DMA控制器和F103有差异配置前一定核对寄存器描述。5.2 HardFault追踪通过故障监控程序补位移植过程中HardFault是躲不掉的。标准Cortex-M3芯片的HardFault_Handler默认是一个死循环出了故障无法定位。我们这次给工程加了一个简单的HardFault现场保存函数。Cortex-M3进HardFault时硬件会自动把一部分寄存器压栈压栈顺序是xPSR、PC、LR、R12、R3、R2、R1、R0。通过分析进入异常前的LR值可以判断用的是MSP还是PSP然后把栈指针取出来就能读到出错的PC。一个常见的实现模板是void HardFault_Handler(void) { __asm volatile( TST LR, #4\n ITE EQ\n MRSEQ R0, MSP\n MRSNE R0, PSP\n B hard_fault_dump\n ); } void hard_fault_dump(uint32_t *stack) { // stack[0] R0 // stack[1] R1 // stack[2] R2 // stack[3] R3 // stack[4] R12 // stack[5] LR // stack[6] PC // stack[7] xPSR while (1); }实际调试时不要在hard_fault_dump里写太复杂的逻辑内部可能又触发异常。最简单的方法是把stack数组复制到一个固定的全局缓冲区然后通过调试器读出来或者通过日志带出来。这个项目里我们遇到的HardFault根因是某个指针在GPS语句解析越界后把内存写坏触发了一次野指针跳转。用这个监控程序把PC值抓出来反汇编后立刻看到地址落在了一个数组后面不到半小时就锁定了问题。5.3 用USB虚拟串口输出调试日志的小技巧GPS定位器没有屏幕常规的串口调试口在量产板上可能已经砍掉了。我们在调试版上用了USB虚拟串口把printf输出重定向到USB_CDC这样既能保持业务串口不被占用又能用PC直接看日志。STM32F103的USB虚拟串口例程很多库版本v4.0的工程可以直接迁移到国芯思辰平台上但需要确认USB外设寄存器是否对齐。移植时特别注意两点USB D上拉电阻由3.3V接到USB_DP引脚部分国产MCU会把上拉电阻内置需要配置对应寄存器。USB中断优先级和PWM定时器中断不要冲突。USB是一个异步低速设备中断处理不及时会导致枚举失败或者通信卡死。如果国产MCU的USB驱动还没有做到完全无缝替换一个保守方案是调试版把USART3当调试口量产版再用USB做固件升级或数据传输。我们在4G模组版产品上实际量产选择的是普通串口方案USB虚拟串口只在实验室调试时用这个取舍要看你产品的架构。6. 迁移完成后的收益总结与可扩展方向6.1 替换后的性能与功耗实测移植完成后我们把GPS平台跑了一轮长时间老化测试基本结论是72MHz主频的国芯思辰MCU在这个应用场景下表现足够完全没有性能焦虑。GPS数据解析的主循环CPU占用率大概在30%以下剩余资源还能同时处理4G模组的AT指令、心跳包发送和按键逻辑。设备冷启动从复位到主循环大约几十毫秒和F103的体感差别不大。功耗方面GPS定位器整机电流由模块和通信模组主导主控侧的低功耗策略才是关键——我们用待机模式加串口唤醒待机电流比运行电流降低明显。如果产品对功耗敏感建议重点优化休眠-唤醒时序而不是特意去追MCU标称的微安级待机电流。有一点要提醒不要只看主频要实测你的整机业务在目标芯片上的实际功耗。国产MCU的低功耗模式和F103的停止模式一样都要把GPIO状态、外部中断触发方式和时钟源配置清楚否则会出现“看着睡了实际上还在耗电”的尴尬情况。6.2 后续功能扩展思路这次迁移不仅解决了供应链问题还顺手把GPS平台的数据处理框架理顺了。基于现在的“中断接收加FIFO加状态机解析”架构后面加功能非常顺手接入4G Cat.1模组把RMC解析出的经纬度、速度上报到MQTT或HTTP平台做实时位置服务。加三轴加速度计用MCU的INT1中断脚唤醒主控实现震动唤醒、静止休眠和碰撞检测。把GGA里的卫星数和海拔结合地理围栏算法在本地判断是否越界省掉服务器端的频繁拉取。用GPS的PPS秒脉冲给本地RTC做校时让设备日志时间戳和UTC对齐对数据回溯和审计都有帮助。蓝牙扩展可以优先复用我们的软件串口方案做近场配置和蓝牙信标不用再占用硬件串口资源。这些扩展都不需要重新设计硬件框架主控的资源和引脚余量都足够。最后分享一点我个人的体会。这次把GPS平台从STM32F103换到国芯思辰32位MCU真正花时间的不是写业务代码而是把“兼容”这个词背后的差异一条条抠清楚。启动文件、时钟树、寄存器定义、外设复用关系每个环节都可能留下一个看似神秘的问题。如果你也打算做类似的替换我的建议是别一上来就盯着业务流程先把最小系统跑通串口回环测一遍再上GPS数据流。调试工具里最好备一台逻辑分析仪和一把烙铁很多玄学问题最后都是接触和时序问题跟芯片品牌无关。
