企业官网建设流程全解析

做到这个系列的第16章，我默认你前面已经把 PS 侧的串口、GPIO、SD 和以太网这些外设都点亮过，PL 侧也拉通过两三个自定义 IP。也就是说，开发板、Vivado 工程和 Vitis 工具链已经不是瓶颈——然后你会撞上一个特别真实的问题：功能一多，裸机 main loop 就开始失控。轮询任务、定时器回调、中断服务函数、状态机，全堆在一个 while(1) 里，每加一个功能都得重新梳理所有功能的时序关系。本讲要解决的就是这个核心痛点：给这套 Zynq-7000 工程化 bring-up 平台加入真正的调度器。读完这一章，你应该能独立完成 FreeRTOS 的移植接入、任务划分、PL 中断与调度器的协同，最后把平台稳定跑在抢占式多任务状态下。适合已经能烧写 BOOT.BIN、能跑起裸机外设、但正在被复杂业务逻辑折磨的工程师。

1. 为什么到第16章才加调度器：裸机代码“毒打”后的必然选择

1.1 前15章积累下的真实痛点

很多初学者对 RTOS 的认知是"反正最后都要上，不如一开始就上"。但工程化的路子不是这样。前 15 章我们干的事情本质上是把 Zynq 当成一个"超级单片机"在玩：初始化时钟、配 DDR、加载 bitstream、点灯、打串口、试 SD 卡、跑 UDP。这些功能单个拎出来都很简单，但把它们塞进同一个 main loop 之后，难受的事情就开始冒头了。

以我实际踩过的例子来说：某个外设模块的轮询逻辑原本要求 10ms 周期执行，UDP 接收又需要及时响应远程指令，PL 侧的高速采集还时不时来一个中断要你赶紧把数据搬走。三个需求挤在同一个 while(1) 里，结果就是要么把轮询周期拉长，要么让 UDP 丢包，要么在中断服务函数里干太多活导致其他中断被饿死。每解决一个 bug，都会在另一个模块里引入新的时序问题。

还有一类更隐蔽的痛点：中断回调里的"延迟敏感"代码越写越长。你以为中断里只是搬数据，实际上搬完数据还要解析、组包、登记状态，这些操作在裸机中断里全部是"原子执行"的，关中断的时间一旦变长，以太网 PHY 的中断就可能被错过。真到了这一步，main loop 已经谈不上"工程化"了，它能跑，纯粹是运气好外加时序裕量大。

1.2 调度器到底帮你解决了什么，又带来哪些成本

调度器的本质是让你把"什么时候干什么事"从"手工编排"变成"系统裁决"。裸机里每个模块的运行窗口完全靠你肉眼估算，调度器则通过优先级和时间片，把 CPU 资源按规则分配出去。对于那些延迟要求高的任务，它可以抢占低优先级任务的执行权，保证响应边界是确定的。这一点在需要闭环控制的场景里尤其重要：控制算法宁可晚 100 微秒启动，也不希望被一个无关的串口打印代码卡住 5 毫秒。

当然，引入调度器不是零成本。第一是内存成本：每个任务都要一个独立的栈空间，一个任务给 2KB~4KB 很常见，任务一多 DDR 占用就会上去。第二是调试成本：任务切换、队列传输、优先级反转，这些概念一旦出错，比裸机 bug 难查得多。第三是与现有裸机代码的磨合：你之前写的很多全局变量轮询逻辑，可能要改成任务间通信的方式。所以我把这一步放到第 16 章，就是希望你先体会过裸机方式的极限在哪里，再去理解调度器为什么是"工程化"的必经之路。

2. 调度器选型：FreeRTOS 还是自研协作式任务调度器

2.1 两种方案的全面对比

在动手之前，要先回答一个路线问题：到底是移植一个完整 RTOS，还是自己写一个简单的协作式调度器？我把这两种方案的差别列在下面，实际项目里真的需要认真权衡：

我见过不少工程师为了"轻量"或者"学习"自己写调度器，写到后面要支持信号量、消息队列、定时器时逐渐失控。协作式调度器在处理"任务主动让出"这件事上非常依赖程序员的纪律性，一旦某个任务写了一个 while 循环等条件，整个系统就卡死了。这种风险在开发调试阶段还能接受，到了现场运行阶段就是定时炸弹。

2.2 为什么选择 FreeRTOS，而不是其他 RTOS

FreeRTOS 在 Zynq 平台上的优势非常明显：Xilinx 的 Vitis BSP 生成器原生支持 FreeRTOS，创建的 BSP 里已经包含了针对 Cortex-A9 的移植代码，你不用自己去处理上下文切换、tick 定时器、GIC 中断映射这些底层细节。相比 uC/OS 的商业授权顾虑，相比 RT-Thread 在裸机 BSP 上的额外裁剪工作量，FreeRTOS 是一个社区资料最多、踩坑记录最全、迁移成本最低的选择。

还有一个重要原因是它和 lwIP 的配合。上一章如果在做以太网 UDP 测试，后续想把 lwIP 跑在 FreeRTOS 之上，Xilinx 的 BSP 有现成的 freertos_lwip 模板，网络协议栈的线程调度和裸机轮询模式完全不同，数据吞吐和 CPU 占用率都会好看很多。这个生态衔接是自研调度器给不了的。

2.3 Zynq-7000 上 FreeRTOS 的启动链路全景

在真正写代码之前，必须把整个软件执行路径在脑子里过一遍，否则出了问题会不知道在哪里断的。Zynq-7000 的启动链路大概是这样的：

1. 上电后 BootROM 先执行，根据启动模式引脚决定从 QSPI、SD、Nor 还是 JTAG 加载。
2. BootROM 加载 FSBL（First Stage Boot Loader）。FSBL 完成 PS 端的硬件初始化：DDR 控制器、MIO、时钟、PLL。
3. FSBL 通过 PCAP 接口把 PL 的 bitstream 加载进 FPGA，这个动作对应 PL 侧 DONE 引脚拉高。
4. FSBL 把应用程序的 ELF 从启动介质拷贝到 DDR，然后跳转到 app 的入口。
5. 在 app 内部，先完成 GIC、串口等基础驱动初始化，然后创建任务，最后调用 vTaskStartScheduler 交出控制权。

从这个流程可以看出，FreeRTOS 的调度器启动是"最后一步"，它的前提是之前所有工程化 bring-up 动作全部成功。如果你在加入调度器之前，裸机程序都已经验证过硬件的稳定性和启动链路的可靠性，现在要做的就是给 main 函数"换个活法"，而不是从零开始重新 bring-up。

3. 工程化 bring-up：把硬件平台彻底跑稳再谈调度

3.1 启动阶段的三板斧：DDR 初始化、时钟电路、MIO 配置

很多人在这一步栽跟头，不是因为代码写得不对，而是因为对 FSBL 的职责不清楚。FSBL 最大的作用不是"跳转"，而是把 DDR 初始化好。Zynq 的 DDR 控制器对时序参数极其敏感，Vivado 里导出的 XSA 文件中已经包含了根据你的硬件设计生成的 DDR 参数，FSBL 在编译时把这些参数固化进去。如果你换了板卡或改了 DDR 颗粒型号，却忘了重新生成 XSA，就会出现一个经典现象：上电后串口只打了几个字符就死掉，debug 一查发现 FSBL 卡在 DDR 训练阶段。

时钟电路方面，PS 侧主要由 PS_CLK 引脚的有源晶振提供参考时钟，FSBL 负责把 PLL 配到期望频率。PL 侧的时钟可以来自 PS 的 FCLK0/1/2/3，也可以使用独立的 PL 时钟引脚。我建议在工程化平台里把 PL 时钟使用 FCLK 输出，这样 bitstream 里如果涉及需要精确时钟的 IP，调试时能统一从 PS 侧调整频率，不用动 PCB。

MIO 配置则是另一个容易忽略的环节。Zynq 的 PS 引脚很多是复用功能，FSBL 要根据硬件设计在寄存器里配置好复用、上下拉和驱动能力。最常见的坑是 SD 卡检测引脚没配好，或者 UART 的 MIO 没配对，导致 FSBL 打印不出来。做工程化 bring-up 时，建议在 FSBL 之后先跑一个最小裸机程序，逐项测试 DDR 读写、串口、LED、SD 卡，确认硬件链路全部通过，再谈加调度器。

3.2 BOOT.BIN 与镜像生成流程

Zynq 的烧写方式和大体流程是工程化的基础设施。裸机应用最终打包成 BOOT.BIN，这个文件由 BIF 文件定义：

// boot.bif the_ROM_image: { [bootloader]fsbl.elf system.bit app.elf }

然后使用 bootgen 工具生成镜像：

bootgen -image boot.bif -o BOOT.BIN -w

其中 fsbl.elf 是第一阶段的引导程序，system.bit 是 PL 侧的 bitstream，app.elf 就是你要运行的 FreeRTOS 应用程序。如果只是调试，也可以用 JTAG 方式加载 FSBL 和 app，但工程化落地一定要走启动介质烧写。

以 QSPI 方式为例，烧写命令如下：

program_flash -f BOOT.BIN -fsbl fsbl.elf -flash_type qspi-x4-single -offset 0

烧写完成后把启动模式跳线拨到 QSPI，上电就应该能看到 app 的串口打印。这一步务必在加入调度器之前做一次完整的验证，因为一旦 scheduler 跑起来，复现 boot 问题会混入 RTOS 的因素，排查复杂度直接翻倍。

3.3 验证裸机程序已经稳定的判断标准

在加入调度器之前，我建议你给裸机程序定一个"稳定验收标准"。这个标准不是"能点亮 LED"，而是：

• 串口连续打印 24 小时无卡死、无乱码。
• 反复冷启动和热复位 100 次，每次都成功进入 main，打印启动 banner。
• DDR 读写测试覆盖常用的 0x10000000~0x3FFFFFFF 地址段，读写校验全部通过。
• 以太网 UDP 循环发包 10 万帧，无丢包、无错包，ping 延迟稳定。

这些标准看着机械，但都是工程化 bring-up 的底线。如果你带着一个偶发 DDR 错误或者没稳定的时钟配置去跑 RTOS，你会花十倍时间在"到底是调度器 bug 还是硬件 bug"的泥潭里。我自己的习惯是先用裸机把所有外设跑满负载压力测试，再动 scheduler，这个顺序能帮你省下大量 debug 时间。

4. 实操：把 FreeRTOS 真正搬进工程

4.1 新建平台与 BSP 的 OS 选择

在 Vitis 里导入包含 Zynq 硬件的 XSA 之后，创建应用工程时会让你选择 standalone、FreeRTOS 还是 Linux。选择 FreeRTOS 后，BSP 会自动生成一个名为 freertos 的 OS 支持库，里面包含：

• FreeRTOS 核心源码，路径在 BSP 的ps7_cortexa9_0_freertos目录下。
• 针对 Cortex-A9 的移植文件port.c（上下文切换、tick 定时器、中断入口）。
• 针对 Xilinx 中断控制器 GIC 的适配代码，包括vApplicationIRQHandler。

你不需要自己下载 FreeRTOS 源码再手动移植，这一点对工程化极其重要。因为 Xilinx 的移植测试过它自家 BSP 里的驱动，比如XScuGic、XUartPs、XAxiDma，与 FreeRTOS 的接口可以无缝配合。手动下载最新版 FreeRTOS 去移植，反而容易碰上中断接口不匹配的问题。

BSP 生成完成后，建议先打开FreeRTOSConfig.h确认几个默认宏：

#define configTICK_RATE_HZ 1000 #define configTOTAL_HEAP_SIZE (64 * 1024) #define configMINIMAL_STACK_SIZE 128 #define configUSE_PREEMPTION 1 #define configUSE_IDLE_HOOK 0 #define configUSE_TICK_HOOK 1

4.2 关键配置参数：tick、heap、最小栈

三个参数直接关系到系统能不能稳定运行，需要逐个确认。

configTICK_RATE_HZ 决定调度器每秒的时基次数，默认 1000 意味着每 1ms 触发一次 SysTick 中断。工程化平台建议保持 1000，太高会让 CPU 频繁进入时钟中断而增加开销，太低则会让 vTaskDelay 的最小粒度变大，任务调度的响应精度变差。

configTOTAL_HEAP_SIZE 决定 FreeRTOS 可用的堆空间，任务控制块、任务栈、队列、信号量全部从这个池子里分配。这里有个常见误区：堆大小不是越大越好，而是要根据你的任务数量和栈大小去估算。一个栈为 1024 字（即 4KB）的任务，加上 TCB，大约消耗 4KB 多一些。如果你规划 6 个任务，加上队列和信号量，64KB 通常够用，但如果任务栈开得很大，就需要往 128KB 以上走。

configMINIMAL_STACK_SIZE 在 Cortex-A9 移植里通常为 128 字，即 512 字节。Idle 任务的栈就这么大，别去动它。真正需要费心的是你自己创建的任务的栈大小，一个包含浮点运算、局部缓冲区较大、或者有深度函数调用的任务，建议从 1024 字起步。

另外强烈建议打开两个配置宏，它们是排查问题的左膀右臂：

#define configUSE_IDLE_HOOK 1 #define configCHECK_FOR_STACK_OVERFLOW 1 // 配合 vApplicationStackOverflowHook #define configASSERT xAssert

4.3 第一个多任务跑起来

硬件平台和 BSP 都准备好之后，写一个最简单的主程序验证调度器能转，这一步不要直接搬复杂业务逻辑。代码结构如下：

#include "FreeRTOS.h" #include "task.h" #include "platform.h" #include "xil_printf.h" static TaskHandle_t led_task_handle; static TaskHandle_t print_task_handle; static void led_task(void *arg) { (void)arg; while (1) { /* 翻转某个 MIO 控制的 LED */ XGpioPs_WritePin(&g_gpio, 3, 1); vTaskDelay(pdMS_TO_TICKS(100)); XGpioPs_WritePin(&g_gpio, 3, 0); vTaskDelay(pdMS_TO_TICKS(100)); } } static void print_task(void *arg) { (void)arg; uint32_t count = 0; while (1) { xil_printf("[tick] %u\r\n", (unsigned int)count++); vTaskDelay(pdMS_TO_TICKS(1000)); } } int main(void) { BaseType_t ret; platform_init(); // BSP 生成的硬件初始化入口 ret = xTaskCreate(led_task, "led", 512, NULL, 3, &led_task_handle); configASSERT(ret == pdPASS); ret = xTaskCreate(print_task, "print", 512, NULL, 1, &print_task_handle); configASSERT(ret == pdPASS); vTaskStartScheduler(); while (1) { /* 正常到不了这里，除非调度失败 */ } return 0; }

注意几个细节。第一，xTaskCreate的第三个参数是任务栈大小，单位是"字"（word），在 32 位的 Cortex-A9 上一个字是 4 字节，所以 512 字对应 2KB。第二，优先级数值越大优先级越高，FreeRTOS 的语义是数字大优先，这和很多其他 RTOS 相反。第三，vTaskStartScheduler()只有在创建 Idle 任务和启动第一次上下文切换失败时才会返回，所以它后面的 while(1) 实际上是一个错误兜底，正常不会执行到。

4.4 理解上下文切换的中断实现：SWI、GIC 与 tick 的协同

不要跳过这一小节，因为在 Zynq 上排查调度的疑难杂症时，你迟早要回到这里。

Xilinx 给 Zynq 的 FreeRTOS 移植里，上下文切换的触发机制依赖 ARM 的软件中断（SWI），而不是常见的 PendSV。具体来说，portYIELD宏会触发一个 SWI 异常，在异常处理函数中完成当前任务上下文的保存和下一个任务的恢复。tick 时基则来自 Cortex-A9 的处理器私有定时器，它通过 GIC 的 PPI 中断送入 FreeRTOS 的心跳处理函数。

GIC 在这里扮演的是中断总线的角色。无论哪个中断源，最终都要通过 GIC 分发到 ARM 核。FreeRTOS 在启动时对 GIC 做了初始化，并且通过configMAX_SYSCALL_INTERRUPT_PRIORITY划定了"可以调用 FromISR 系列 API 的中断优先级"和"只能做快速现场处理的中断优先级"之间的分界线。这个宏非常关键：如果你在超过这个优先级的中断服务函数里调用了xQueueSendFromISR，就可能破坏 FreeRTOS 内部的临界区保护，导致不可预期的崩溃。

实际排查中，我见过一个典型故障：PL 侧自定义 IP 产生的中断优先级被配置得比 FreeRTOS 票准优先级还高，然后在 ISR 里调用了队列 API，结果系统运行几分钟后随机死机。后来把优先级调整到允许范围内，问题立刻消失。所以不要随意修改 BSP 生成的 GIC 优先级分组和 FreeRTOS 中断屏蔽宏，除非你清楚自己在干什么。

5. 多任务划分与 PS/PL 协同的中断设计

5.1 怎么划分任务才算合理

任务不是越多越好。工程化平台的一个常见错误是"一个功能一个任务"，最后任务数量爆炸，上下文切换开销占掉不少 CPU 资源，还增加了调试难度。合理的任务划分遵循三个原则：按实时性划分、按阻塞点划分、按变化频率划分。

按实时性划分的意思是，控制回路、紧急事件响应这类有严格时限逻辑的要独立成高优先级任务；数据采集和处理如果依赖 PL 中断，也要单独成一个中优先级任务；而 UDP 发包、串口调试、状态显示这类可以容忍延迟的，放在低优先级任务里即可。

按阻塞点划分的核心是"不能让一个任务卡住整个系统"。比如网络协议栈本身就含有阻塞等待（等接收、等发送），把它放进一个阻塞任务里，其余任务照常运行，这正是 RTOS 相对裸机最大的优势。

我在这套平台上实际使用的任务划分如下，供参考：

这个任务表的核心是 pl_event_task 用最高优先级，因为 PL 侧的中断事件一旦发生，需要尽快处理，否则 FIFO 可能溢出丢数据。ctrl_task 紧跟其后，保证控制周期不因网络任务而抖动。UDP 任务虽然优先级不高，但它内部有 lwIP 的阻塞等待，并不会在空闲时白白消耗 CPU。

5.2 PL 中断进入 FreeRTOS 的完整路径

Zynq 的 PL 侧用户逻辑可以通过 IRQ_F2P 通道向 PS 侧 GIC 发送中断请求。每个 PL IP 的中断号，在 Vitis 生成的头文件里有对应的宏，比如XPAR_FABRIC_AXI_GPIO_0_IP2INTC_IRPT_INTR。不要死记硬背中断号数字，一律使用生成的宏。

中断服务的注册和使能流程如下：

#include "xscugic.h" #include "xil_exception.h" static XScuGic g_gic; static void pl_isr(void *arg) { BaseType_t xHigherPriorityTaskWoken = pdFALSE; uint32_t len; /* 从 PL 侧寄存器读取本次数据长度 */ len = *(volatile uint32_t *)PL_SAMPLE_LEN_REG; /* 关键：读取 PL 写入 DDR 的数据前，失效 PS 侧 cache */ Xil_DCacheInvalidateRange((UINTPTR)PL_SAMPLE_BUFF_BASE, len); /* 把数据长度放入队列，由 pl_event_task 接收处理 */ xQueueSendFromISR(sample_queue, &len, &xHigherPriorityTaskWoken); /* 如果唤醒的任务优先级高于当前任务，立即切换 */ portYIELD_FROM_ISR(xHigherPriorityTaskWoken); } int setup_pl_interrupt(void) { int status; status = XScuGic_CfgInitialize(&g_gic, &g_gic_config, g_gic_config.CpuBaseAddress); if (status != XST_SUCCESS) return status; Xil_ExceptionRegisterHandler(XIL_EXCEPTION_ID_INT, (Xil_ExceptionHandler)XScuGic_InterruptHandler, &g_gic); status = XScuGic_Connect(&g_gic, XPAR_FABRIC_AXI_GPIO_0_IP2INTC_IRPT_INTR, (Xil_InterruptHandler)pl_isr, NULL); if (status != XST_SUCCESS) return status; XScuGic_Enable(&g_gic, XPAR_FABRIC_AXI_GPIO_0_IP2INTC_IRPT_INTR); Xil_ExceptionEnable(); return XST_SUCCESS; }

这里有一个很多新手会忽略的重点：ISR 里不要做耗时操作，只做"搬数据 + 发通知"。数据解析和业务处理放到 pl_event_task 里做，这样既保证了中断响应足够快，又不会因为长时间关闭中断而影响其他模块。这也是 FreeRTOS 里 FromISR 系列 API 存在的意义：因为 ISR 执行期间调度器不会做上下文切换，为了让更高优先级的任务能及时被唤醒，portYIELD_FROM_ISR会在中断返回前触发一次上下文切换检查。

5.3 共享内存与 Cache 一致性：PS/PL 协同最容易踩的深坑

PS 和 PL 共享数据通常有两种方式：一是通过 AXI GPIO 等 IP 做寄存器级小数据交互，二是通过 AXI HP 口或 AXI BRAM 把 DDR 或 BRAM 作为数据缓冲区。寄存器级交互不需要考虑 cache，但大数据量共享必须处理 cache 一致性问题，否则你会看到"数据时对时错""第一次读对了第二次读的是旧值"这种诡异现象。

Cortex-A9 的 PS 侧 L1/L2 cache 对 PS 是透明的，但 PL 侧的 DMA 或者其他 AXI 主机绕过 CPU 直接读写 DDR 时，PS 侧 cache 里可能存着旧数据。解决思路就两条：PL 写、PS 读时，PS 要 invalidate；PS 写、PL 读时，PS 要先 flush。对应 Xilinx 的 API 是：

Xil_DCacheInvalidateRange((UINTPTR)src, len); // PL 写完数据，PS 读之前调用 Xil_DCacheFlushRange((UINTPTR)src, len); // PS 写完数据，PL 读之前调用

每次共享数据访问都加上这一对操作之后，再配合 PL 侧的中断通知，PS/PL 的数据通路才算真正可靠。这里还建议在共享内存区域的头部放一个 magic number 和数据长度字段，PL 每次写入时更新，PS 读取前先校验 magic number，能有效避免因为 PL 侧逻辑未复位导致读到全 0 或全 F 的脏数据。

6. 实战中的坑：启动、调度、内存问题排查实录

6.1 上电启动阶段的烦心事

加入调度器之后最吓人的故障莫过于"上电后串口没一点输出"。遇到这种情况，先不要打开调试器看 app，先用排除法确认启动链路停在哪个阶段。判断依据如下：

• 如果连 FSBL 的 banner 都没有，问题在 BootROM 加载阶段，优先检查启动模式引脚和镜像是否烧写成功。
• 如果 FSBL 打印正常、板子也加载了 bitstream，但 app 没有任何输出，可能是 app 本身没跑起来，或者跑起来了但串口驱动初始化失败。
• 如果发现 app 卡死在某个外设驱动的初始化里，而在裸机程序里相同的初始化是正常的，那就要检查是不是初始化顺序或配置被 FreeRTOS 的代码覆盖了。

我碰到过一个很典型的 case：裸机 app 一切正常，迁移到 FreeRTOS 后串口只有 boot 打印，app 阶段完全沉默。查到最后发现是 BSP 里 FreeRTOS 的堆定义和 lwIP 的 DMA 缓冲区定义在链接脚本里使用了同一段 DDR 地址，app 启动后被堆分配覆盖了 DMA 描述符，导致外设挂掉。排查这种问题，建议把 app 的链接脚本和 FreeRTOS 堆地址打印出来逐个核对，别依赖"看起来没问题"。

6.2 跑起来之后调度异常：优先级、堆栈、临界区

系统能跑起来只是第一步，任务切换不正常才是真正的考验。我把实际项目中遇到的高频故障整理成一张速查表，遇到可参照排查：

关于优先级反转，FreeRTOS 的互斥量自带优先级继承机制，但注意只有使用xSemaphoreCreateMutex创建的互斥量才具备该能力，使用二值信号量则没有。工程化场景下，如果多个任务要访问同一个 SPI 或 I2C 总线，强烈建议用互斥量而不是二进制信号量。

6.3 排查工具与手段：示波器、Trace 宏、断言一个都不能少

RTOS 排查比裸机更需要工具思维。我常用的三种手段：

第一，给 tick hook 挂一个短的 GPIO 翻转逻辑，用示波器看系统的心跳是否稳定。如果 tick 波形出现长时间停顿，那说明有中断被长时间屏蔽，或者高优先级任务持续霸占 CPU。这个动作 10 分钟就能做出来，对定位死机问题极有帮助。

第二，使用 FreeRTOS 的 trace 功能。在FreeRTOSConfig.h里开启configUSE_TRACE_FACILITY，然后定时调用vTaskList或uxTaskGetSystemState，可以输出每个任务的状态、优先级和栈高水位线。我一般在调试阶段用一个串口调试命令，周期打印任务列表，直接在终端观察哪个任务"饿死"了或者栈快满了。

第三，不要小看configASSERT。Xilinx BSP 默认的 assert 可能只是停在那里打一行字，你要把它改成一个可观测的行为，比如点红灯加死循环，然后在串口里打印出错文件行号。这只花 15 分钟配置，却能让你在"莫名其妙的复位"时第一时间看到 FreeRTOS 在哪个 API 上崩了。

7. 调度器加入之后的工程化体会

按前面步骤把 FreeRTOS 接入 Zynq-7000 平台之后，一个最直观的变化是：往系统里加新功能，不再需要重新编排所有任务的时序了。UDP 通信、PL 数据采集、控制闭环、状态显示各自住在一个"房间"里，按优先级排队使用 CPU，整体系统的响应确定性比裸机时代好了不止一个档次。

我个人的体会是：调度器的引入不是终点，而是一个新的起点。你会发现接下来的问题不再是"主循环怎么写"，而是"任务之间怎么通信""共享资源怎么保护""中断响应怎么设计"。这些才是嵌入式系统真正值钱的部分。而这一步一旦走通，下次你再遇到带 RTOS 的新项目，启动和适配就会很快进入状态。

最后分享一个小技巧：在 main 函数里把vTaskStartScheduler()之前的所有初始化都封装成一个pre_scheduler_init()，并在里面打印每个阶段的状态码。如果调度器之后出现任何运行期问题，你随时可以通过这个打印确认"硬件、PL、驱动"三条线在启动时都是好的。这个习惯让我们的平台从调试状态平滑过渡到现场运行状态，希望你也能用得上。