你可能也被“STM32FPGA双核技术系统”这个标题吸引过。刚开始接触这个概念时我也在想这到底是硬核炫技还是真有需求直到我拿到一个四路频率测量、一路MIPI图像采集、步进电机加减速控制、最后还要把数据上报云端的项目才彻底明白有些活单靠MCU能凑合单靠FPGA也能硬扛但一起做就会特别痛苦。STM32FPGA双核系统的本质不是两块芯片叠在一起而是把“会做事”和“能扛事”的两个角色凑成一个高效团队。这套方案适合谁参考适合那些已经在用STM32但发现定时器、GPIO翻转速度、外部总线带宽不够用的朋友也适合刚入门FPGA、想找一个真实项目把状态机、FIFO、UART、LVDS这些模块串起来的新手。今天这篇文章不打算写成论文只从我自己实际做过的项目出发把架构、接口、测频、显示、电机、上云这些环节的取舍和坑一次讲清楚。1. 为什么“STM32FPGA双核”不是叠buff1.1 两颗芯片的性格差异STM32是典型的顺序执行处理器主频一般几十到几百MHz跑指令、跑RTOS、跑TCP/IP协议栈是它的强项。它的外设非常丰富串口、CAN、ADC、DMA、以太网、USB基本上一颗芯片能搞定一个控制板的全部需求。但它的致命问题在于“时间确定性”同一个操作可能因为中断、总线仲裁、Cache命中与否消耗的时间完全不同。你很难用它去实现ns级别稳定的脉冲输出或高速并行数据采集。FPGA则是完全另一种性格。它没有“指令流”所有的逻辑都是并行化的硬件电路。你可以同时跑十个计数器、八个FIFO、两组LVDS差分线而且每个逻辑单元的处理时延是确定的。但它不适合写复杂协议代码。你要是在FPGA里硬写一个完整MQTT客户端或者跑文件系统那个工作量足以让人怀疑人生。所以STM32FPGA双核的第一层逻辑是让两个人干各自擅长的事。STM32负责“干什么”FPGA负责“怎么干得又快又稳”。这就像项目经理和车间流水线的关系你给项目经理说“今天出100件货”他能拆任务、协调资源、处理异常但真正一个时钟周期出一个结果的重复劳动必须交给流水线。1.2 任务怎么切控制面和数据面分离我一般把系统分成两个平面控制面和数据面。控制面包括命令解析、状态管理、通信协议、电机轨迹计算、用户交互这些全部放在STM32数据面包括数据采样、等精度测频、边沿捕捉、DDS波形生成、图像行场同步、串行差分接收这些放在FPGA。拿我做过的一套测频系统举例。STM32负责接收上位机命令比如“测1秒、通道A、显示到LCD”然后把参数打包通过FSMC接口写进FPGA寄存器FPGA收到配置后立刻启动硬件计数器等计数结束把结果放在一个双端口RAM里拉一个中断通知STM32来读。整个过程STM32只做了两次配置和一次读数据剩下的高频计数全部在FPGA内部跑测频精度直接取决于参考时钟而不是CPU中断抖动。这种切分还有个好处调试边界清晰。FPGA出问题时多半是时序或状态机问题STM32出问题时多半是协议或外设配置问题。把调试范围缩小排错效率会显著提升。1.3 哪些场景值得上双核不是所有项目都需要STM32FPGA。普通传感器采集、低速控制一颗STM32绰绰有余简单的逻辑替换一颗FPGA也能应付。真正值得用双核的场景有几个明显特征需要并行执行多个实时任务比如同时测频、同时采集图像、同时输出多路PWM需要高带宽数据传输比如高速ADC采样后的数据必须在几个时钟内搬走需要对外设接口做自定义扩展比如用普通IO模拟MIPI、LVDS或专用传感器时序需要系统在恶劣电磁环境下稳定运行FPGA的硬件逻辑比中断驱动的MCU更适合扛干扰。反之如果你只是点个灯、读个温湿度强行上双核就是给自己制造不必要的麻烦。双核系统的成本、功耗、PCB面积、开发难度都是成倍增长的项目立项前一定要做“加减法”加法留给确定性计算减法砍掉不必要的并行扩展。2. 双核系统架构与关键接口设计2.1 选型先算账引脚、资源、带宽很多朋友一开始就在纠结选哪颗FPGA、哪个STM32型号。我的建议是先算账后选型至少算三笔账引脚数、逻辑资源、通信带宽。先看引脚数。FPGA要接多少外部信号摄像头并行数据可能有8~16位ADC可能有12~16位多路频率测量要分配3~5个通道LCD如果是RGB接口还要二十多根线。把这些引脚全部列出来加上时钟、复位、调试脚就基本确定了FPGA的最小封装。千万别只看核心逻辑最后发现引脚不够就尴尬了。系统里那几个IO口我习惯留出20%的余量方便调试和后期扩展。再看逻辑资源。想做DDS波形发生器、等精度测频、UART、FIFO、状态机这类模块用不了太多资源入门级FPGA完全够如果要做图像缓存、MIPI接收、LVDS转并行数据资源占用就会迅速上升尤其是Block RAM。图像的一行数据就要几KB一帧缓存更是几百KB起步选型前务必估算存储资源。最后算通信带宽。假设STM32和FPGA之间要在1秒内传一帧320x240的灰度图像数据量约76KB。用SPI的话如果SPI跑20MHz理论带宽只有2.5MB/s扣除协议开销勉强够用用8位并口加读写控制跑30MHz带宽就有30MB/s余地充分。高速图像场景我基本不会用SPI直接上FSMC或自定义并行总线。接口方式典型带宽优点适用场景UART0.1~1MB/s简单、抗干扰好低速控制、调试信息SPI/QSPI2~50MB/s引脚少、速率可调小包数据、LCD控制8/16位并行10~100MB/s带宽大、时序直观图像、高速采样FSMC/FMC与STM32总线同步可映射成内存地址大数据量批量存取2.2 STM32与FPGA之间怎么连才不憋屈选好接口协议后硬件连接方式通常有三种直接GPIO直连、并行总线、差分信号。低速控制命令用GPIO直连就够一个写使能、加8位数据、加一个中断信号简单粗暴也好排查问题。STM32先拉低片选和写信号把数据放到数据线然后拉高写使能FPGA在上升沿采样。这个过程用示波器抓一下就知道有没有问题。如果数据量一大GPIO直连会非常痛苦这时候就要用FSMC/FMC。FSMC能把FPGA映射到STM32的地址空间STM32直接往变量地址写数据就像操作内部RAM一样。硬件连接上把FSMC的地址线、数据线、NBL、NOE、NWE连到FPGAFPGA内部写一个简单的总线从设备逻辑解析地址和读写信号。这个方案我用了很多年最直观的好处是STM32代码里不需要显式封装复杂的读写字函数一句*(volatile uint16_t*)0x60000000 value;就完成了传输。对于LVDS这种高速差分信号就不能用普通GPIO直连了。STM32几乎没有原生LVDS接口通常由FPGA接收LVDS转成并行数据后再通过FSMC桥给STM32。这里有个关键点FPGA的LVDS输入引脚必须做差分端接常见做法是在PCB上靠近FPGA放置100欧姆差分电阻如果IO Bank支持内部端接可以直接配置Internal Termination省掉外围电阻但不同系列的FPGA能力不同用前一定要查Datasheet。2.3 通信协议和缓存设计STM32和FPGA之间的通信协议建议用一个简单可靠的帧格式。我常用的是帧头2字节、命令字1字节、长度1字节、数据区N字节、CRC校验2字节。MCU发命令给FPGA时FPGA解析帧头、校验CRC然后执行FPGA回传数据时同样按这个格式组帧。这里有一点要提醒两条芯片之间的接口容易受干扰特别是电机驱动、继电器动作时偶发数据错误概率会高很多。如果没做CRC校验后期排查会非常痛苦。CRC简单点可以用CRC-16/CCITT在FPGA里是组合逻辑或者LFSR状态机资源开销很小。数据量大的时候协议之上必须加缓存机制。FPGA侧在收到数据后先放进一个FIFO或双端口RAMSTM32再通过DMA过来搬运不要每次一个字都靠中断。双缓冲是另一个实用技巧FPGA将“当前帧”写入Buffer A同时“下一帧”在Buffer B积累帧同步信号到来时再切换避免STM32读到一半数据被更新。这个机制在图像采集和高速ADC项目中尤其重要。有人会问STM32里跑FreeRTOS怎么和这些缓存结构对接我的做法是定义一个共享数据模型比如MeasurementData g_fpgaData; SemaphoreHandle_t g_dataReadySem;。FPGA通过中断通知STM32后中断服务函数里只GiveSemaphore真正读取数据的任务在等待到信号量后从FIFO或双口RAM里拷贝数据。这样中断处理时间极短既不阻塞系统又保证数据不会丢。2.4 时钟、复位与电源设计双核系统的时钟设计比单芯片系统更容易出问题。STM32和FPGA通常各自用晶振但两者之间传递数据时必须考虑跨时钟域。FPGA内部模块经常用到多时钟域比如系统主时钟50MHz、采样时钟120MHz、串口时钟波特率分频跨时钟域的信号处理不好就会出现偶发错码、状态机跳飞。几个常用的处理办法单个bit信号用两级或三级同步寄存器打拍多位数据用异步FIFO或握手协议对严格要求对齐的场景可以把STM32侧接口时钟直接引给FPGA做输入让FPGA采样逻辑使用统一的接口时钟。我自己就吃过跨时钟域的亏一个标志信号没同步就直接用结果大约每十分钟出现一次状态机误触发查了一整天才定位到。从那以后凡是跨时钟域的握手信号一律先打三拍。复位设计也容易被忽略。FPGA上电后不建议直接进入主逻辑最好用一个“上电复位按键复位”的组合复位信号要经过施密特触发器或RC滤波消除毛刺。STM32侧如果是用外部复位复位时间要足够长至少满足FPGA配置完成再加几个毫秒否则FPGA还没加载完毕STM32就开始初始化外设两者通信会失败。电源方面可以考虑先给FPGA供电保证其完成配置后再让STM32运行。简单做法是两个芯片各用独立LDO或DC-DC通过使能脚控制时序。STM32和FPGA的IO电平也要匹配STM32常用3.3VFPGA也支持3.3V但LVDS bank通常需要单独的差分参考电压不容搞混。3. 核心模块实战测频、显示、电机、上云3.1 频率测量为什么FPGA做得更“稳”我最常被问到的FPGA项目就是频率测量。STM32本身有定时器的输入捕获模式测低频信号很简单比如测量1kHz PWM用输入捕获配合DWT延时误差几个Hz完全没问题。但一旦信号频率升到几十MHz或者要求同时测多路频率STM32定时器就显得力不从心。这时FPGA用等精度测量法是更好的选择。等精度测频的思路很简单设一个基准闸门时间T比如1秒在闸门开启期间同时统计被测信号的上升沿个数Nx和基准时钟的上升沿个数Ns。如果基准时钟频率为Fs那么被测频率Fx Nx / Ns * Fs。因为闸门开启与待测信号同步所以被测信号计数没有量化误差误差只取决于基准时钟。用FPGA实现时状态机生成一个“闸门开/关”信号两个计数器分别累加闸门关闭后锁存计数值等待STM32读取。// 简单的等精度测频计数器内核伪代码风格 reg gate_q, gate_sync; reg [31:0] counter_ref, counter_sig; wire gate_rise gate_q !gate_prev; reg [31:0] ref_latched, sig_latched; always (posedge clk_ref) begin if (counter_ref TARGET_COUNT) begin counter_ref 0; gate_internal 1b0; end else if (start_cmd) begin counter_ref 0; gate_internal 1b1; end else if (gate_internal) begin counter_ref counter_ref 1; end // 同步待测信号边沿再用它做闸门同步 // 实际要注意跨时钟域处理 end这个模块做完后STM32侧的工作就很简单了写寄存器启动测量轮询中断标志读完两个计数值再套公式计算。我实测下来以50MHz参考时钟、1秒闸门频率分辨率能做到几Hz以内而且STM32任务切换和中断嵌套完全不影响测量结果。这就是双核系统最真实的收益。3.2 LCD显示一次把ILI9341和中文编码问题说透很多热词里都提到STM32LCD尤其是ILI9341读ID问题是A1A1。这块芯片在国产开发板上太常见了驱动方式有SPI、8位并口、16位并口。我通常用SPI刷显示因为接线简单但SPI刷全屏比较慢适合显示文字和简单图形如果要做流畅的UI动态刷新建议还是用并口或FSMC。ILI9341读ID踩坑很多。正常情况下用命令0xD3可以读到三个字节正确结果类似0x00 0x93 0x41如果你从软件SPI调试串口读出来是0xA1A1多半不是型号不对而是MISO配置有问题。软件SPI读数据时主机必须在发完命令字节后立刻将MISO引脚切换为输入模式并留出足够的时间让从机驱动数据线如果MISO一直保持推挽输出模式或者读数据时选的采样沿不对ID读回来就是乱码。硬件上MISO线最好加上拉电阻对读ID这类慢速操作更可靠。GBK转UTF8也是中文显示的经典问题。STM32内部如果只存UTF8字符串ILI9341驱动里的中文字库通常以GB2312/GBK编码索引两者不一致就会显示乱码。有两个解决办法一是上位机在生成字库时先把编码统一成GBK代码里不转码二是在STM32内做一张转换表把UTF8字符串转成GBK再查字库。第二种方法灵活但占Flash我一般只保留常用汉字转一次就存缓存数组。FPGA还能配合LCD做更复杂的事比如用FPGA产生RGB LCD的时序、把STM32写入的显存数据扫描到屏幕上这能让STM32彻底摆脱刷屏消耗。不过这个方案要占用FPGA逻辑和RAM属于双核系统里比较进阶的做法。如果你只想把LCD当一个监控面板STM32SPI完全够用。3.3 步进和伺服STM32算轨迹FPGA发脉冲电机控制是“双核分工”最典型的例子。五线四相步进电机可以直接由STM32定时器产生PWM脉冲但在多轴联动、高频脉冲输出、加减速要求严格的场合STM32定时器处理会显得很吃力。我用过的方案是STM32负责插补计算把每一步的脉冲间隔、方向、步数写进FPGA的寄存器FPGA内部维护一个脉冲发生器定时发送脉冲给驱动器再实时产生方向信号。FPGA里做脉冲发生器其实很简单一个计数器一个比较寄存器。计数器累加到比较值就翻转一次脉冲输出同时更新下一个步长的比较值。这个比较值就是STM32算出来的当前速度对应的定时周期速度越快周期越短。加减速曲线可以预先算好放在STM32的RAM里运行时逐条写入FPGA。这样即使STM32被中断拖住十几微秒脉冲输出依然不会有抖动驱动器就不会因为丢脉冲而失步。伺服电机通过485控制时也类似。STM32负责Modbus或自定义485协议栈FPGA负责监控编码器反馈信号。因为FPGA能在几个时钟周期内捕捉编码器AB相脉冲位置计数非常准。你可以在FPGA里做一个硬件位置计时器STM32通过FSMC接口周期性读取当前位置这样系统响应速度就比单纯靠STM32外部中断计数快得多。有人会质疑FPGA做485会浪费其实如果只需要发送ASCII字符串比如状态查询命令FPGA串口模块也能轻松实现但完整的PID闭环、伺服参数读写、模式切换这些逻辑还是STM32更适合。3.4 物联网网关FreeRTOSLwIP巴法云在双核系统里STM32还有另一个大任务联网。FreeRTOS配LwIP是目前很成熟的方案再接一个MQTT库就能接入巴法云这类物联网平台。FPGA采集数据不等于系统上云真正要把数据上报还需要协议栈、时间戳、异常重传、设备管理等软件层面的东西。我习惯把整个上报流程拆成几个任务采集任务从FPGA读取数据转换成人读得懂的单位协议任务负责MQTT主题整理、QoS等级设置、心跳包维护云平台上报任务定时把最新数据发布到主题。FreeRTOS的任务优先级要排好一般把数据采集任务设为最高优先级因为它直接影响实时性MQTT网络任务可以放低一些LwIP调用不能阻塞其他任务必要时用消息队列传递数据。巴法云这类平台接入时一个常见坑是MQTT连接不稳定。测试阶段直接用IP连没问题换成域名后就会因为DNS解析失败而掉线。解决办法是不要把域名解析放在任务启动流程的关键路径上可以先解析一次缓存业务线程与网络线程分离。在FPGA侧采集的数据最好先用环形缓冲保留最近几十个采样点等MQTT恢复后集中补报这样数据不会完全丢失。STM32里保存配置数据也需要处理端序和编码。很多时候ASCII和UTF8混着来比如设备序列号用ASCII设备名称用UTF8云平台上显示才会正常。如果全部硬编码后面改配置非常麻烦。我在这个时候才体会到双核系统并不是只管FPGA的并行逻辑STM32侧的任务架构如果没设计好照样会拖后腿。3.5 顺便讲个低成本的FPGA信号发生器信号发生器也是FPGA入门常见的项目几乎是DDS的教科书级应用。DDS原理不复杂用一个相位累加器每个时钟周期加一次频率控制字高位数作为ROM查找表的地址ROM里存正弦波一个周期的幅值数据输出就是正弦波。给定时钟频率Fclk、相位累加器位数N输出频率fout fctrl * Fclk / 2^N。我在系统里把DDS频率控制字交给STM32计算FPGA只需要实现累加器和ROM查找。STM32收到用户按键或上位机命令算出fctrl后通过接口写入FPGAFPGA就能稳定输出对应频率。实测下来50MHz系统时钟、32位累加器几Hz以上频率都能稳定输出到外部运放。如果想让输出波形更平滑可以在FPGA内再加一级Sinc插值滤波器但波形质量要求不高时这步可以省掉。用FPGA做信号发生器有个好处多路输出、扫频、方波、三角波都能同时生成而且互不干扰。STM32做参数输入和显示FPGA做波形生成正好把双核系统中的“机器语言”和“人机接口”分得明明白白。你要是想在FPGA里用UART发送ASCII字符串给电脑端显示频率值也不是难事一个简单的波特率发生器加状态机就能完成但调试时还是建议优先用串口从STM32打印省得两头查。4. 联调、工具链与固件协作4.1 STM32工程搭建从CubeMX到VSCodeJ-Link最近几年STM32开发环境变化不小除了Keil越来越多团队开始用VSCodeCMakeJ-Link。我第一次把工程从Keil迁移到VSCode时最大的感受是代码检索和Git对比确实舒服但环境配置比Keil麻烦很多。核心步骤如下先用STM32CubeMX生成外设初始化代码图形化配置FSMC、UART、ADC、GPIO再用STM32CubeCLT或GCC工具链编译最后通过VSCode的Cortex-Debug插件连接SEGGER J-Link配置好device、interface、swd这些参数。芯片包安装也是一道关卡。CubeMX下载芯片支持包时经常很慢或失败我习惯直接从ST官网手动下载对应封装的包然后导入CubeMX信息库。VSCode下调试时J-Link固件版本和驱动要匹配有些老J-Link在新驱动下会报“The connected probe appears to be a clone”之类的错误那大概率是固件太旧需要用J-Link Commander升级。有人喜欢直接在工程里写裸机代码但我建议跑FreeRTOS。双核系统里STM32往往要处理通信、显示、云平台等多个任务裸机主循环加中断的处理模式很容易变得混乱。FreeRTOS的队列、信号量、任务通知都特别适合承接FPGA中断触发的事件流。4.2 FPGA开发流程和几个提升效率的习惯FPGA开发流程比STM32更依赖工具链。无论是Quartus还是Vivado从头到尾都要经过设计输入、仿真、综合、布局布线、时序分析、比特流生成、下载调试。新手最容易犯的错是不做仿真直接上板。一个简单的状态机加上跨时钟域信号仿真不跑上板查错可能要花十倍时间。ModelSim或者Vivado自带的Simulator都能用别嫌仿真麻烦。我在FPGA内部写模块时会严格划分时钟域每个模块顶层只接收来自同一个时钟域的输入。跨时钟域的FIFO用现成的IP核生成不要自己手写。组合逻辑块的时序也挺关键时序不满足时先看关键路径是“寄存器到寄存器”长还是“引脚到寄存器”长。后者多半是引脚约束或IO标准配置问题比如LVDS输入没有设置差分端接。还值得提一下状态机编码。FPGA里状态机可以用独热码或二进制码。独热码每个状态只有一个bit为1译码逻辑简单组合逻辑延时小速度能跑得更高但触发器用得多二进制码最省寄存器适合状态多、逻辑不复杂的场景。我一般优先用独热码因为FPGA逻辑单元里触发器资源比较充裕而时序收敛更重要。case语句里必须给默认分支防止状态机进入非法状态。4.3 双核联调的Debug三板斧STM32和FPGA联调最怕两边都觉得自己没错。我把这几年积累的调试技巧归纳成三板斧第一板斧是分模块回环测试第二板斧是抓波形第三板斧是设计观测点。分模块回环测试就是把通信先断开各自验证自身功能。FPGA单独用SignalTap或ILA抓内部信号STM32单独用串口打印寄存器数据。两边都确认没问题后再把FSMC或SPI物理总线接上。联调时优先检验的是CS信号、WR/RD信号、Busy/ACK反馈而不是上来就看最终数据对不对。时序上有一点偏差数据可能整体错位。抓波形要用逻辑分析仪别只依赖示波器。STM32的FSMC写周期通常只有几十纳秒示波器单触发抓一次绝对没问题但想要看波形序列和时序关系逻辑分析仪更好用。可以把CS、WR、地址线、数据线上的触发条件设为“CS下降沿且WR上升沿出现时”一次就能抓到完整写周期。观测点是指代码里的调试追踪点。STM32侧每个关键函数入口出口打串口日志带上时间戳FPGA侧把状态机当前状态、FIFO水位、握手信号引到空闲引脚用逻辑分析仪实时观察。两边的时间戳对应不上时优先怀疑通信协议和位宽配置而不是功能逻辑。这套方法几乎能解决我遇到过的所有“偶发”问题。5. 我踩过的坑随便挑几个说5.1 板上信号完整性相关坑双核系统有高速信号、低速信号、电机电源混合信号完整性问题特别多。最典型的坑是FPGA的LVDS接收线和普通GPIO挨得太近差分线没有做阻抗控制导致高频率时接收误码。解决方法是PCB布线时LVDS差分对走线要等长、靠近、包地远离时钟线和开关电源。另一个坑是FPGA IO口配置成Hysteresis Input Mode。这个模式其实很有用施密特触发器输入可以增大最小输入电压和最大输入电压之间的门限宽度对边沿缓慢的信号非常友好。按键、编码器、外部低频方波信号如果不用这个模式按键抖动、编码器毛刺都可能被当成有效边沿。但开滞回之后输入切换点的迟滞会让信号边沿在时间上有一点偏移测频率或测相位时需要考虑必要时还是转化为差分或被同步后的信号。电源噪声也很常见。FPGA核心电压和IO电压分开供电很多板子为了省钱共用LDO结果FPGA内部翻转电流一大STM32和FPGA之间的通信就开始出错。后来我把FPGA内核电源单独用DC-DC或低噪声LDO供电再用磁珠隔离数字地和模拟地通信才恢复稳定。双核系统的地平面设计要从一开始就考虑不能靠飞线解决。5.2 STM32外设的经典问题STM32外设坑数起来一大串这里挑几个高频的。ADC切换通道后第一两次采样值经常异常这个我在驱动多通道ADC时经常遇到。解决方法是每次切换通道后写入足够长的采样时间或者连续采样两次丢弃第一次结果。ADC的参考电压也尽量用外部基准内部VREF受温度影响比较大会影响测量精度。CAN通信突然连不上也是网上问得最多的问题。表面上看总线没问题代码没变但就是进不了中断。排查时先看总线电平CANH和CANL间有2.5V左右的差分电压再看是否每侧都加了120欧终端电阻。如果总线没问题查看波特率是否因为系统主频变化产生了误差CAN波特率容差要求很高主频即使差一点也可能导致同步失败。项目里我都是先从DBG接口重新烧写程序在连接稳定时修改配置不要等出问题再想怎么恢复。STM32把JTAG引脚复用成普通IO也是一个隐蔽的坑。PA15、PB3、PB4默认是JTAG调试口如果你把它们当普通GPIO用必须在初始化里执行禁用JTAG的配置。一旦禁用ST-Link/J-Link通过JTAG就再也连不上只能靠重新上电并保持复位引脚拉低再尝试连接或者改用SWD。所以项目里我都保留SWD模式把JTAG完全关闭因为这个模式至少还能接两根线调试程序。5.3 FPGA逻辑设计的几个深坑FPGA逻辑上的坑很多跟开发者的经验积累有关。MIPI接收是出了名的难D-PHY的数据率动辄几百Mbps甚至Gbps级别普通的FPGA GPIO根本不能直接接收MIPI信号必须用专用差分IO Bank配合硬核PHY或外置物理层芯片。用普通IO直怼MIPI即使是做验证也大概率失败。如果你只是想读取摄像头图像更稳妥的方案是选自带MIPI接口的FPGA芯片或使用摄像头转并行接口的桥接芯片。FPGA与STM32之间的跨时钟域我前面已经说了要打拍和用FIFO这里再补充一个“异步FIFO深度不够”的坑。FSMC写入数据量大时FIFO深度不够很容易发生写满、读空导致数据错帧。解决办法是根据最大突发数据量、读写时钟频率比计算FIFO深度至少要等于“满载传输过程中写入的数据量减去读出的数据量”的最大值并留出两倍余量。我的经验值是系统时钟50MHz、接口时钟30MHz、一次突发传输16KB数据FIFO至少留32KB否则传输过程中水位告警会频繁触发。还有独热码状态机时忘记写default分支。这会导致复位时状态未知进入非法状态后永远跳不回来。虽然综合工具有时会自动处理但我从不让工具猜状态枚举里一定添加一种“非法状态”并默认跳回复位态。类似的case语句用独热码时信号同时多bit置位的可能性虽然理论上不该存在但外部干扰或亚稳态会让它发生所以必须做状态检测和自恢复。最后聊一个让我印象深刻的“玄学现象”FPGA里偶尔会出现一个信号看起来物理上该是低电平却总被读成高电平。原因可能是该信号跨时钟域后没同步也可能是IO口管脚根本没有物理连接。用逻辑分析仪直接抓FPGA芯片引脚波形是最快的确认方式。逻辑分析仪比仿真器更接近物理真实性尤其适合排查“理论上不可能但实际发生了”的问题。我个人在实际操作中的体会是STM32FPGA双核系统能不能做出价值不在于你用多贵的芯片而在于你愿不愿意在架构阶段多花几天把任务边界、接口时序、协议帧和缓存空间算清楚。每踩一个坑后面的项目就少踩一次。这套组合非常适合那些想从“单片机能搞定”跨到“高速并行处理也能搞定”的应用场景。如果你正被定时器捕获精度不够、图像刷屏卡顿、多路并行采集不稳定的问题折磨不妨从这个架构开始试。 
长河君 · 2026/10/8 22:36:26 · 阅读 1.2k STM32+FPGA双核系统架构与实战：从测频到上云
你可能也被“STM32FPGA双核技术系统”这个标题吸引过。刚开始接触这个概念时我也在想这到底是硬核炫技还是真有需求直到我拿到一个四路频率测量、一路MIPI图像采集、步进电机加减速控制、最后还要把数据上报云端的项目才彻底明白有些活单靠MCU能凑合单靠FPGA也能硬扛但一起做就会特别痛苦。STM32FPGA双核系统的本质不是两块芯片叠在一起而是把“会做事”和“能扛事”的两个角色凑成一个高效团队。这套方案适合谁参考适合那些已经在用STM32但发现定时器、GPIO翻转速度、外部总线带宽不够用的朋友也适合刚入门FPGA、想找一个真实项目把状态机、FIFO、UART、LVDS这些模块串起来的新手。今天这篇文章不打算写成论文只从我自己实际做过的项目出发把架构、接口、测频、显示、电机、上云这些环节的取舍和坑一次讲清楚。1. 为什么“STM32FPGA双核”不是叠buff1.1 两颗芯片的性格差异STM32是典型的顺序执行处理器主频一般几十到几百MHz跑指令、跑RTOS、跑TCP/IP协议栈是它的强项。它的外设非常丰富串口、CAN、ADC、DMA、以太网、USB基本上一颗芯片能搞定一个控制板的全部需求。但它的致命问题在于“时间确定性”同一个操作可能因为中断、总线仲裁、Cache命中与否消耗的时间完全不同。你很难用它去实现ns级别稳定的脉冲输出或高速并行数据采集。FPGA则是完全另一种性格。它没有“指令流”所有的逻辑都是并行化的硬件电路。你可以同时跑十个计数器、八个FIFO、两组LVDS差分线而且每个逻辑单元的处理时延是确定的。但它不适合写复杂协议代码。你要是在FPGA里硬写一个完整MQTT客户端或者跑文件系统那个工作量足以让人怀疑人生。所以STM32FPGA双核的第一层逻辑是让两个人干各自擅长的事。STM32负责“干什么”FPGA负责“怎么干得又快又稳”。这就像项目经理和车间流水线的关系你给项目经理说“今天出100件货”他能拆任务、协调资源、处理异常但真正一个时钟周期出一个结果的重复劳动必须交给流水线。1.2 任务怎么切控制面和数据面分离我一般把系统分成两个平面控制面和数据面。控制面包括命令解析、状态管理、通信协议、电机轨迹计算、用户交互这些全部放在STM32数据面包括数据采样、等精度测频、边沿捕捉、DDS波形生成、图像行场同步、串行差分接收这些放在FPGA。拿我做过的一套测频系统举例。STM32负责接收上位机命令比如“测1秒、通道A、显示到LCD”然后把参数打包通过FSMC接口写进FPGA寄存器FPGA收到配置后立刻启动硬件计数器等计数结束把结果放在一个双端口RAM里拉一个中断通知STM32来读。整个过程STM32只做了两次配置和一次读数据剩下的高频计数全部在FPGA内部跑测频精度直接取决于参考时钟而不是CPU中断抖动。这种切分还有个好处调试边界清晰。FPGA出问题时多半是时序或状态机问题STM32出问题时多半是协议或外设配置问题。把调试范围缩小排错效率会显著提升。1.3 哪些场景值得上双核不是所有项目都需要STM32FPGA。普通传感器采集、低速控制一颗STM32绰绰有余简单的逻辑替换一颗FPGA也能应付。真正值得用双核的场景有几个明显特征需要并行执行多个实时任务比如同时测频、同时采集图像、同时输出多路PWM需要高带宽数据传输比如高速ADC采样后的数据必须在几个时钟内搬走需要对外设接口做自定义扩展比如用普通IO模拟MIPI、LVDS或专用传感器时序需要系统在恶劣电磁环境下稳定运行FPGA的硬件逻辑比中断驱动的MCU更适合扛干扰。反之如果你只是点个灯、读个温湿度强行上双核就是给自己制造不必要的麻烦。双核系统的成本、功耗、PCB面积、开发难度都是成倍增长的项目立项前一定要做“加减法”加法留给确定性计算减法砍掉不必要的并行扩展。2. 双核系统架构与关键接口设计2.1 选型先算账引脚、资源、带宽很多朋友一开始就在纠结选哪颗FPGA、哪个STM32型号。我的建议是先算账后选型至少算三笔账引脚数、逻辑资源、通信带宽。先看引脚数。FPGA要接多少外部信号摄像头并行数据可能有8~16位ADC可能有12~16位多路频率测量要分配3~5个通道LCD如果是RGB接口还要二十多根线。把这些引脚全部列出来加上时钟、复位、调试脚就基本确定了FPGA的最小封装。千万别只看核心逻辑最后发现引脚不够就尴尬了。系统里那几个IO口我习惯留出20%的余量方便调试和后期扩展。再看逻辑资源。想做DDS波形发生器、等精度测频、UART、FIFO、状态机这类模块用不了太多资源入门级FPGA完全够如果要做图像缓存、MIPI接收、LVDS转并行数据资源占用就会迅速上升尤其是Block RAM。图像的一行数据就要几KB一帧缓存更是几百KB起步选型前务必估算存储资源。最后算通信带宽。假设STM32和FPGA之间要在1秒内传一帧320x240的灰度图像数据量约76KB。用SPI的话如果SPI跑20MHz理论带宽只有2.5MB/s扣除协议开销勉强够用用8位并口加读写控制跑30MHz带宽就有30MB/s余地充分。高速图像场景我基本不会用SPI直接上FSMC或自定义并行总线。接口方式典型带宽优点适用场景UART0.1~1MB/s简单、抗干扰好低速控制、调试信息SPI/QSPI2~50MB/s引脚少、速率可调小包数据、LCD控制8/16位并行10~100MB/s带宽大、时序直观图像、高速采样FSMC/FMC与STM32总线同步可映射成内存地址大数据量批量存取2.2 STM32与FPGA之间怎么连才不憋屈选好接口协议后硬件连接方式通常有三种直接GPIO直连、并行总线、差分信号。低速控制命令用GPIO直连就够一个写使能、加8位数据、加一个中断信号简单粗暴也好排查问题。STM32先拉低片选和写信号把数据放到数据线然后拉高写使能FPGA在上升沿采样。这个过程用示波器抓一下就知道有没有问题。如果数据量一大GPIO直连会非常痛苦这时候就要用FSMC/FMC。FSMC能把FPGA映射到STM32的地址空间STM32直接往变量地址写数据就像操作内部RAM一样。硬件连接上把FSMC的地址线、数据线、NBL、NOE、NWE连到FPGAFPGA内部写一个简单的总线从设备逻辑解析地址和读写信号。这个方案我用了很多年最直观的好处是STM32代码里不需要显式封装复杂的读写字函数一句*(volatile uint16_t*)0x60000000 value;就完成了传输。对于LVDS这种高速差分信号就不能用普通GPIO直连了。STM32几乎没有原生LVDS接口通常由FPGA接收LVDS转成并行数据后再通过FSMC桥给STM32。这里有个关键点FPGA的LVDS输入引脚必须做差分端接常见做法是在PCB上靠近FPGA放置100欧姆差分电阻如果IO Bank支持内部端接可以直接配置Internal Termination省掉外围电阻但不同系列的FPGA能力不同用前一定要查Datasheet。2.3 通信协议和缓存设计STM32和FPGA之间的通信协议建议用一个简单可靠的帧格式。我常用的是帧头2字节、命令字1字节、长度1字节、数据区N字节、CRC校验2字节。MCU发命令给FPGA时FPGA解析帧头、校验CRC然后执行FPGA回传数据时同样按这个格式组帧。这里有一点要提醒两条芯片之间的接口容易受干扰特别是电机驱动、继电器动作时偶发数据错误概率会高很多。如果没做CRC校验后期排查会非常痛苦。CRC简单点可以用CRC-16/CCITT在FPGA里是组合逻辑或者LFSR状态机资源开销很小。数据量大的时候协议之上必须加缓存机制。FPGA侧在收到数据后先放进一个FIFO或双端口RAMSTM32再通过DMA过来搬运不要每次一个字都靠中断。双缓冲是另一个实用技巧FPGA将“当前帧”写入Buffer A同时“下一帧”在Buffer B积累帧同步信号到来时再切换避免STM32读到一半数据被更新。这个机制在图像采集和高速ADC项目中尤其重要。有人会问STM32里跑FreeRTOS怎么和这些缓存结构对接我的做法是定义一个共享数据模型比如MeasurementData g_fpgaData; SemaphoreHandle_t g_dataReadySem;。FPGA通过中断通知STM32后中断服务函数里只GiveSemaphore真正读取数据的任务在等待到信号量后从FIFO或双口RAM里拷贝数据。这样中断处理时间极短既不阻塞系统又保证数据不会丢。2.4 时钟、复位与电源设计双核系统的时钟设计比单芯片系统更容易出问题。STM32和FPGA通常各自用晶振但两者之间传递数据时必须考虑跨时钟域。FPGA内部模块经常用到多时钟域比如系统主时钟50MHz、采样时钟120MHz、串口时钟波特率分频跨时钟域的信号处理不好就会出现偶发错码、状态机跳飞。几个常用的处理办法单个bit信号用两级或三级同步寄存器打拍多位数据用异步FIFO或握手协议对严格要求对齐的场景可以把STM32侧接口时钟直接引给FPGA做输入让FPGA采样逻辑使用统一的接口时钟。我自己就吃过跨时钟域的亏一个标志信号没同步就直接用结果大约每十分钟出现一次状态机误触发查了一整天才定位到。从那以后凡是跨时钟域的握手信号一律先打三拍。复位设计也容易被忽略。FPGA上电后不建议直接进入主逻辑最好用一个“上电复位按键复位”的组合复位信号要经过施密特触发器或RC滤波消除毛刺。STM32侧如果是用外部复位复位时间要足够长至少满足FPGA配置完成再加几个毫秒否则FPGA还没加载完毕STM32就开始初始化外设两者通信会失败。电源方面可以考虑先给FPGA供电保证其完成配置后再让STM32运行。简单做法是两个芯片各用独立LDO或DC-DC通过使能脚控制时序。STM32和FPGA的IO电平也要匹配STM32常用3.3VFPGA也支持3.3V但LVDS bank通常需要单独的差分参考电压不容搞混。3. 核心模块实战测频、显示、电机、上云3.1 频率测量为什么FPGA做得更“稳”我最常被问到的FPGA项目就是频率测量。STM32本身有定时器的输入捕获模式测低频信号很简单比如测量1kHz PWM用输入捕获配合DWT延时误差几个Hz完全没问题。但一旦信号频率升到几十MHz或者要求同时测多路频率STM32定时器就显得力不从心。这时FPGA用等精度测量法是更好的选择。等精度测频的思路很简单设一个基准闸门时间T比如1秒在闸门开启期间同时统计被测信号的上升沿个数Nx和基准时钟的上升沿个数Ns。如果基准时钟频率为Fs那么被测频率Fx Nx / Ns * Fs。因为闸门开启与待测信号同步所以被测信号计数没有量化误差误差只取决于基准时钟。用FPGA实现时状态机生成一个“闸门开/关”信号两个计数器分别累加闸门关闭后锁存计数值等待STM32读取。// 简单的等精度测频计数器内核伪代码风格 reg gate_q, gate_sync; reg [31:0] counter_ref, counter_sig; wire gate_rise gate_q !gate_prev; reg [31:0] ref_latched, sig_latched; always (posedge clk_ref) begin if (counter_ref TARGET_COUNT) begin counter_ref 0; gate_internal 1b0; end else if (start_cmd) begin counter_ref 0; gate_internal 1b1; end else if (gate_internal) begin counter_ref counter_ref 1; end // 同步待测信号边沿再用它做闸门同步 // 实际要注意跨时钟域处理 end这个模块做完后STM32侧的工作就很简单了写寄存器启动测量轮询中断标志读完两个计数值再套公式计算。我实测下来以50MHz参考时钟、1秒闸门频率分辨率能做到几Hz以内而且STM32任务切换和中断嵌套完全不影响测量结果。这就是双核系统最真实的收益。3.2 LCD显示一次把ILI9341和中文编码问题说透很多热词里都提到STM32LCD尤其是ILI9341读ID问题是A1A1。这块芯片在国产开发板上太常见了驱动方式有SPI、8位并口、16位并口。我通常用SPI刷显示因为接线简单但SPI刷全屏比较慢适合显示文字和简单图形如果要做流畅的UI动态刷新建议还是用并口或FSMC。ILI9341读ID踩坑很多。正常情况下用命令0xD3可以读到三个字节正确结果类似0x00 0x93 0x41如果你从软件SPI调试串口读出来是0xA1A1多半不是型号不对而是MISO配置有问题。软件SPI读数据时主机必须在发完命令字节后立刻将MISO引脚切换为输入模式并留出足够的时间让从机驱动数据线如果MISO一直保持推挽输出模式或者读数据时选的采样沿不对ID读回来就是乱码。硬件上MISO线最好加上拉电阻对读ID这类慢速操作更可靠。GBK转UTF8也是中文显示的经典问题。STM32内部如果只存UTF8字符串ILI9341驱动里的中文字库通常以GB2312/GBK编码索引两者不一致就会显示乱码。有两个解决办法一是上位机在生成字库时先把编码统一成GBK代码里不转码二是在STM32内做一张转换表把UTF8字符串转成GBK再查字库。第二种方法灵活但占Flash我一般只保留常用汉字转一次就存缓存数组。FPGA还能配合LCD做更复杂的事比如用FPGA产生RGB LCD的时序、把STM32写入的显存数据扫描到屏幕上这能让STM32彻底摆脱刷屏消耗。不过这个方案要占用FPGA逻辑和RAM属于双核系统里比较进阶的做法。如果你只想把LCD当一个监控面板STM32SPI完全够用。3.3 步进和伺服STM32算轨迹FPGA发脉冲电机控制是“双核分工”最典型的例子。五线四相步进电机可以直接由STM32定时器产生PWM脉冲但在多轴联动、高频脉冲输出、加减速要求严格的场合STM32定时器处理会显得很吃力。我用过的方案是STM32负责插补计算把每一步的脉冲间隔、方向、步数写进FPGA的寄存器FPGA内部维护一个脉冲发生器定时发送脉冲给驱动器再实时产生方向信号。FPGA里做脉冲发生器其实很简单一个计数器一个比较寄存器。计数器累加到比较值就翻转一次脉冲输出同时更新下一个步长的比较值。这个比较值就是STM32算出来的当前速度对应的定时周期速度越快周期越短。加减速曲线可以预先算好放在STM32的RAM里运行时逐条写入FPGA。这样即使STM32被中断拖住十几微秒脉冲输出依然不会有抖动驱动器就不会因为丢脉冲而失步。伺服电机通过485控制时也类似。STM32负责Modbus或自定义485协议栈FPGA负责监控编码器反馈信号。因为FPGA能在几个时钟周期内捕捉编码器AB相脉冲位置计数非常准。你可以在FPGA里做一个硬件位置计时器STM32通过FSMC接口周期性读取当前位置这样系统响应速度就比单纯靠STM32外部中断计数快得多。有人会质疑FPGA做485会浪费其实如果只需要发送ASCII字符串比如状态查询命令FPGA串口模块也能轻松实现但完整的PID闭环、伺服参数读写、模式切换这些逻辑还是STM32更适合。3.4 物联网网关FreeRTOSLwIP巴法云在双核系统里STM32还有另一个大任务联网。FreeRTOS配LwIP是目前很成熟的方案再接一个MQTT库就能接入巴法云这类物联网平台。FPGA采集数据不等于系统上云真正要把数据上报还需要协议栈、时间戳、异常重传、设备管理等软件层面的东西。我习惯把整个上报流程拆成几个任务采集任务从FPGA读取数据转换成人读得懂的单位协议任务负责MQTT主题整理、QoS等级设置、心跳包维护云平台上报任务定时把最新数据发布到主题。FreeRTOS的任务优先级要排好一般把数据采集任务设为最高优先级因为它直接影响实时性MQTT网络任务可以放低一些LwIP调用不能阻塞其他任务必要时用消息队列传递数据。巴法云这类平台接入时一个常见坑是MQTT连接不稳定。测试阶段直接用IP连没问题换成域名后就会因为DNS解析失败而掉线。解决办法是不要把域名解析放在任务启动流程的关键路径上可以先解析一次缓存业务线程与网络线程分离。在FPGA侧采集的数据最好先用环形缓冲保留最近几十个采样点等MQTT恢复后集中补报这样数据不会完全丢失。STM32里保存配置数据也需要处理端序和编码。很多时候ASCII和UTF8混着来比如设备序列号用ASCII设备名称用UTF8云平台上显示才会正常。如果全部硬编码后面改配置非常麻烦。我在这个时候才体会到双核系统并不是只管FPGA的并行逻辑STM32侧的任务架构如果没设计好照样会拖后腿。3.5 顺便讲个低成本的FPGA信号发生器信号发生器也是FPGA入门常见的项目几乎是DDS的教科书级应用。DDS原理不复杂用一个相位累加器每个时钟周期加一次频率控制字高位数作为ROM查找表的地址ROM里存正弦波一个周期的幅值数据输出就是正弦波。给定时钟频率Fclk、相位累加器位数N输出频率fout fctrl * Fclk / 2^N。我在系统里把DDS频率控制字交给STM32计算FPGA只需要实现累加器和ROM查找。STM32收到用户按键或上位机命令算出fctrl后通过接口写入FPGAFPGA就能稳定输出对应频率。实测下来50MHz系统时钟、32位累加器几Hz以上频率都能稳定输出到外部运放。如果想让输出波形更平滑可以在FPGA内再加一级Sinc插值滤波器但波形质量要求不高时这步可以省掉。用FPGA做信号发生器有个好处多路输出、扫频、方波、三角波都能同时生成而且互不干扰。STM32做参数输入和显示FPGA做波形生成正好把双核系统中的“机器语言”和“人机接口”分得明明白白。你要是想在FPGA里用UART发送ASCII字符串给电脑端显示频率值也不是难事一个简单的波特率发生器加状态机就能完成但调试时还是建议优先用串口从STM32打印省得两头查。4. 联调、工具链与固件协作4.1 STM32工程搭建从CubeMX到VSCodeJ-Link最近几年STM32开发环境变化不小除了Keil越来越多团队开始用VSCodeCMakeJ-Link。我第一次把工程从Keil迁移到VSCode时最大的感受是代码检索和Git对比确实舒服但环境配置比Keil麻烦很多。核心步骤如下先用STM32CubeMX生成外设初始化代码图形化配置FSMC、UART、ADC、GPIO再用STM32CubeCLT或GCC工具链编译最后通过VSCode的Cortex-Debug插件连接SEGGER J-Link配置好device、interface、swd这些参数。芯片包安装也是一道关卡。CubeMX下载芯片支持包时经常很慢或失败我习惯直接从ST官网手动下载对应封装的包然后导入CubeMX信息库。VSCode下调试时J-Link固件版本和驱动要匹配有些老J-Link在新驱动下会报“The connected probe appears to be a clone”之类的错误那大概率是固件太旧需要用J-Link Commander升级。有人喜欢直接在工程里写裸机代码但我建议跑FreeRTOS。双核系统里STM32往往要处理通信、显示、云平台等多个任务裸机主循环加中断的处理模式很容易变得混乱。FreeRTOS的队列、信号量、任务通知都特别适合承接FPGA中断触发的事件流。4.2 FPGA开发流程和几个提升效率的习惯FPGA开发流程比STM32更依赖工具链。无论是Quartus还是Vivado从头到尾都要经过设计输入、仿真、综合、布局布线、时序分析、比特流生成、下载调试。新手最容易犯的错是不做仿真直接上板。一个简单的状态机加上跨时钟域信号仿真不跑上板查错可能要花十倍时间。ModelSim或者Vivado自带的Simulator都能用别嫌仿真麻烦。我在FPGA内部写模块时会严格划分时钟域每个模块顶层只接收来自同一个时钟域的输入。跨时钟域的FIFO用现成的IP核生成不要自己手写。组合逻辑块的时序也挺关键时序不满足时先看关键路径是“寄存器到寄存器”长还是“引脚到寄存器”长。后者多半是引脚约束或IO标准配置问题比如LVDS输入没有设置差分端接。还值得提一下状态机编码。FPGA里状态机可以用独热码或二进制码。独热码每个状态只有一个bit为1译码逻辑简单组合逻辑延时小速度能跑得更高但触发器用得多二进制码最省寄存器适合状态多、逻辑不复杂的场景。我一般优先用独热码因为FPGA逻辑单元里触发器资源比较充裕而时序收敛更重要。case语句里必须给默认分支防止状态机进入非法状态。4.3 双核联调的Debug三板斧STM32和FPGA联调最怕两边都觉得自己没错。我把这几年积累的调试技巧归纳成三板斧第一板斧是分模块回环测试第二板斧是抓波形第三板斧是设计观测点。分模块回环测试就是把通信先断开各自验证自身功能。FPGA单独用SignalTap或ILA抓内部信号STM32单独用串口打印寄存器数据。两边都确认没问题后再把FSMC或SPI物理总线接上。联调时优先检验的是CS信号、WR/RD信号、Busy/ACK反馈而不是上来就看最终数据对不对。时序上有一点偏差数据可能整体错位。抓波形要用逻辑分析仪别只依赖示波器。STM32的FSMC写周期通常只有几十纳秒示波器单触发抓一次绝对没问题但想要看波形序列和时序关系逻辑分析仪更好用。可以把CS、WR、地址线、数据线上的触发条件设为“CS下降沿且WR上升沿出现时”一次就能抓到完整写周期。观测点是指代码里的调试追踪点。STM32侧每个关键函数入口出口打串口日志带上时间戳FPGA侧把状态机当前状态、FIFO水位、握手信号引到空闲引脚用逻辑分析仪实时观察。两边的时间戳对应不上时优先怀疑通信协议和位宽配置而不是功能逻辑。这套方法几乎能解决我遇到过的所有“偶发”问题。5. 我踩过的坑随便挑几个说5.1 板上信号完整性相关坑双核系统有高速信号、低速信号、电机电源混合信号完整性问题特别多。最典型的坑是FPGA的LVDS接收线和普通GPIO挨得太近差分线没有做阻抗控制导致高频率时接收误码。解决方法是PCB布线时LVDS差分对走线要等长、靠近、包地远离时钟线和开关电源。另一个坑是FPGA IO口配置成Hysteresis Input Mode。这个模式其实很有用施密特触发器输入可以增大最小输入电压和最大输入电压之间的门限宽度对边沿缓慢的信号非常友好。按键、编码器、外部低频方波信号如果不用这个模式按键抖动、编码器毛刺都可能被当成有效边沿。但开滞回之后输入切换点的迟滞会让信号边沿在时间上有一点偏移测频率或测相位时需要考虑必要时还是转化为差分或被同步后的信号。电源噪声也很常见。FPGA核心电压和IO电压分开供电很多板子为了省钱共用LDO结果FPGA内部翻转电流一大STM32和FPGA之间的通信就开始出错。后来我把FPGA内核电源单独用DC-DC或低噪声LDO供电再用磁珠隔离数字地和模拟地通信才恢复稳定。双核系统的地平面设计要从一开始就考虑不能靠飞线解决。5.2 STM32外设的经典问题STM32外设坑数起来一大串这里挑几个高频的。ADC切换通道后第一两次采样值经常异常这个我在驱动多通道ADC时经常遇到。解决方法是每次切换通道后写入足够长的采样时间或者连续采样两次丢弃第一次结果。ADC的参考电压也尽量用外部基准内部VREF受温度影响比较大会影响测量精度。CAN通信突然连不上也是网上问得最多的问题。表面上看总线没问题代码没变但就是进不了中断。排查时先看总线电平CANH和CANL间有2.5V左右的差分电压再看是否每侧都加了120欧终端电阻。如果总线没问题查看波特率是否因为系统主频变化产生了误差CAN波特率容差要求很高主频即使差一点也可能导致同步失败。项目里我都是先从DBG接口重新烧写程序在连接稳定时修改配置不要等出问题再想怎么恢复。STM32把JTAG引脚复用成普通IO也是一个隐蔽的坑。PA15、PB3、PB4默认是JTAG调试口如果你把它们当普通GPIO用必须在初始化里执行禁用JTAG的配置。一旦禁用ST-Link/J-Link通过JTAG就再也连不上只能靠重新上电并保持复位引脚拉低再尝试连接或者改用SWD。所以项目里我都保留SWD模式把JTAG完全关闭因为这个模式至少还能接两根线调试程序。5.3 FPGA逻辑设计的几个深坑FPGA逻辑上的坑很多跟开发者的经验积累有关。MIPI接收是出了名的难D-PHY的数据率动辄几百Mbps甚至Gbps级别普通的FPGA GPIO根本不能直接接收MIPI信号必须用专用差分IO Bank配合硬核PHY或外置物理层芯片。用普通IO直怼MIPI即使是做验证也大概率失败。如果你只是想读取摄像头图像更稳妥的方案是选自带MIPI接口的FPGA芯片或使用摄像头转并行接口的桥接芯片。FPGA与STM32之间的跨时钟域我前面已经说了要打拍和用FIFO这里再补充一个“异步FIFO深度不够”的坑。FSMC写入数据量大时FIFO深度不够很容易发生写满、读空导致数据错帧。解决办法是根据最大突发数据量、读写时钟频率比计算FIFO深度至少要等于“满载传输过程中写入的数据量减去读出的数据量”的最大值并留出两倍余量。我的经验值是系统时钟50MHz、接口时钟30MHz、一次突发传输16KB数据FIFO至少留32KB否则传输过程中水位告警会频繁触发。还有独热码状态机时忘记写default分支。这会导致复位时状态未知进入非法状态后永远跳不回来。虽然综合工具有时会自动处理但我从不让工具猜状态枚举里一定添加一种“非法状态”并默认跳回复位态。类似的case语句用独热码时信号同时多bit置位的可能性虽然理论上不该存在但外部干扰或亚稳态会让它发生所以必须做状态检测和自恢复。最后聊一个让我印象深刻的“玄学现象”FPGA里偶尔会出现一个信号看起来物理上该是低电平却总被读成高电平。原因可能是该信号跨时钟域后没同步也可能是IO口管脚根本没有物理连接。用逻辑分析仪直接抓FPGA芯片引脚波形是最快的确认方式。逻辑分析仪比仿真器更接近物理真实性尤其适合排查“理论上不可能但实际发生了”的问题。我个人在实际操作中的体会是STM32FPGA双核系统能不能做出价值不在于你用多贵的芯片而在于你愿不愿意在架构阶段多花几天把任务边界、接口时序、协议帧和缓存空间算清楚。每踩一个坑后面的项目就少踩一次。这套组合非常适合那些想从“单片机能搞定”跨到“高速并行处理也能搞定”的应用场景。如果你正被定时器捕获精度不够、图像刷屏卡顿、多路并行采集不稳定的问题折磨不妨从这个架构开始试。