做国产芯片的开发很多时候难的不是技术本身而是第一步资料太散、路线不清晰。最近好几个群里的朋友都在问复旦微FMQL的PS端能不能直接用IAR做裸机开发甚至有人拿着Zynq的教程往FMQL上套能跑通一半但卡在启动流程上。这篇前言先把整个系列的地图铺开——FMQL和Zynq到底是什么关系、为什么选IAR而不是官方SDK、裸机开发在PS端意味着什么以及后续文章会按什么路线推进。适合三类人读从STM32这类MCU转型过来的工程师、有Zynq经验想快速评估FMQL切换成本的老手、以及想系统了解PS端底层开发的FPGA工程师。1. 复旦微FMQL一颗国产Zynq的来龙去脉1.1 FMQL45T900的核心规格与定位复旦微FMQL系列是典型的异构SoC芯片以最常见的FMQL45T900为例它内部集成了双核ARM Cortex-A9处理器旁边紧挨着一大块FPGA可编程逻辑。这种ARMFPGA的组合本质上是把一个嵌入式CPU和一个可重构加速器封装在同一颗芯片里CPU负责跑流程、跑协议、跑算法调度FPGA负责做高速并行处理和IO扩展。PS端Processing System包含双核A9、DDR控制器、DMA控制器以及一串板级硬核外设——UART、SPI、I2C、CAN、USB、千兆以太网GEM等等。PL端Programmable Logic就是那颗FPGA核心逻辑容量、DSP单元、BRAM分布在PL侧具体资源看型号FMQL20、FMQL45、FMQL60这些不同档位的芯片PL容量逐级拉开但PS端架构基本一致。这点非常关键你在一颗低端型号上写的PS端裸机代码换到高端型号上编译一下基本就能跑。FMQL的定位就是奔着Zynq-7000系列去的——引脚、启动流程、地址映射、甚至很多外设的寄存器布局都有很强的对应关系。用国产Zynq来称呼它不是营销话术而是从工程实践角度确实可以大量平移Zynq的开发经验。但注意我说的是对应关系而不是完全兼容。想拿Zynq的裸机工程直接烧进FMQL就跑基本不现实至少在FSBLFirst Stage Boot Loader阶段、时钟配置、部分外设驱动上需要重新适配。这就是为什么这个系列选择从PS端裸机开发切入——它是最能体现同与不同的战场。1.2 为什么越来越多项目转向FMQL这类国产方案抛开后端供应链、国产化率等大环境因素不谈光从纯技术视角看FMQL有几个非常实际的吸引力。技术支持响应速度是一个经常被低估的加分项。用海外芯片的时候遇到奇怪的硬件行为或者资料含糊的地方很多时候只能翻社区、猜寄存器、靠经验硬扛问题可能要拖一两周。而FMQL这边原厂和代理商技术支持能直接拉群、发邮件、甚至派人现场支持遇到启动异常或时序问题回复效率完全不是一回事。对项目排期卡得紧的团队来说这比芯片本身的性能参数重要得多。另一个原因很多团队摆不上台面但心里都清楚BSP和驱动适配成本。Zynq在Linux下的BSP、设备树、驱动补丁数量庞杂但FMQL毕竟也是同类架构能做到大部分复用。加上复旦微这些年陆续推出了完整的参考设计、裸机例程和Linux BSP从评估一下到能跑起来的距离比很多人想象中要短。群里经常有人说上电第一件事是先把Zynq的doc翻出来对照着看这本身就是FMQL定位成功的最有力证明。1.3 FMQL与Zynq-7000的兼容关系哪些能平移哪些必须重写聊兼容性前先明确一点我说FMQL和Zynq-7000有对应关系指的是体系结构层面的相似而不是可以在同一条生产线上互通替换。我建议把可复用性分成三档来看内容可平移程度备注ARMv7-A架构知识、ARM文档、中断模型完全可平移ARM Ver系架构由ARM公司定义与芯片厂商无关AXI总线协议、PL与PS交互模型高度可平移AXI是公开标准协议PL侧IP使用习惯完全一致FSBL启动流程、DDR初始化参数需要重写引脚映射、DDR颗粒型号、BootROM行为有差异外设驱动寄存器代码部分可平移UART、SPI等通用功能寄存器布局高度相似但地址、中断号有差异必须逐一核对官方SDK生成的BSP不可直接复用需要基于FMQL对应的BSP或独立编写实际踩过的坑也佐证了这个表。之前我拿Zynq的裸机UART例程改到FMQL上中断号对不上反复看寄存器发现UART基地址有偏移但驱动逻辑本身没什么改动空间。所以我的建议是把Zynq的资料当作思路参考而不是素材库越底层的代码越要自己造轮子这也是这个系列坚持用IAR从零写代码的原因。2. 为什么选IAR做PS裸机开发工具链背后的真实考量2.1 裸机开发的场景与边界什么项目才真的适合裸机FMQL这类带MMU的双核A9芯片摆在面前的软件方案其实有三条路裸机、RTOSFreeRTOS、RT-Thread等、Linux。很多人觉得既然芯片这么强跑个Linux才对得起算力。但实际上裸机方案在特定场景里是压倒性的最优解甚至没有之一。第一个典型场景是确定性要求极高的实时控制。Linux的调度延迟、缓存未命中、中断处理优先级都不是应用层能完全控制的。而裸机程序里中断优先级、临界区、定时器全部由自己掌控时序抖动可以压到微秒级甚至更小。这对电机控制、激光测距、精密仪器这类场景是致命的。第二个场景是量产固件的成本和复杂度控制。Linux系统对Flash和DDR的需求摆在那里还要处理文件系统、启动镜像、内核版本管理一套下来光维护成本和升级风险就够团队喝一壶。裸机固件一个bin文件搞定烧录、升级、回滚都极其简单。第三个场景是在相对简单的系统里避免过度设计。如果你的需求就是做数据采集、协议转换、逻辑控制根本没有跑Linux的必要裸机甚至不需要RTOS一个超级循环加中断就足够。我见过不少团队把Zynq当STM32用效果非常好。当然如果项目需要用到完备的网络协议栈、复杂文件系统、动态加载模块、多用户权限或者团队根本没有意愿写底层驱动那就老老实实上Linux。裸机的边界在于你能掌控多少复杂性——掌控不了就不要裸奔。2.2 IAR、官方SDK、GCC三足鼎立到底怎么选很多FMQL新人会默认使用官方配套的SDK开发环境毕竟从Zynq习惯迁移过来最自然。另一个阵营是从MCU圈转型过来的工程师他们上个项目用的是Keil或者IAR手里积累了大量现成的底层代码和调试习惯。第三个阵营是Linux工程师习惯GCC和Makefile。这三个阵营各有各的道理但作为侧重PS端裸机开发的系列教程我选择IAR理由很直接。IAR Embedded Workbench for ARM对Cortex-A9的支持非常成熟。编译优化效率在业界算第一梯队生成的代码密度和运行效率都不错调试器接口稳定JLINK、CMSIS-DAP都能顺利接。最关键的是对从MCU切过来的工程师来说IAR的操作习惯与Keil接近工程管理、断点、变量监视、寄存器窗口上手几乎没有学习成本。官方SDK如果把FMQL的配套IDE算进来的话走的是和Vivado等PL工具深度绑定的路线对PLPS联合调试更友好但软件工程师往往抱怨两件事工具版本升级频繁导致工程迁移痛苦以及生成的代码里大量封装层想去理解底层细节的时候很费劲。做裸机开发我们希望代码的每一行都是自己写得清楚的而不是SDK自动生成一堆难以追踪的大杂烩。纯GCC加Makefile当然也能干活且工具链免费、自动化程度高。但调试体验需要额外花时间配置比如OpenOCD、GDB脚本、Flash烧录工具链。对初学者和中小团队来说把这部分时间省下来投入到功能开发上更划算。我的实际方案是IAR为主GCC为辅常规开发和调试用IAR批量编译和CI构建时用GCC。两边只需要维护同一个源文件集合工程文件分开配即可。2.3 我用IAR跑PS端工程时踩过的工具链坑先把体会放这儿IAR本身的编译和调试没什么问题问题几乎全出在工程之外的衔接环节上。最大的坑是调试前的初始化。Cortex-A9上电后DDR控制器根本没有初始化片上RAM又小得可怜。直接用JLINK加载程序到DDR地址去debug十有八九会跑飞。解决办法有两个要么让IAR在调试会话启动前执行一段初始化脚本把DDR时序、时钟PLL、引脚复用全部配好要么先用官方工具链生成一个FSBL烧到QSPI Flash里把硬件初始化做完然后IAR只负责加载应用程序。这个系列的后续文章会专门用一整篇讲清楚FSBL和IAR的配合方式。另一个坑是中断控制器。A9的GICGeneric Interrupt Controller和Cortex-M系列的NVIC完全是两码事。我见过不少人在IAR里开了UART中断中断处理函数写完却发现进不去——不是代码写错了是GIC的使能流程需要在每个CPU接口上单独操作。而且中断处理函数要写成裸函数避免编译器插入多余的上下文保存恢复代码。这些细节官方例程里往往一笔带过实际踩一次坑至少浪费大半天。还有一个容易被忽视的点链接脚本。IAR的按钮操作很直观但链接脚本里堆栈指针初始值、堆的位置、异常向量表布局这些如果照抄STM32工程模板百分之百出问题。Cortex-A9的向量表是可以重定位的但裸机启动代码里必须显式设置VBAR寄存器再加上IAR的__low_level_init、__iar_program_start这些启动流程钩子少配一个都可能让代码死在很奇怪的地方。这些坑在正式系列文章里都会展开讲。3. 避不开的PS/PL架构课从硬件视角理解软件分工3.1 PS和PL各管哪摊事一个办公室的类比理解FMQL最忌讳的就是把PS当普通单片机、把PL当一块大FPGA然后完全割裂地看待它们。实际操作中系统性能的上限往往取决于PS和PL之间怎么配合。打个比方PS是办公室里的人负责思考、规划、发号施令PL是车间里的自动化流水线负责高速重复性的处理动作。人的优势是灵活能处理各种异常和随机事件但速度慢流水线的优势是吞吐量大、延迟确定但只能做预先安排好的动作。在FMQL上一个典型任务是摄像头数据进来做实时图像处理然后存到内存里。摄像头接口接在PL侧数据以极高的速率流入PL。PL里的图像处理流水线对每帧数据进行滤波、边缘检测、压缩——这一系列操作不占用PS任何时间。处理完的数据通过AXI总线写到DDR内存PS的CPU只需要在最后收到一个中断然后去DDR里把处理结果取走就行。这种流水线结构才是PSPL异构SoC的真正价值所在。用裸机开发PS端程序时你写的代码通常扮演人的角色初始化外设、响应中断、控制流程、调度任务。而PL那一侧是另一套开发工具和另一个工程师或者同一个工程师的另一分身负责的。两边的开发节奏不同——PL开发要经过综合、实现、生成比特流PS开发是编译、链接、调试。最后通过FSBL和比特流加载把两部分拼起来。3.2 AXI总线PS和PL之间的高速公路系统PS和PL之间通过AXI总线通信。AXI是ARM AMBA总线家族的一员本身是公开标准。FMQL上常用的是AXI4和AXI4-Lite协议——前者用于大数据块传输后者用于单个寄存器的读写。理解AXI最实用的方式是记住三种口AXI_GP口全称General Purpose口。这个口的特点是通用性强、功能最全但带宽相对有限。PS端CPU可以直接通过GP口读写PL侧的寄存器空间PL也可以通过GP口访问PS侧的部分地址空间。一般做低速控制——比如PS往PL配置一个滤波系数寄存器或者PL向PS报告一个状态标志——都用GP口。AXI_HP口全称High Performance口。这个口是高带宽专用数据通道PL可以通过HP口直接读写PS外挂的DDR。热词里那个pl读写ps外挂ddr说的就是这条通路。图像数据从PL进来不需要CPU参与直接经HP口泵进DDR这是系统高性能的关键。HP口通常还带有FIFO缓冲能平滑流量峰值。AXI_ACP口全称Accelerator Coherency Port。这个口是带缓存一致性的加速器端口。PL通过ACP口访问PS内存时可以和CPU共用L2缓存保持数据一致性。相当于CPU和PL共享一个大脑缓存不需要软件做一致性维护适合CPU和PL频繁交换小数据的场景——但实现复杂度也比HP口高不少。实际工程中最常见的策略是控制流走GP口数据流走HP口。两者配合好系统的性能曲线会非常漂亮。我在项目里做过一次DDR带宽实测PL通过HP口写DDR的速率轻松跑满设计指标而用GP口做同样的事带宽性能差出了接近一个数量级所以关键通道必须上HP口这句话建议写进每个设计评审的检查清单里。3.3 裸机开发中最常见的三种PS-PL数据通路结合搜索热词里大家最关心的问题我列出PS裸机开发中必然会碰到的三种典型通路。这几种模式在系列后续文章里都会给到完整的可运行代码。第一种PS通过GP口访问PL侧寄存器。这种模式下PS端把PL侧的某个AXI从设备通常是一个寄存器文件映射到自己的地址空间。裸机代码里就是一个内存读写操作。比如PL侧有一个32位状态寄存器地址偏移是0x00PS侧映射基地址是0x40000000那么读状态就是*(volatile unsigned int *)0x40000000。使用场景是PS下发控制命令、查询状态、配置参数。优点是实现简单、调试直观缺点是带宽低不适合大批量数据。第二种PL发起数据流写DDR对应热词pl读写ps外挂ddr、petalinux ps端通过moverdata过去pl端ddr3。PL侧逻辑通过AXI_HP口直接把数据写进DDR。PS端要做的是提前在DDR里预留一块内存区域把物理地址告诉PL侧的寄存器然后等待PL完成后触发中断。这种模式下PS的CPU全程不拷数据性能最高。写代码时需要特别注意两点要多mem域在MMU里配置为Non-cacheable避免缓存一致性问题——裸机里如果没有开MMU就不存在这个问题还要预留物理连续内存不能随便malloc。这个场景的完整流程会在PL访问DDR的专题里拆解。第三种中断与握手通知。PL侧完成一批数据后通过AXI的interrupt信号向PS的GIC发起中断。PS在中断处理函数里读取PL的状态寄存器确认数据已经就绪然后继续处理。中断是最常用的PS-PL协作通知手段但也是最容易出错的地方——GIC配置、中断号分配、PL侧IP的中断输出极性任何一个环节不对程序就卡死在等待中断那一步。这个系列也会用一篇专门文章cover。4. 系列总览与前置准备动手之前先搭好认知框架4.1 内容路线图这个系列一共要讲什么作为前言我得把整个系列的学习地图交代清楚。后面的文章大致按以下逻辑推进章节主题核心目标本篇前言与整体框架建立认知地图理解选型逻辑第2篇开发环境搭建与调试链路IAR安装、JLINK配置、FSBL生成、第一个Hello World跑通第3篇GPIO与MIO/EMIO从点亮一个灯开始理解PS端引脚复用第4篇UART轮询与中断串口驱动从轮询到中断改写掌握调试手段第5篇GIC中断控制器深入中断源、中断分发、CPU接口配置、嵌套优先级第6篇PS与PL交互入门通过AXI GP口完成寄存器读写、中断握手第7篇DDR内存管理与MPU配置内存布局、Non-cacheable/Cacheable设置、TCM使用第8篇PL通过HP口访问DDR高速数据传输实战、带宽实测、一致性对策第9篇DMA控制器使用从DDR到外设、从PL到DDR不占CPU的数据搬运第10篇双核启动与裸机多核通信双核协同工作机制、核间中断与共享内存第11篇Bootloader与固件升级IAR裸机工程与FSBL合并、QSPI烧写、bin文件生成注意每篇文章的依赖关系。第2篇是门槛第4、5篇是PS端基本功第6篇开始进入PS-PL联调领域越往后越综合。我建议按顺序推进不要跳着看——尤其是中断和MMU配置在后续章节里会被反复引用。4.2 前置知识清单不用学完也能看懂但学过会事半功倍这个系列虽然是从零开始但我默认读者多少有点嵌入式开发的底子。具体来说C语言基础是硬门槛而且是寄存器操作、指针操作那一套不是会写链表就行。至少要知道volatile关键字为什么存在、结构体怎么按地址映射、函数指针怎么调用。CPU面对寄存器时本质上就是一组可读写的内存地址全部通过指针操作来实现。ARM基础概念也不能完全空白。至少要明白CPU有几个特权模式、异常向量是什么意思、中断和异常的区别、什么是MMU和Cache。如果你之前只写过STM32Cortex-M其实底子是够的——A9和M系列在架构复杂度上差了不少但基本思维方式共通。本系列里遇到A9特有的概念我会花篇幅展开但不会过度科普ARM通用指令集。FPGA基础可以放后面补。但至少要明白PL侧有个东西叫比特流bitstreamPS侧程序叫可执行文件两者是独立编译、联合加载的。你不一定要会写Verilog但后续文章里涉及PL侧IP的时候我会尽量给到可以直接综合的代码你只要能在PL工具里生成比特流、加载进芯片就够。4.3 硬件与软件准备清单照着买、照着装少走弯路硬件上最核心的是一块FMQL开发板。以FMQL45T900为例市面上很多开发板的板载资源都够这个系列使用至少一个USB转串口、一组LED和按键、DDR3内存、QSPI Flash、JTAG调试接口。选板子时注意一个细节确认板载DDR容量和型号因为FSBL阶段DDR初始化参数和它强相关不同颗粒的时序参数不一样。调试器方面JLINK V9以上V10、V11更好是比较省心的选择IAR对JLINK的支持最为完善。如果用板载调试器确认IAR的CMSIS-DAP配置是否匹配。串口工具建议备一个USB转串口模块FT232或CP2102都可以注意3.3V电平逻辑电平兼容。软件清单如下IAR Embedded Workbench for ARM版本建议9.30以上。A9支持在这个版本线里非常完善低版本可能出现调试器兼容性问题对应使用IAR的License。License这块建议提前解决别等到调试的时候弹窗再找——有条件用正版授权条件有限就用官方评估版或项目组共享license这不多展开终端串口工具MobaXterm、SecureCRT、甚至串口助手都行设置波特率、流控时注意和FSBL/BSP保持一致FMQL的PL端开发工具链用于生成PL比特流以及FSBL。有些人会用Vivado加复旦微的器件支持包有些会用复旦微自有的CAD环境选型看手里的资料和团队习惯如果你手里有一块官方或第三方FMQL的FPGA开发板配套的FSBL模板/参考例程建议都下载下来存好——后续排错时它们会是最快的对照参照物4.4 搭建开发环境时的推荐顺序先软件后硬件先调试后业务环境的搭建顺序有讲究。我的建议是先装IAR把license激活好确认能编译空工程然后再接调试器尝试连接芯片和读取ID最后才去碰FSBL和DDR配置。这样能把问题分层——如果连芯片都读不到ID就不要去纠结DDR初始化为什么失败。第一次上手时别急着写业务代码。用IAR建立一个最简单的空工程让CPU在main函数里死循环任何外设都不初始化。确认能看到程序在main里跑起来LED或者某个寄存器能被操作就说明整个调试链路是通的。这一步虽然简单但能把后续调试时的到底是代码问题还是环境问题这个分诊成本降到最低。我第一次用IAR调试FMQL时犯过一个经典错误直接在FSBL之前加载程序到DDR结果程序怎么都不动怀疑是板子问题查半天才发现是J-Link的初始化脚本没有配复位后CPU直接跑DDR里的随机数据。从那以后我的固定流程就是确认JTAG连通、确认复位行为、确认DDR可用三步走通之后才谈其他的。这个流程也会贯穿整个系列的操作指导。还有一件事值得在前面就提一下IAR的工程文件和一些IDE习惯与我们平常用STM32时不同它用.ewp文件保存工程配置、.eww文件保存工作区。从Github上拉FMQL相关的裸机例程时注意看工程文件是不是IAR格式很多网上流传的例子其实是MDK或者GCC工程格式不兼容会让人误以为代码有问题。这也是选型IAR之后一个不太能忽视的生态检查项。这个系列写到这里框架算是立起来了。近几年国产芯片的评估走访里FMQL是我觉得潜力最被低估的一颗——既能跑Linux支持复杂业务又能切回裸机做确定性实时控制还能用PL实现灵活加速。但这颗芯片的社区资料还远不如它的海外对标丰富很多人卡在了启动、中断、PS-PL协同这些会者不难、难者不会的环节上。作为一个经历过这些坑的人我能做的就是把这个系列写厚、写实把每个环节的做法和判断依据交代清楚。如果你手头正好拿到一块FMQL开发板下一篇文章就是环境搭建和第一个裸机程序的完整实战到时候我们直接从工具链配置开始动手。