做嵌入式开发这些年Xilinx ZYNQ基本算是ARMFPGA异构平台的教科书级方案。但最近两三年我身边越来越多的项目开始要求国产化替代客户开口就问“能不能换成国产芯片软件尽量少改”。我今年刚完成一个从ZYNQ-7020/7045迁移到复旦微FMQL45T900的项目从硬件改版、FPGA工程移植、Linux系统搭建到QT界面全部重跑了一遍。这篇笔记就把整个迁移过程里能落地的思路和方法写出来尤其是那些文档上不会写、实际调试才踩得到的东西。不管你是做工业控制、图像采集还是边缘计算网关只要打算从ZYNQ往复旦微FMQL系列迁这篇应该能帮你少走大半个月弯路。1. 项目开局为什么从ZYNQ转向FMQL45T9001.1 需求驱动与选型考量先说结论这次迁移不是技术驱动而是供应链和合规驱动。原方案用的是ZYNQ-7020CPU跑LinuxFPGA做接口扩展和图像预处理整套方案已经稳定量产两年。但客户提出新的准入要求核心器件的国产化率必须达标Xilinx的芯片不能再出现在关键路径上。所以我们必须找一个能在功能上平替、在软件生态上尽量接近、团队上手成本又不太高的平台。我当时列了三个候选复旦微FMQL系列、紫光同创的FPGA外部ARM、以及某家国产FPGA自己攒ARM核的方案。后两个要么缺少ARM核要么需要外挂A7/A9硬件复杂度和BOM成本都会上升。FMQL系列是真正的ARM硬核FPGA单芯片融合方案和ZYNQ的架构思路一样软件迁移的工作量主要集中在BSP、驱动、启动链路和工具链切换PL端逻辑相对好处理。最终从团队研发效率和风险控制角度考虑选了FMQL45T900。选型时还有一个容易被忽略的点FMQL45T900的PS端不是A9而是ARM Cortex-A7双核。虽然寄存器模型和GIC中断控制器都类似但指令集是ARMv7-A而ZYNQ-7000是ARMv7-A的Cortex-A9编译参数、NEON指令支持、Cache行为都有细节差异。如果没有提前评估这块后面做性能调优时会很被动。1.2 FMQL45T900平台速览与项目资源盘点FMQL45T900是复旦微的ARMFPGA异构融合芯片封装是BGA900PS端有一颗双核ARM Cortex-A7处理器主频我这边跑在800MHz左右PL端官方标称是40多万逻辑单元还带DSP Slice和Block RAM整体定位和ZYNQ-7045比较接近。接口上PS自带DDR3/DDR3L控制器、千兆以太网、USB、SDIO、UART、CAN、SPI、I2C这些常用外设和ZYNQ的外设列表高度重合。拿到样片后我第一时间做了一张资源盘点表把原ZYNQ工程里用到的所有PS外设、PL模块、软件栈全部列出来逐项对比。原项目PS端用了UART1调试、SDIO挂eMMC、千兆MAC走RGMII、USB Host接摄像头PL端用了VDMA做图像采集、AXI GPIO做控制、自定义RTL模块做像素格式转换。软件栈是Linux 4.x QT5.5.10 交叉编译应用。盘点完发现FMQL45T900在资源数量上完全够用真正要花精力的是把每个外设重新映射到FMQL的引脚和地址空间。1.3 迁移前必须要做好的几项准备迁移不是拿到芯片就开干前期准备做得越细后面调试越顺。我这里的做法是先建立迁移评估表按“功能模块、原方案实现、FMQL对应方案、改动工作量、风险等级”五列把整机所有功能全部过一遍。比如原ZYNQ里PL侧的MIG DDR控制器迁移到FMQL就必须用复旦微的DDR IP重新生成因为控制器寄存器接口不一样但纯逻辑的RTL模块只要不是依赖Xilinx原语太多基本可以直接拿过来。准备工作里最重要的一项是把原工程的地址映射关系梳理清楚。ZYNQ下PS外设、PL AXI地址、FPGA内部BRAM地址都是我们自己定义的实际上这些是软件和FPGA之间的“协议”。迁移到FMQL后地址空间虽然大体结构类似但外设基地址可能会有差异尤其是PL侧AXI从地址和中断号必须在FPGA工程阶段就定好否则Linux设备树写出来就是一堆错误。另外建议在迁移前把开发环境搭好并验证一遍。FMQL的开发流程和ZYNQ很像但工具链不是VivadoSDK而是复旦微自己提供的PL开发环境和PS端交叉编译工具链。先花两三天时间在空板上把最简单的点灯工程跑通确认工具链、下载器、启动模式都没问题再开始做真正的迁移这样能避免把“工具链不熟”和“代码有问题”混在一起排查。2. 硬件平台差异对比不是简单换个引脚封装2.1 PS端外设差异与引脚映射调整很多人拿到FMQL45T900的第一个感觉是“这不就是ZYNQ吗”但越往下做越会发现两者只是长得像细节差异非常多。最直接的就是PS端MIO映射方式。ZYNQ把UART、SDIO、GMAC、USB、CAN这些外设的引脚配置在MIO上FMQL也有类似的MIO管脚但同一外设的可选引脚位置不一样。比如原ZYNQ工程里UART1用的是MIO[48:49]到FMQL上这两个引脚可能就不能配置成UART1得重新查官方管脚手册选一组可用引脚然后改硬件原理图、改板级约束、改设备树三处同步改。EMIO也是一样。原ZYNQ方案里有些低速信号通过EMIO连到了PL侧比如从FPGA扩展出几路GPIO控制继电器。FMQL的PS和PL之间也有类似的EMIO通道但信号编号和中断映射不完全一致。这种“看起来一样、实际不对”的地方最坑人硬件上不能直接照搬必须逐脚核对。我在这个环节踩过一次坑原ZYNQ把PS端的I2C0挂在了MIO[50:51]上板子已经LAYOUT完成。迁移到FMQL后发现FMQL的I2C0在MIO[50:51]上不可用最终只能把I2C0改到EMIO从PL引脚飞线虽然功能一样但多占了两个PL引脚还额外改了一遍底层驱动。所以一定要尽早拿到FMQL的管脚复用表先把引脚分配冻结再开始布局布线。2.2 启动模式配置与烧录链路差异ZYNQ的启动模式是通过MIO[6:2]五个引脚的电平组合来选择的支持JTAG、QSPI、SD、NAND等方式上电时处理器按这几个引脚的拨码状态决定从哪里加载第一级启动镜像。FMQL45T900的启动模式和ZYNQ思路一致但具体引脚的编号和模式编码不同不能想当然地照搬原ZYNQ的拨码电路。我用的方法是先看官方评估板的启动配置电路再对着数据手册确认自己板子的拨码状态。更关键的是烧录链路。ZYNQ把FSBL、bitstream、U-Boot打包成BOOT.BIN可以烧到SD卡或者QSPI Flash里。FMQL也是类似的打包方式但打包工具和命令参数是复旦微自己的。这个环节建议用官方IDE的图形化界面生成BOOT.BIN除非你对它的内部字段已经很熟否则不要试图手工拼接。因为BOOT.BIN里有启动头、校验信息、镜像偏移等多个字段拼错一个字节上电就静默失败。另外要注意QSPI Flash的型号兼容性。原ZYNQ板子用的是某款国产Flash在Xilinx下有驱动支持但FMQL的QSPI控制器支持的Flash ID列表可能不一样。第一次烧录前先在开发板上验证一遍Flash型号或者直接用复旦微评估板上的同款Flash否则会出现“烧录显示成功、重启找不到镜像”的问题。2.3 电源、时钟与复位设计的重新核对ARMFPGA异构芯片最怕的就是电源时序。ZYNQ要求PS和PL的电源有明确的上电顺序比如先VCCPINT再VCCO_AUX再PL核电压违反时序轻则启动不稳定重则直接烧片。FMQL45T900同样有严格的电源上电时序要求而且具体顺序和ZYNQ不完全一样。这块一定不要沿用原ZYNQ板子的PMIC配置必须找复旦微数据手册里的电源时序图逐项核对。时钟方面ZYNQ的PS_CLK通常是33.333MHzFMQL45T900的PS参考时钟我查手册发现要求不同板子上的晶振频率也需要相应调整。如果继续用33.333MHz的晶体PS端PLL可能锁不住Linux串口控制台会出现乱码或者U-Boot阶段就卡死。PL端的参考时钟也要注意原ZYNQ的PL侧可能用了100MHz差分晶振FMQL的PL时钟输入引脚定义可能不同需要在FPGA工程的约束文件里重新指定管脚。复位电路同样需要改。ZYNQ的PS复位输入是低有效FMQL也是低有效但是复位延迟时间和上下电复位阈值可能不同。我在样机上碰到过一个问题按一下复位键系统概率性起不来后来发现是复位芯片的延迟时间太短复位释放时DDR还没有完成初始化把RC复位延时从100ms调到200ms后问题消失。这种问题在原理图评审阶段很难看出来但测试时非常头疼所以提前把电源监控芯片和复位芯片的选型参数定好能省很多事。3. 软件迁移全流程实操从SDK到交叉编译的每一步3.1 工具链切换与ARM交叉编译环境搭建软件迁移的第一关是工具链。原ZYNQ在Xilinx SDK里可以直接生成ARM编译器并调试FMQL的方案则要在Ubuntu环境下搭建交叉编译工具链再把应用源码从SDK工程里搬出来编译。我们用的目标平台是Cortex-A7指令集是ARMv7-A所以选择了arm-linux-gnueabihf工具链编译参数加上-marcharmv7-a -mfpuneon -mfloat-abihard这样能充分使用NEON SIMD指令图像处理类应用会有明显提升。安装和验证工具链的步骤比较简单在Ubuntu 18.04/20.04下执行sudo apt-get install -y gcc-arm-linux-gnueabihf export CROSS_COMPILEarm-linux-gnueabihf- export ARCHarm $CROSS_COMPILE-gcc --version确认版本能看到arm-linux-gnueabihf-gcc的输出后建议先编译一个最简单的Hello World用file命令查看生成文件格式确认是ARM架构的ELF。交叉编译环境本身不难搭真正麻烦的是把原来依赖Xilinx SDK里的C库头文件、第三方库全部迁移过来。比如项目里用到的libpng、libjpeg、sqlite都要用交叉编译工具链逐个重新编译成ARM版本并安装到sysroot目录下否则后面编译应用会报找不到头文件。3.2 FPGA工程移植从Vivado IP到FMQL PL工程FPGA工程迁移是整个项目里最耗体力的环节。如果你原来的PL代码全部是手写RTL不依赖Xilinx的IP核那迁移工作量不大只要把顶层文件的引脚约束改成FMQL的管脚重新综合实现就行。但绝大多数ZYNQ工程都会用到MIG、AXI DMA、AXI GPIO、VDMA这些IP核这些IP的寄存器接口和时序跟复旦微的IP不是一回事不能直接拷贝网表。我的处理思路是“预留适配层”。把顶层模块根据数据流拆成三块外部接口、内部处理、PS交互。外部接口比如LVDS、MIPI、千兆PHY这些是纯引脚逻辑基本可以原样保留内部处理比如像素格式转换、滤波算法、帧缓存控制如果是自己写的RTL直接拷贝PS交互部分则重新用FMQL的AXI IP生成一套AXI-Lite/AXI-Full接口保持寄存器地址和中断号与原方案一致。这样改动最小软件侧的驱动只需要微调不用重新设计数据通路。如果你原工程里用了Xilinx特有的原语比如IDELAYCTRL、BUFGCE、MMCM迁移时要在FMQL的FPGA工具里找对应的时钟原语替换。特别要注意MMCM/PLL的参数虽然都是Altera? 不是ZYNQ是XilinxFMQL是国产FPGA但两者PLL的寄存器配置完全不同不能直接用IP参数必须根据FMQL的时钟IP重新配置倍数和分频数。clk_wiz这类时钟IP建议全部重建。3.3 Linux系统移植与U-Boot启动链构建Linux系统迁移是本次项目的核心难点也是坑最多的地方。FMQL45T900的PS端可以运行Linux官方的BSP包里一般会提供U-Boot、Linux内核和设备树的基础版本但版本通常比较老需要自己根据硬件板卡修改。我整理的完整启动链分为四步第一步用FMQL的PL开发工具完成FPGA综合实现生成bit流文件第二步在PS端工具里创建FSBL工程编译生成fsbl.elf。FSBL的作用类似ZYNQ里的第一级启动引导负责初始化DDR、时钟、外设加载bit流和U-Boot第三步编译U-Boot。U-Boot源码里需要修改板级配置至少包括DDR容量、以太网PHY地址、串口波特率、启动环境变量。我建议先不加DTS进U-Boot直接用默认配置跑通启动再优化第四步制作BOOT.BIN。把fsbl.elf、工程生成的bit文件和u-boot.elf按顺序打包放到SD卡BOOT分区或者烧进QSPI。FMQL的打包工具和Xilinx的bootgen界面类似但也有自己的格式要求必须用官方工具生成。U-Boot环境变量里要指定内核加载地址、设备树加载地址和根文件系统挂载方式。以我的板卡为例内核镜像放在SD卡FAT分区U-Boot启动后执行fatload mmc 0:1 0x12000000 zImage fatload mmc 0:1 0x13000000 fmql.dtb setenv bootargs consolettyS0,115200 root/dev/mmcblk0p2 rw rootwait bootz 0x12000000 - 0x13000000这里加载地址不能照抄ZYNQ的习惯要先确认FMQL的DDR映射基地址以及U-Boot默认的编译链接地址加载地址必须在DDR有效范围内并且不能跟U-Boot本身占用的内存重叠。3.4 Linux内核与设备树修改要点FMQL官方的Linux内核版本和Xilinx内核可能有差异但设备树模型是完全一致的所以修改设备树的时候可以沿用原来的思路。把原ZYNQ设备树里的compatible、reg、interrupts属性拿出来对照FMQL的寄存器手册和官方的设备树模板逐项改。最常改的是这几个节点串口节点要改成FMQL实际使用的UART实例和对应MIO引脚以太网节点要确认MAC控制器基地址、中断号和PHY的MDIO地址是不是一致特别是RGMII引脚约束FMQL的引脚mux和驱动强度配置可能不同SD卡节点要关注SDIO控制器的时钟和卡检测引脚。还有中断号FMQL的GIC中断号分配和ZYNQ有差异直接把原设备树的中断号改过来大概率会出错最好先启动系统通过/proc/interrupts逐一确认外设中断是否生效。设备树里的时钟频率尤其重要。ZYNQ的PS时钟树是在FSBL里初始化的Linux内核依靠device tree里的clock节点获取时钟信息。FMQL的时钟框架源码和ZYNQ不同必须使用官方BSP提供的clock驱动并在dts里删掉或替换掉Xilinx的clock相关节点否则Linux内核启动时会因为时钟模块不匹配而卡死或者外设异常。3.5 QT5.5.10与ARM应用层迁移实战应用层我们用的是QT5.5.10属于比较老的版本在ARM Linux上的移植还算成熟。首先用交叉工具链编译QT库configure时要指定操作平台为linux-arm-gnueabi-g并且关闭一些用不到的模块比如QtWebEngine、QtMultimedia能明显缩短编译时间并减小运行库体积。我当时是在Ubuntu主机上用sysroot方式编译的将目标板根文件系统里的lib和usr/include作为交叉编译的库搜索路径这样编译出来的应用和运行时环境一致降低运行时缺少依赖的风险。QT运行在嵌入式Linux里有两种方式一种是linuxfb直接写framebuffer简单稳定适合单界面应用另一种是eglfs利用GPU或者底层EGL加速画面更流畅。FMQL的PS端不带GPU所以eglfs这种方案在公共的A7平台上用处不大建议用linuxfb就够了。用linuxfb跑QT时有几个环境变量必须设置正确export QT_QPA_PLATFORMlinuxfb export QT_QPA_FONTDIR/usr/share/fonts export TSLIB_TSDEVICE/dev/input/event1如果界面出现花屏或者字体显示异常先确认framebuffer的分辨率和色深是否和屏幕匹配再检查字体文件是否放在了正确目录。我遇到过一次QT界面整体偏移的问题定位发现是FB设备的尺寸参数和实际屏幕不一致后来在启动参数里强制指定了宽高才解决。3.6 PL与PS协同AXI和中断迁移的坑ARMFPGA方案里PS和PL的数据通路一般通过AXI接口互联。ZYNQ下的AXI地址映射、DMA描述符格式、中断控制器配置和FMQL在总体思路上一致但寄存器偏移和一些控制位可能有区别。原来直接操作AXI寄存器的裸机驱动必须重新适配。我们在迁移时遇到最典型的例子是VDMA图像采集。原ZYNQ方案用Xilinx VDMA IP把摄像头数据写入DDR中断通知ARM去处理图像。迁移到FMQL之后虽然FMQL也有类似的VDMA IP但中断状态寄存器位不一样Linux驱动里中断处理函数读取的状态位全部对不上导致每帧图像都丢失中断或者重复触发。排查方法很简单先把驱动改成轮询模式确认DDR里是否有图像数据在更新如果有就说明数据通路OK问题只出在中断状态处理上再对照寄存器手册修正中断位。设备树里中断号的定义也容易出错。ZYNQ的PL中断通常使用SPI中断号比如61-68FMQL的GIC中断号分配不一样我在dts里把原来的61改成了FMQL对应的中断号结果系统启动时驱动申请中断直接失败后来用官方BSP的SDK生成设备树作为基准再把自己的外围节点加进去才算稳定下来。4. 常见问题与排查技巧实录4.1 启动卡死在U-Boot或DDR初始化阶段我拿到的第一批样片最开始上电发现串口没有输出量了各路电源都正常用JTAG连接FSBL调试发现卡在DDR初始化。排查后确认是DDR控制器的型号配置和时序参数不对。FMQL45T900的DDR控制器需要根据板上的DDR3颗粒型号设置容量、位宽、Bank数、时序参数不能沿用ZYNQ的DDR参数。复旦微的工具里通常会提供一个DDR初始化配置界面需要根据DDR颗粒手册填入CL、tRCD、tRP等参数。一个建议先在官方评估板上用同款DDR颗粒跑通一遍拿到一套能用的参数再套到自己的板卡上。如果自制板DDR走线做了等长、但拓扑和评估板不一致可能还需要微调读写延迟。4.2 QSPI烧写后无法启动只能用SD卡救砖QSPI烧写遇到的坑也很典型。第一次我们把BOOT.BIN直接烧到QSPI Flash偏移0地址重启后系统毫无反应。后来发现FMQL从QSPI启动时读取地址偏移不是从0开始就是需要特定头部寻址而且QSPI控制器对Flash是否支持SFDP探测有要求。我的处理办法是先在SD卡启动的模式下把U-Boot跑起来然后用U-Boot的sf命令烧写Flashsf probe sf erase 0x0 0x800000 sf write 0x15000000 0x0 0x800000这样即使QSPI启动失败还能切回SD卡模式重新烧写至少不会把系统弄到彻底无法恢复。另外提醒一点每次重新生成BOOT.BIN后确认bit流是不是已经更新。我遇到过好几次FPGA逻辑没生效排查半天才发现是BOOT.BIN里打包的还是旧bit。4.3 串口波特率漂移导致乱码和启动日志中断如果启动日志前面正常、后面开始乱码最常见的原因是时钟树配置和U-Boot里假设的波特率不一致。ZYNQ里UART的波特率由PS时钟分频得到FMQL的UART模块类似但外部晶振或者PLL配置变了如果不改U-Boot里的时钟计算实际波特率会偏离115200表现为乱码。排查时可以先把串口波特率调到9600或者38400看看是否依然乱码如果低波特率正常基本可以断定是分频误差问题。然后回FSBL或者U-Boot源码里核对UART时钟源的频率计算结果。4.4 Linux下外设加载失败、中断申请失败系统能启动但外设不工作多半是设备树和实际硬件不匹配。排查顺序是先确认设备树节点是否存在在Linux启动日志里搜索对应的设备名确认base address和interrupts是否正确然后看驱动是否匹配compatible字段最后再查引脚复用是否配置正确。我在排查GPIO控制继电器时发现通过sysfs导出的GPIO编号和原理图上的网络名对不上。原因是FMQL的GPIO控制器bank数量和偏移映射和ZYNQ不一样GPIO编号计算逻辑也不同。解决方法是先在Linux下把GPIO控制器的寄存器全部dump出来手动翻转一位确认哪个bank对应哪个管脚再修正驱动里的GPIO编号。4.5 常见问题速查表问题现象可能原因快速排查方法解决方案串口无任何输出启动模式不对、晶振未起振、DDR初始化失败检查拨码/JTAG连接/电源灯确认启动模式电平、查FSBL日志串口乱码时钟树PLL配置错误、波特率分频不准降低波特率测试重新配置PS时钟树、核对晶振频率QSPI烧录后无法启动Flash ID不匹配、镜像偏移错误SD卡启动后用sf命令检查Flash内容换Flash型号或用sf probe确认Linux启动到一半卡死设备树中clock节点不匹配、DDR参数不对用earlyprintk定位卡死位置使用官方BSP的dts模板修改外设中断申请失败设备树中断号错误、GIC配置问题查看/proc/interrupts对照FMQL中断号表修改QT界面花屏或偏移framebuffer参数不对、字体缺失检查/dev/fb0分辨率和色深强制指定QT_QPA_PLATFORM参数网络不通PHY地址变化、MDIO时序问题U-Boot里跑ping测试修改U-Boot和内核里的PHY地址DDR带宽不如预期DDR控制器参数、Cache一致性开销运行lmbench内存测试调整DDR时序和刷新参数5. 性能验证与长期稳定性测试的几点体会5.1 实测链路吞吐与CPU负载评估迁移完成不代表项目结束性能验证才是决定能否量产的关口。我这边做了几项基础测试内存带宽测试用lmbench或者STREAM分别测memcpy、read、write的带宽跑这个主要是看DDR控制器参数是否正确以及Cache策略有没有问题。网络吞吐用iperf3在板卡和PC之间打流千兆口如果只能跑到700Mbps先排查PHY配置和描述符数量再考虑DMA缓存一致性开销。CPU浮点性能可以用CoreMark或者干脆编译一个实际算法跑计时对比ZYNQ-7020上的耗时判断是否需要把部分热点逻辑搬进FPGA。从实际项目来看FMQL45T900在LinuxQT应用场景下性能足够用但FPGA和PS之间的数据搬运如果走的是DDR还是要做带缓存的批量DMA避免每个像素都触发CPU访问。5.2 功耗与温升管理A7双核跑Linux加QT全屏刷新整套板的功耗比原ZYNQ方案略低一点但PL侧如果同时跑高速接口热功耗会增加不少。FMQL45T900的封装比较大散热设计反而比ZYNQ好做。我们给PL侧加了温控风扇策略通过一个AXI GPIO接温度传感器Linux里写个小服务读取温度超过70摄氏度开始调速实测满负载运行8小时后温升稳定。如果你也有温控需求建议在迁移阶段就把温度传感器的设备树节点和QT状态显示预留好不要等到整机测试时再补。5.3 软件版本和配置管理经验国产化迁移项目里有大量中间产物FSBL工程、U-Boot配置、内核补丁、设备树、QT库、各种驱动源码。建议从一开始就建立独立的分支管理用专门的文件服务器或者Git仓库保存每一版能够正常运行的BOOT.BIN、内核镜像、设备树和根文件系统。每修改一个参数就在commit信息里写清楚原因比如“增加DDR读写延迟解决低概率启动失败”否则两周后你会发现自己改过什么完全记不清。我在项目里养成了一个习惯每次烧写前把当前运行的BOOT.BIN、zImage、dtb、rootfs都打包留存按日期和版本号命名。这样即使后面某次更新把系统搞挂也能迅速回滚到上一个可运行版本。5.4 稳定性测试和量产前必做的回归项量产前的稳定性测试建议覆盖这几项长时间上电老化测试至少72小时同时监控串口日志、温度、网络连接数和内存占用掉电重启测试用定时插座循环断电上电检查每次是否都能正常启动特别是DDR初始化和QSPI读取是否能每次都稳定完成拔插外设测试USB、SD卡、网线在系统运行状态下反复插拔外设并发压测比如一边网络灌数据一边QT界面切换一边UART通信看系统是否出现死锁或者内存增长。这些回归项如果在原ZYNQ平台上已经跑过就用同样的测试脚本在FMQL平台上再跑一遍。没有脚本的也建议趁迁移阶段整理出一份自动化测试清单后面每个版本的软件更新都跑一遍能省很多半夜定位问题的精力。写在最后的实操心得整个项目做下来最大的感受是“迁移”这件事的难点不在于单个点有多深而在于你以为一样的系统里藏着各种不一样的细节。ZYNQ用久了之后很多人会默认PS的寄存器和外设行为是行业标准但换了国产芯片之后必须清空原来的假设拿着数据手册一个寄存器一个寄存器地核对。如果想少踩坑我建议在迁移初期把团队分工成硬件、FPGA、嵌入式软件三条线每条线都先实现最小可用版本再把三套东西合并起来联调。先别追求功能全跑通先让SD卡能启动到Linux再把每个外设逐个验证最后才做QT界面和业务逻辑。这种“最小系统先行”的策略帮我几天内就排除了大量基础问题。最后分享一个小技巧把原ZYNQ平台和FMQL平台放在同一张桌子上同一个应用在两块板上同时跑对比串口日志和驱动加载顺序。直观看差异比看文档快得多尤其是设备树和中断这类配置问题一对比就能定位到是哪个节点配置不对。希望这篇笔记能帮正在做国产化替代的同行们少走一些弯路也欢迎大家多交流FMQL平台上的实操经验。
