第15期做完的时候我的工程里跑的还是裸机主循环——串口能打印、PL侧的FIFO能轮询读写、中断能进、各个模块单测都过。看起来一切正常但我心里清楚这种一切尽在掌控其实是一种假象所有外设都在同一个while(1)里排队优先级、实时性、模块隔离全靠自觉代码稍微再长一点就要乱。所以第16期我决定干一件改变工程结构的事加入调度器。这一期是整个bring-up过程里比较有分水岭意义的一步。Zynq-7000这颗芯片的真正价值在于PS与PL协同而PS这一侧一旦从裸机模式切换到RTOS任务模式后面所有外设驱动、算法逻辑、PL侧数据流的接入方式都会跟着变。本文就把我在这个阶段做的事情完整拆开来讲为什么是这个时机选调度器、怎么选型、移植FreeRTOS到Cortex-A9有哪些关键步骤、中断要怎么改、实测又踩了哪些坑。适合正在做Zynq-7000平台bring-up、想把工程从玩具级推向工程化的朋友。1. 先把第15期的底子摊开这个平台此刻还缺什么1.1 十五期结束时系统已经具备的能力简单回顾一下我手上这套平台的现状。经过前面十几期的折腾PS侧的启动链路是通的FSBL能正常加载、U-Boot能起来、内核最后也顺利跑到了命令行这是Linux侧裸机侧我们另有一条从BSP生成的ELF直接上板的路径。PL侧的bitstream加载没问题PS透过AXI总线对PL侧BRAM/寄存器的读写验证也通过了UART的收发、GPIO的点灯、裸机中断的进入退出逻辑都单独验证过。为了不让后面的描述悬空我把第15期结束时系统里确认过的东西列一个表。功能模块状态验证方式PS启动链路正常FSBL U-Boot 内核引导PL bitstream加载正常通过SD卡/FSBL加载AXI总线读写正常AXI GP口读写PL侧BRAM寄存器UART串口通信正常裸机printf收发测试GPIO控制正常按键输入、LED输出测试裸机中断正常定时器中断、PL中断均可触发当时所有验证都是在一个main函数里通过主循环完成的。UART要轮询发送、GPIO要轮询读取、PL侧状态要轮询刷新唯一的异步机制就是中断服务函数。1.2 裸机主循环模式的天花板在哪里很多人做Zynq开发会喜欢裸机主循环因为简单直观逻辑是一行行顺序下来的。但等你手上的模块超过两三个这个模式就开始变味了。打个比方主循环就像一个只有一个收银台的小超市所有顾客事件都必须在柜台前排队谁先到谁先结账哪怕是VIP客户高优先级事件也得等着。具体到我的平台问题有几个明显暴露点。第一是响应实时性不可控。PL侧如果有一个高频数据流比如每毫秒产生一个中断而主循环里某个外设查询函数执行时间稍长下一次中断的数据就可能被覆盖。裸机下想保证实时性唯一靠谱的办法就是把关键代码全塞进中断里但中断里塞太多逻辑系统又会被拖死。第二是模块间耦合严重。每个新功能都要改主循环的调用顺序要么加标志位要么加状态机。多个功能模块共享同一个循环变量、共享同一个全局状态排查问题的时候谁都说不清是哪个模块改坏了什么。第三是没有统一的休眠机制。CPU永远满转功耗和发热在嵌入式设备上是硬伤。想让CPU在空闲时停下来等事件裸机下要自己实现低功耗逻辑又回到容易出错的老路。1.3 第16步为什么是调度器bring-up顺序里的合理化解释我理解的工程师化bring-up不是简单地把外设一个个点亮而是让这些外设最终能在一个有条理的系统里协同工作。第1期到第15期解决的核心问题是硬件能不能用、驱动怎么调通。到了第16期要解决的是硬件都通了代码结构怎么组织才能支撑后面继续叠加功能。调度器就是这个阶段最应景的工具。它正好解掉了裸机主循环的三个死结用优先级抢占保证高价值事件能被及时处理用任务边界把模块彻底隔离用阻塞机制让CPU在无事件时真正空闲下来。后面每一期再加新外设比如网口、SD卡、图像采集就不再是往主循环里插一段代码而是新建一个任务、配好优先级和信号量本质改变了工程的组织方式。2. 调度器选型为什么是FreeRTOS而不是Linux或继续while(1)2.1 一个不科学的直觉Zynq不是能跑Linux吗为什么不用聊到调度器很多人第一个念头是Zynq-7000这边不是有完整的处理器系统吗直接把Linux跑起来不就完事了Linux内核本身就是个超强的调度器什么任务调度、内存管理、网络协议栈全都有了。我确实在平台上验证过Linux但把系统换成Linux跑业务等于把bring-up的难度整体抬了一个数量级。Linux的启动链路更长U-Boot配置、设备树、内核配置、根文件系统每个环节都是新的不确定性来源。而且PL侧的IP核要接入Linux你得按照Linux的设备驱动模型写驱动要么用UIO要么走DMA框架这和在裸机上直接操作寄存器完全是两回事。对正在做PS/PL协同验证的团队来说Linux的驱动框架会把PL侧的调试问题掩盖在一堆不明原因的内核报错里排查起来非常痛苦。Linux适合做产品化的最终形态不适合放在bring-up阶段当调试杠杆。如果嫌Linux太重又不想回到裸机轮询的死胡同FreeRTOS或者类似的轻量RTOS就是刚好卡在中间的那个选择。2.2 FreeRTOS在Cortex-A9上的表现与生态我选FreeRTOS说到底四个字轻、稳、熟、多。轻不只是内核代码量少关键是心智负担小。整个内核就是task、queue、semaphore、timer这几样东西搞过单片机的人大概一两天就能上手。对Cortex-A9这种带MMU、带GIC的复杂处理器来说FreeRTOS的Cortex-A9移植层是官方维护的社区里用Zynq跑FreeRTOS的案例非常多遇到问题能搜到的参考资料比任何其他RTOS都多。稳体现在板级验证上。Zynq官方SDK本身就提供FreeRTOS的BSP模板说明Xilinx自己就用它做过Zynq平台验证。GIC中断、物理定时器、上下文切换这些A9特有的东西官方移植代码已经处理好了不再需要我从零写核心汇编。熟是对团队说的协作的同事大都学过FreeRTOS后续维护成本低。多则是说生态任务通知、流缓冲、软件定时器需要的组件基本都有。其他轻量RTOS我也评估过。RT-Thread国产化程度高、组件丰富但Zynq平台的支持相对没有FreeRTOS那么原装uC/OS经过商业授权风波后许可条款让一部分商业项目有顾虑。选型这种事没有绝对好坏只有跟自己的平台和团队匹配不匹配对我来说FreeRTOS是这个阶段最省事的选项。2.3 单核任务调度与双核负载均衡本期先不碰SMP这里要给一个特别重要的提醒Zynq-7000是双核Cortex-A9但FreeRTOS加入系统绝不等于从此就双核并行跑任务了。这期我选择的是单核模式把所有任务调度都在CPU0上跑CPU1先挂起。原因很实在双核SMP模式涉及CPU间中断、任务迁移、锁的竞争粒度、缓存一致性任何一个问题在bring-up阶段都是巨大的调试黑洞。先把单核调度跑稳确保任务切换、中断嵌套、信号量同步全部没问题后面再开SMP就是水到渠成的事。至于负载调度器这种话题——双核之间怎么把任务均匀分配、怎么让高负载核的实时任务迁移到空闲核那是在SMP打开之后才真正变成焦点的。单核模式下所有任务都挤在一个核上讨论负载均衡是空中楼阁。所以这期先把调度本身做好负载均衡留给后面专门的一期来讲。3. 工程移植记录从裸机SDK工程到FreeRTOS任务工程3.1 代码组织把FreeRTOS源文件和BSP分隔开移植的第一步不是写代码而是先把工程目录结构理清楚。我以前见过不少人的做法是把FreeRTOS源码直接拷进BSP目录里平铺看起来省事实际上把第三方代码和项目代码混在一起以后升级内核版本、同步修改都痛苦。我最终采用的结构是这样的app/ main.c bsp/ platform.c platform.h uart.c pl_driver.c pl_driver.h task/ app_task.c app_task.h freertos/ Source/ include/ portable/ GCC/ARM_CA9/ list.c queue.c tasks.c timers.c event_groups.cFreeRTOS源码保持原样一份干净、只读的第三方代码放在freertos目录下编译系统把它作为静态库或者直接编进来都行。自己的初始化代码和任务逻辑放app目录靠include路径来引用FreeRTOS的头文件。这样做最大的好处是FreeRTOS源码可以随时换版本我的应用层代码完全不依赖它是怎么组织的。3.2 FreeRTOSConfig.h里最关键的四组配置FreeRTOS没有图形化配置界面所有裁剪和参数都在FreeRTOSConfig.h里完成。这个文件我照搬了官方Cortex-A9 port的模板然后根据自己的工程调整了关键几项。这里必须说明不同版本的port对配置项的依赖不完全一样以下内容是基于我当前工程的实际配置用的是官方ARM_CA9移植目录下那套实现。#define configUSE_PREEMPTION 1 #define configMAX_PRIORITIES 8 #define configTICK_RATE_HZ ( 1000 ) #define configTOTAL_HEAP_SIZE ( 128 * 1024 ) #define configSUPPORT_DYNAMIC_ALLOCATION 1 #define configUSE_MUTEXES 1 #define configUSE_COUNTING_SEMAPHORES 1 #define configUSE_TIMERS 0 #define configUSE_PORT_OPTIMISED_TASK_SELECTION 1 #define configMINIMAL_STACK_SIZE ( 128 ) #define configUSE_NEWLIB_REENTRANT 1几个要展开讲的重点configTICK_RATE_HZ是调度器的心跳频率。我设定为1000Hz也就是每个tick间隔1ms。这个值决定了系统时间的最小粒度也决定了定时任务延时、超时的精度。对PL侧高频中断的场景1000Hz足够支撑绝大多数控制周期需求。如果后续要做音频、高精度PWM这类周期更短的任务可以提到2000甚至4000Hz代价是CPU每秒钟要处理更多次tick中断上下文切换开销也随之上升。configTOTAL_HEAP_SIZE决定任务栈的总容量。这是新手最容易忽略的一个宏。FreeRTOS里面xTaskCreate动态创建任务时任务的栈是从堆里分配的而这个堆的大小就是由configTOTAL_HEAP_SIZE定义的。我给了128KB。从后面实际运行情况看4到5个任务、每个任务栈4KB到8KB堆空间还有富余但如果后面要加TCP/IP协议栈、文件系统组件这个值得再往上加。configUSE_PORT_OPTIMISED_TASK_SELECTION必须关心。这个是Cortex-A9 port特有的优化项打开后任务选择会使用硬件指令来加速查找最高优先级任务比纯软件遍历要快。对实时性敏感的场景建议打开但前提是优先级数量不能超过32个我的configMAX_PRIORITIES是8满足要求。configUSE_NEWLIB_REENTRANT要注意。如果你在Zynq上用了newlib的printf、malloc这类C库函数这个配置必须为1。它的作用是让每个任务有独立的errno和stdio状态避免多个任务同时打印时库内部状态被互相覆盖。这个配置直接和后面要讲的串口打印踩坑有关。3.3 链接脚本与栈的搬运内存分配不能想当然裸机工程里Cortex-A9的栈顶、堆位置通常是在链接脚本里写死的。加入FreeRTOS后任务栈都要从堆里动态分配所以堆的设置变得格外重要。我遇到过的情况是链接脚本里堆的起始地址和大小设置不合理任务一创建就报内存申请失败但看代码又明明调用了xTaskCreate问题极其隐蔽。另外一个印象深刻的点是FPU。Cortex-A9带硬件浮点单元Zynq的CPU默认上电后FPU是关闭的需要在启动代码里把CP10、CP11的访问权限打开并且把FPEXC的EN位置1。如果忽略这一步任务里只要有一句浮点运算CPU立刻进入Undefined Instruction异常表现就是死机或者反复复位。我的解决办法是在启动汇编里加入FPU使能代码同时在链接脚本里把栈裸机模式的启动栈放到OCM里因为早期代码在DDR初始化完成前就要使用栈。// 启动代码中的FPU使能片段示意 // 将协处理器访问权限打开并允许用户态访问 __asm volatile( mrc p15, 0, r0, c1, c0, 2\n orr r0, r0, #(0xf 20)\n mcr p15, 0, r0, c1, c0, 2\n isb\n mov r0, #0x40000000\n fmxr fpexc, r0\n );实际验证中发现FPU使能这类底层代码写错位置或者漏掉并不会立刻在启动阶段报错而是要等到第一个涉及浮点的任务运行才崩排查起来特别容易把怀疑的焦点引向任务优先级或调度逻辑走了不少弯路。4. 裸机中断与FreeRTOS中断的翻译最容易翻车的环节4.1 从XScuGic的Handler到FreeRTOS的ISR加入调度器之后整个中断体系的处理姿势跟裸机时代完全不同。裸机模式下我简单地在XScuGic_Config里注册好中断回调函数中断一来CPU就跳进回调跑完再回去。但FreeRTOS的Cortex-A9移植层接管了GIC的一部分核心逻辑中断进入时会先走port层的中断处理代码然后才到我的回调。这个变化带来的直接要求是我的ISR里不能随便调用任务级的API必须使用后缀带FromISR的版本。裸机时代的典型写法是// 裸机风格中断服务函数里直接处理业务 void PL_IRQHandler(void *CallbackRef) { u32 data Xil_In32(PL_FIFO_BASE); process_data(data); XScuGic_DeviceDriverUpdate(Gic); }切换FreeRTOS之后我最简单的PL通知中断变成了这样// FreeRTOS风格中断里只做事件通知具体处理挪到任务 void PL_IRQHandler(void *CallbackRef) { BaseType_t xHigherPriorityTaskWoken pdFALSE; vTaskNotifyGiveFromISR(pl_rx_task_handle, xHigherPriorityTaskWoken); portYIELD_FROM_ISR(xHigherPriorityTaskWoken); }两段代码最大的区别是处理数据的动作从ISR里消失了变成了一个信号通知。中断服务函数要做的事情只有三件——快速读取必要的硬件状态、通过FromISR接口通知对应的任务、必要时让出CPU。数据搬运、运算、格式化输出这些耗时操作全部挪到任务上下文里做。这样做的好处是中断占用的时间极短系统不会因为高频中断而假死。4.2 中断优先级与调度器tick的关系FreeRTOS的调度发生在tick中断和系统调用里所以硬件中断的优先级设置对调度行为有直接影响。这里有个经验法则不能让所有硬件中断的优先级都高于tick中断否则tick永远被硬件中断打断调度器无法按预期周期运行也不能让所有硬件中断都低于tick否则关键外设的实时响应会被tick抢占。我在Zynq上的实际配置是PL侧高速数据中断优先级最高因为数据流中断丢失代价最大UART中断和软件定时器中断设为中等tick中断设为中等偏下。这样既保证了高速外设能抢占调度器获得快速响应又不至于让tick饿死。GIC中断优先级的数值越小优先级越高Cortex-A9对每核有多个优先级级别。具体到每个设备的中断号直接照着Zynq-7000 TRM里的中断表查就行。PL侧的中断输入我用了SPI 61这一组UART1的中断号在SPI组里是60这些数字在配置的时候一定要和原理图、地址分配表对清楚编错了最直接的现象就是一个设备的中断跑到另一个设备的中断服务函数里。另外要注意FreeRTOS在Cortex-A9上对中断的处理依赖GIC的优先级比较和抢占。你需要在启动GIC时就把优先级抢占功能打开否则多个中断同时到达时行为就不好控制排查起来会非常困惑。4.3 任务同步的原语选择信号量、事件组还是任务通知任务之间怎么打交道是第16期我花时间最多的地方。FreeRTOS提供了一大堆同步原语最常用的是二值信号量、互斥量、队列、事件组、任务通知。裸机时代我习惯用全局变量加标志位在任务环境下这种习惯要改掉——因为改共享标志位的时候不是原子的两个任务可能同时读写同一个变量产生竞态。我总结了一套自己的选型经验同步场景推荐原语理由中断通知任务有数据了任务通知速度快CPU开销最小多任务抢占共享慢速外设互斥量有优先级继承防优先级反转生产者消费者传数据队列自带缓冲天然实现解耦等待一组事件中的任意一个事件组位掩码操作逻辑清晰任务通知xTaskNotifyGive是这里面开销最低的一次典型的通知大约只花几百纳秒到几微秒取决于是否有任务需要唤醒非常适合ISR到任务这种高频场景。队列看起来方便但数据拷贝有开销如果传的是大块数据我更倾向于把数据放在全局缓冲里队列只传指针或者帧序号。在PL侧FIFO接收任务里我用的是任务通知指针的方式ISR里xTaskNotifyGive通知任务收到通知后从全局双缓冲里取数据然后立刻回下一次接收。实测在1MHz左右的PL数据流频率下CPU占用率可以接受数据不丢。5. 任务化改造后的实测三个必踩的坑与排查链路5.1 坑一printf在多个任务里打架系统串口卡死现象是最典型不过了vTaskStartScheduler之后第一个任务打印正常第二个任务一开打印串口输出就开始乱紧接着系统卡住不动了。我用调试器挂上去发现任务卡在UART的发送函数里一直等FIFO空。一开始我怀疑是UART驱动本身的问题裸机下它明明没问题。后来查FreeRTOS的一组文档才意识到多个任务同时调用printf而printf内部通过newlib的write接口写UART寄存器这里有两个并发隐患一是newlib的stdio内部有缓冲区多任务同时访问缓冲区会互相踩二是UART驱动发送过程中包含了写寄存器、等待状态位这样的非原子操作两个任务交替执行状态机就乱了。解决办法分两步。第一步开启configUSE_NEWLIB_REENTRANT保证每个任务有独立的stdio锁第二步给UART发送函数外面的printf包一把互斥量让整段格式化发送的过程变成临界区。void app_printf(const char *fmt, ...) { va_list args; xSemaphoreTake(uart_mutex, portMAX_DELAY); va_start(args, fmt); vprintf(fmt, args); va_end(args); xSemaphoreGive(uart_mutex); }需要特别注意的是这个互斥量不能直接在中断里配合xSemaphoreTake使用。中断里的调试打印要走专门的ISR版本或者在调试中断时干脆禁掉任务级的打印。我把这个坑写出来是因为它极具代表性很多加入RTOS就死机的问题根子并不在RTOS的调度本身而在你把裸机时代不设防的函数直接带进了RTOS环境。5.2 坑二PL高速中断把系统拖到假死PL侧的设计是每毫秒产生一次中断用于同步数据采集。改造前我在ISR里做的事情比较多读FIFO、解析包头、更新标志位、清零中断。在裸机时代这套逻辑能跑但切换FreeRTOS之后系统表现为看起来活着但任务调度极其迟钝LED闪烁周期变得不规则串口打印速度严重下降。我第一反应是任务优先级没配好各种调优优先级之后问题依旧。后来用示波器量了PL侧中断引脚和CPU的响应时间发现ISR里耗时接近800微秒而tick周期才1毫秒——等于CPU有将近八成的时间都泡在ISR里调度器根本没机会运行。根因清楚了ISR里做了大量非必须的软件处理。我按照前面说的原则把ISR瘦身只保留读硬件状态和发任务通知两个动作数据解析全部移到高优先级任务里。改造之后同样1ms一次的中断ISR耗时压在10微秒以内系统调度恢复正常。这算是RTOS和裸机最大的习惯差异裸机下ISR里多干点事只要不出错就行RTOS下ISR的短是系统一切正常的前提。5.3 坑三任务栈溢出引发的随机死机第三个坑是长期运行才暴露的。某次跑压力测试系统跑了一个多小时之后突然死掉复位重来又可能两三个小时才出问题。这种随机死机特别折磨人因为你没办法在几分钟内复现它。排查的时候我加了两层保险。第一层是打开configCHECK_FOR_STACK_OVERFLOW让FreeRTOS在上下文切换时检查栈边界如果有溢出会调用vApplicationStackOverflowHook我在这个钩子里打印出错的任务名。第二层是在每个任务里定期调用uxTaskGetStackHighWaterMark把剩余栈空间打印出来观察。这样跑了一个晚上抓到是某个任务栈不足局部数组加函数嵌套调用把2KB的栈吃穿溢出的数据正好踩坏了相邻任务的TCB导致任务链表被破坏随机死机。处理办法是给这个任务单独加栈到4KB并且给所有任务定了个规矩任务内大块数据用静态全局或者堆上分配绝不在函数里声明大数组。栈溢出这个问题很多人的第一反应是RTOS不靠谱其实是因为任务栈和裸机栈的设计思路完全不同——裸机只有一个大栈RTOS里每个任务都是独立的受保护栈谁在栈上过于豪放谁就是悬在系统头上的定时炸弹。6. 第16期的可交付成果与下一期方向6.1 当前任务结构列表任务怎么划分、优先级怎么排第16期结束后我手上的平台已经从裸机单循环变成了RTOS任务化结构。当前跑着的任务不多但每一个都代表一类典型场景任务名优先级周期/触发方式栈大小主要职责pl_rx_task5事件通知触发4KB接收PL侧数据解析帧ctrl_task410ms周期4KB控制算法写PL控制寄存器uart_tx_task3队列触发2KB从队列取数据发送stat_task21s周期2KB打印各任务运行状态、栈水位idle_task0空闲1KBCPU空闲处理这个优先级排列有几个讲究。PL数据接收最急放最高优先级控制算法周期性很强但周期到了本身就有硬死线放第二串口发送可以缓冲放第三。关键的原则是实时性强、丢数据代价大的任务优先级高能缓则缓的任务优先级低。优先级配错轻则CPU空转重则实时任务被非实时任务饿死。6.2 怎么验证调度器真的在工作观测手段任务化改造完成后怎么证明调度器真的达到了预期不能拍脑袋说能跑。我用了三种观测手段交叉验证。第一种是优先级抢占测试。建一个优先级很低、死循环里打印LOW的任务再建一个高优先级周期任务打印自己的名字。如果调度正常低优先级任务只有高优先级任务休眠时才能打印两者打印模式呈现明显的分时交替。第二种是栈水位监测。在stat_task里周期读取各任务的uxTaskGetStackHighWaterMark打印剩余栈。通过这个值可以定量判断每个任务的栈余量哪些任务接近危险区一目了然。第三种是系统心跳观测。用一个任务控制LED以精确的1Hz闪烁正常运行时LED闪烁均匀。一旦CPU负载过高或者中断故障导致调度器饥饿LED闪烁会明显变得不规则。这个办法简单粗暴但确实是现场排查时最直观的传感器。6.3 双核与更高阶调度负载均衡怎么升级第16期结束不是终点。当前FreeRTOS只在CPU0上运行CPU1还是完全空闲的。后续如果要实现双核负载真正均衡有两个方向可以走。一是切换到SMP模式让FreeRTOS把任务自动分配到两个核上系统自带负载均衡能力二是保持AMP模式CPU0跑业务逻辑CPU1跑专门的硬实时任务两个核之间通过共享内存和核间中断通信。我的初步计划是先把SMP模式跑通测一下任务迁移、锁竞争的表现。对Zynq这种双核A9来说SMP的无线扩展性肯定不如高频单核方案但两个核同时跑确实能缓解单核压力。负载调度器这个方向等真正调通SMP之后再细说到时候四个核的任务怎么放、中断怎么分离、内存带宽怎么分配都是一整期的大话题。回到这一期本身我做完整套改造后最大的体会就是调度器不是一个加进去就完事的组件它像一层操作系统改变了所有代码的运行假设。裸机时代不被约束的全局变量、ISR里的大块运算、随意的栈分配到了RTOS里都会变成腐化系统的隐患。Zynq-7000这种 PS PL 的平台PL侧还有着硬实时数据流调度器更像是一个分配器把CPU时间、外设访问权限、数据流处理时机公平又高效地分散到每个需要它的模块。第16期把这层地基打稳了后面再加任何东西都会顺畅得多。