企业官网建设流程全解析

直接在 Proteus 里跑 FreeRTOS，这个需求在我后台被问了一整年。很多人手里没有开发板，或者板子吃灰了，但是想接触多任务调度、队列、信号量这些 RTOS 玩法，又不想一上来就啃源码。我自己的结论是：用 Proteus 8.9 配合 STM32CubeMX 生成的 HAL 库工程，直接跑 FreeRTOS，不仅可行，而且很适合做验证，尤其是课程设计、毕业设计前想“先跑通再画板”的场景。这篇文章就把我自己踩过的坑、验证过的流程、常用的配置参数全部梳理一遍，跟着做基本能复现一个带串口日志和任务调度的 FreeRTOS 仿真项目。

1. 仿真方案整体拆解：Proteus 跑的不是 RTOS，而是固件

1.1 明确仿真的本质：CPU 级执行 hex

很多人第一次听到“Proteus 仿真 FreeRTOS”会觉得不理解，以为要装什么插件或者要往 Proteus 里塞 RTOS 源码。实际上不需要。Proteus 对 STM32 的仿真，本质上是做了一个 Cortex-M3 内核的指令级模拟，你给它的是编译生成的 hex 文件，它就在虚拟 CPU 上逐条执行里面的指令。

FreeRTOS 作为软件库，在编译阶段已经链接进了你的工程，最终全部逻辑都变成了 hex 里的机器码。Proteus 不需要知道什么是任务控制块，也不需要理解调度器，它只要把每一条指令、每一次中断响应模拟对，你程序里的调度逻辑就会自然跑起来。

这就带来一个好处：只要你的代码能在 Keil 里正常编译并产生 hex，不管代码用了 HAL 库、标准库还是寄存器操作，Proteus 都一视同仁。而 CubeMX 默认生成的就是 HAL 库工程，所以我们直接基于 HAL 库来做，没有任何额外负担。

1.2 这个仿真能验证什么，不能验证什么

我在实际使用中觉得，这套方案最适合验证的是 RTOS 的逻辑层内容，包括：

• 多任务的创建、启动、删除
• 抢占式调度下高优先级任务对低优先级任务的影响
• 时间片轮转调度的宏观表现
• 队列、二值信号量、互斥量、事件组这些 IPC 机制
• 软件定时器的回调逻辑
• 任务栈大小是否合理

但有几个方面必须说清楚，Proteus 毕竟不是真实芯片，它的仿真速度远慢于真实硬件，而且它对外设的建模是偏功能级别的。FreeRTOS 的实时性能、中断响应延迟、任务切换耗时这些硬指标，在仿真里没有任何参考意义。还有，Proteus 里面所有引脚时序都是虚拟出来的，不能用来验证 GPIO 翻转速度、PWM 脉宽精度、ADC 采样率这类依赖硬件特性的东西。

所以我的建议是：用 Proteus 学调度逻辑、验证多任务功能、跑通协议通信，非常合适；但想测 RTOS 的实时性能、做产品级的可靠性验证，还是得回到真实板子上。

1.3 我推荐的工程结构

做 STM32 的 FreeRTOS 仿真，软件栈我建议是这样组合：

• STM32CubeMX：负责芯片初始化、时钟配置、外设配置，以及 FreeRTOS 的集成
• Keil MDK：负责编译和加载 hex
• Proteus 8.9：负责运行仿真、提供虚拟终端和虚拟示波器这些调试工具

这三件事各管一块，互不干扰。CubeMX 生成工程时会把 FreeRTOS 的源码直接放进 Middlewares 目录，Keil 会根据配置自动编译这些源码，最终生成的 hex 再丢给 Proteus。整个过程不需要手动移植任何 RTOS 文件，所以哪怕你对 FreeRTOS 源码的目录结构还不熟，也能先把工程跑起来。

2. 环境准备：CubeMX、Proteus、Keil 三方配合的关键细节

2.1 版本选择与第一个大坑：时钟源不匹配

我用的组合是 Proteus 8.9 SP2、STM32CubeMX 6.5 以上、Keil MDK 5.37 左右，配合 STM32Cube FW_F1 1.8.x 的固件包。这套组合我验证过多次，稳定性没问题。

最容易被忽略的是时钟源配置。CubeMX 新建工程时，如果 RCC 选了 HSE 外部晶振作为时钟源，那么 Proteus 电路里必须加上一个 8MHz 的晶振，并接好两个 20pF 左右的负载电容。否则仿真运行之后，程序容易卡死或者串口波特率完全不对。

反过来，如果你不想在 Proteus 里画晶振，那 CubeMX 里 RCC 就要改成 HSI 内部时钟，并在 Clock Configuration 里把 PLL 源切到 HSI，确保系统时钟源和 Proteus 中的模型一致。这个“时钟一致性”是整个仿真方案的大前提，因为 HAL_Init 和 FreeRTOS 的 SysTick 配置都会用到 SystemCoreClock，如果实际仿真环境和代码里算出来的时钟频率不一致，后面所有依赖时间的东西全部会乱套。

我自己的习惯是：在 CubeMX 里用 HSE 8MHz，Proteus 里老老实实放一个晶振。理由很简单，这是最贴近真实开发板的接法，后面如果你想移植到真实硬件，不需要再改代码。

2.2 CubeMX 里 FreeRTOS 的关键配置参数

在 CubeMX 的中间件选项中启用 FreeRTOS 后，有几个配置项会直接决定仿真能否跑起来：

• 接口选择：建议选 CMSIS_V2，因为它对应的是新版 FreeRTOS 内核，任务创建、队列操作的 API 封装更现代。
• Kernel 设置里的USE_PREEMPTION：保持启用，这正是抢占式调度的开关。
• TICK_RATE_HZ：填 1000，即 1ms 一个 tick，这是最常见的配置，串口日志里的时间戳也是以这个为基准。
• MINIMAL_STACK_SIZE：默认值经常是 128，单位是字（word），不是字节。Cortex-M3 上一个字是 4 字节，所以 128 字是 512 字节，这个空间只够跑简单的任务。如果任务里调用了 printf 或者有较大的局部变量，务必加大到 256 甚至 512。
• TOTAL_HEAP_SIZE：默认值如果是 4096，就直接改到 8192 以上。Cortex-M3 的 SRAM 有 20KB（F103C8），堆太小时创建任务都可能失败。

还有一个必须手工确认的地方：SYS 这个外设里的 Timebase Source。启用 FreeRTOS 后，必须把 HAL 库的时基从 SysTick 切换到其他定时器，比如 TIM6 或者 TIM7。原因很简单，FreeRTOS 的 tick 依赖 SysTick，如果 HAL 库还占用 SysTick，两套系统会打架，轻则延时混乱，重则直接在 vTaskDelay 里死循环。CubeMX 其实会自动处理这个切换，但你在生成代码后依然要去检查一下，确认生成的工程里包含了 stm32f1xx_hal_timebase_tim.c 这个文件，而且 SYS 的 Timebase Source 确实是 TIM6 或 TIM7。

2.3 Proteus 电路搭建和固件加载

Proteus 这边的电路非常简单，核心元件就是一个 STM32F103C8 芯片模型。搜索“STM32F103C8”就能找到。需要连接的信号包括：

• 8MHz 晶振从 OSC_IN 和 OSC_OUT 接入，两个引脚分别对地接 20pF 电容
• NRST 复位脚接一个 10k 上拉电阻到 VDD，这是为了保证复位逻辑明确
• VDD 和 VDDA 接 3.3V，VSS 和 VSSA 接地
• LED1 接 PA1 引脚，LED2 接 PA2 引脚，LED 另一端串联一个 330 欧姆或 1k 欧姆电阻到地
• 虚拟终端（Virtual Terminal）的 RXD 引脚接 STM32 的 PA9（USART1_TX），虚拟终端的 GND 要和仿真地共地

双击 STM32 芯片打开属性窗口，在 Program File 一栏选到你 Keil 生成的 hex 文件。另外需要关注一下 CKS 属性，如果里面可以直接选时钟源，确保它和你的 CubeMX 配置一致，选 HSE 或者外部时钟。

虚拟终端这个东西非常重要，调试 FreeRTOS 任务状态时，它就是你的“串口助手”。我一般会设置波特率 115200，8 位数据，无校验，1 位停止位，和 CubeMX 里 USART1 的配置保持一致。

2.4 Keil 端的两个必须设置

在 Keil 里打开 CubeMX 生成的工程后，有两处设置我不止一次忘记改，导致仿真失败，这里直接写出来：

• Options for Target -> Output -> 勾选 Create HEX File。不勾选的话，Keil 只生成 axf 文件，Proteus 加载不了。
• Options for Target -> Target -> 勾选 Use MicroLIB。printf 重定向串口输出时，MicroLIB 的 printf 实现体积小很多，栈占用也少。如果不用 MicroLIB，printf 可能会把任务栈瞬间吃光。

这两个设置不复杂，但缺一个就白搭。

3. 代码实现：多任务调度加队列通信的核心逻辑

3.1 先理解 FreeRTOS 任务的基本属性

在写代码之前，我先把 FreeRTOS 任务最重要的几个属性用大白话講一遍。每个任务本质上就是一个无限循环的 C 函数，函数的签名必须是void task(void *argument)。这个函数不能返回，一旦执行完，任务就挂了。任务的栈空间大小用usStackDepth参数指定，单位是 word。优先级数字越大优先级越高，这和很多操作系统正好反过来。

任务创建之后会进入就绪态，由调度器根据优先级决定谁运行。如果两个任务优先级相同，RTOS 会在每个 tick 之后做时间片轮转，让两个任务交替运行。高优先级任务只要没有被阻塞，就会一直占据 CPU，低优先级任务永远没机会执行。这就是抢占式调度的核心。理解这一点，很多仿真里“只有一个任务在跑”的问题就很容易排查了。

3.2 创建任务和启动调度器的方式

在 CubeMX 生成的工程里，FreeRTOS 的启动代码框架已经搭好了。main 函数会先做所有外设的 HAL 初始化，然后调用 MX_FREERTOS_Init。这个函数内部会做三件事：调用 osKernelInitialize 初始化内核，创建默认任务，调用 osKernelStart 启动调度器。

我通常会在 MX_FREERTOS_Init 的这个位置，额外加入自己写的 App_TaskCreate 函数，把自定义的几个任务都创建出来。示例如下：

/* freertos.c 中 MX_FREERTOS_Init 内部片段 */ void MX_FREERTOS_Init(void) { osKernelInitialize(); /* 自定义任务创建 */ App_TaskCreate(); /* 默认任务 */ defaultTaskHandle = osThreadNew(StartDefaultTask, NULL, &defaultTask_attributes); osKernelStart(); }

App_TaskCreate 内部直接用 FreeRTOS 原生 API 创建任务：

void App_TaskCreate(void) { xTaskCreate(Task_LED1, "LED1", 128, NULL, 1, NULL); xTaskCreate(Task_LED2, "LED2", 128, NULL, 1, NULL); xTaskCreate(Task_EventProducer, "Producer", 128, NULL, 2, NULL); }

需要特别提醒的是，任务名“LED1”“LED2”会用于调试和任务列表打印，不能重复，也不能超过 configMAX_TASK_NAME_LEN 定义的长度，默认是 16 个字符。优先级 1 和 2 的区别在后面会直接体现在仿真现象上。

3.3 任务函数与 vTaskDelay 的使用

第一个任务负责让 LED1 每隔 500ms 翻转一次。这里有一个关键点：任务里的延时必须用 vTaskDelay，不要用 HAL_Delay。

原因很简单，vTaskDelay 会让当前任务进入阻塞态，把 CPU 让给其他任务，这是多任务调度的基本语义。而 HAL_Delay 本质上是忙等待，会一直占用 CPU，哪怕内部有时基中断，也不会触发任务切换。只要你在一处用了 HAL_Delay，低优先级任务基本就会被饿死。

void Task_LED1(void *argument) { for (;;) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_1); vTaskDelay(pdMS_TO_TICKS(500)); } }

pdMS_TO_TICKS 宏会把毫秒转换成 tick 数，前提是 configTICK_RATE_HZ 是 1000，这样 500ms 正好是 500 个 tick。

第二个任务我设计成 LED2 等待队列消息。为了让演示效果更直观，还加了一个 Producer 任务，优先级设为 2，每 3 秒往队列里发一条消息。LED2 收到消息后翻转一下，同时通过串口打印一条日志。这样能清楚看到优先级更高的 Producer 任务是否可以按周期抢占运行，以及队列是否能把数据正确传递到 LED2 任务。

QueueHandle_t xEventQueue; void Task_EventProducer(void *argument) { uint8_t msg = 1; for (;;) { vTaskDelay(pdMS_TO_TICKS(3000)); xQueueSend(xEventQueue, &msg, 0); } } void Task_LED2(void *argument) { uint8_t rxMsg; for (;;) { if (xQueueReceive(xEventQueue, &rxMsg, portMAX_DELAY) == pdTRUE) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_2); printf("[Queue] get msg=%d\r\n", rxMsg); } } }

在 main 初始化或者 App 初始化里，要先创建队列：

xEventQueue = xQueueCreate(4, sizeof(uint8_t));

xQueueCreate 的第一个参数是队列深度，第二个参数是单个消息的字节数。这里队里最多缓存 4 条消息，每条消息一个字节。

3.4 printf 重定向到串口

任务里的 printf 需要重定向到 USART1 才能出现在虚拟终端上。CubeMX 生成的串口句柄默认叫 huart1，所以重定向代码如下：

#include <stdio.h> int fputc(int ch, FILE *f) { HAL_UART_Transmit(&huart1, (uint8_t *)&ch, 1, 0xFFFF); return ch; }

重定向之后，printf 输出的内容会直接通过串口发送。Proteus 的虚拟终端收到的就是这些字符。要注意的是，如果多个任务同时使用 printf，可能会造成字符交叉，这是正常现象。实际项目中通常会加一个互斥量保护串口，但在仿真验证阶段我很少这么干，毕竟问题本来就不起决定作用。

3.5 怎么直观观察任务调度

我在仿真里最常用的观察手段有三个。第一是看两个 LED 的闪烁节奏，频率不同就说明多个任务在交替执行。第二是看虚拟终端的打印日志，配合每次打印前加一个 HAL_GetTick 或者任务计数，能非常清晰地看到时间线。第三是用 FreeRTOS 自带的任务状态查询函数，在某个任务里定期打印所有任务的状态。

要打印任务状态，需要在 FreeRTOSConfig.h 中打开两个宏：

#define configUSE_TRACE_FACILITY 1 #define configUSE_STATS_FORMATTING_FUNCTIONS 1

然后调用 vTaskList，把任务信息格式化到字符串里：

void Task_StatusDump(void *argument) { char buffer[512]; for (;;) { vTaskDelay(pdMS_TO_TICKS(5000)); vTaskList(buffer); printf("%s\r\n", buffer); } }

输出表格里会有任务名、状态、优先级、栈剩余量等信息。状态一列会列出 Ready、Blocked、Suspended 等，看到这些值基本就能理解调度器在某一时刻是怎么选择任务的。

3.6 为什么在任务里不要使用 HAL_Delay

我在这里单独展开说这个点，是因为它太容易踩了。CubeMX 默认生成的大量底层外设代码都会调用 HAL_Delay，比如 I2C、SPI 在一些错误处理时会用。如果在 FreeRTOS 多任务环境中，一个任务调用了 HAL_Delay，它是基于 TIM6 时基的忙等待，其他任务无法趁机运行，整个系统看起来就像死机了一样，但 LED 自己的翻转其实还在进行，只是大量 CPU 时间被白白浪费了。

真正正确的做法是：应用代码中所有需要延时的场合，都用 vTaskDelay 或者 vTaskDelayUntil。vTaskDelayUntil 更适合做固定周期的循环，因为它在计算延时目标时不受任务自身执行时间影响。比如 LED1 的这个任务，用 vTaskDelayUntil 可以做到非常稳定的 500ms 周期翻转：

TickType_t xLastWakeTime = xTaskGetTickCount(); for (;;) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_1); vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(500)); }

4. 仿真运行中的高频问题与排查技巧

4.1 程序卡死在 HardFault_Handler

这个问题排在所有 FreeRTOS 仿真问题的第一名。典型的现象是点击运行后，虚拟终端没有任何输出，LED 不闪，代码停止在 HardFault_Handler 的 while 死循环里。

常见原因有四个。第一，任务栈溢出，尤其使用 printf 时容易触发；第二，SysTick 的中断优先级设置不正确，FreeRTOS 对 kernel 中断优先级有严格要求；第三，某个任务访问了非法地址，比如数组越界或者野指针；第四，队列或者信号量句柄在创建前就被使用。

排查方法我建议按照顺序来：先检查任务栈大小，把涉及 printf 的任务栈开到 256 甚至 512；再确认 FreeRTOSConfig.h 中 configASSERT 是否打开，打开后如果有优先级或互斥调用问题，程序会卡在 configASSERT 指向的具体位置，比 HardFault 容易定位得多。最后把默认任务里的逻辑精简，只保留最简单的点灯代码，确认是任务代码问题还是框架问题。

4.2 两个任务里只有一个在跑

这个现象非常典型，而且原因很清楚。如果你启动了多个任务但只有一个 LED 在闪，另一个完全不动，先检查你的任务里是不是用了 HAL_Delay。如果用了，换成 vTaskDelay。如果没有，检查两个任务的优先级。高优先级任务如果没有阻塞点，比如一个任务里是空空的 for 循环没有任何延时，它就永远不会让出 CPU，低优先级任务就一直处于 Ready 状态但得不到执行。

还有一种情况是任务创建失败了，xTaskCreate 返回的不是 pdPASS。这通常是因为堆内存不足。把 TOTAL_HEAP_SIZE 调大，然后重新生成代码再编译，基本上能解决。在仿真的早期阶段，我习惯把每个任务的栈空间都开得大一点，宁多勿少，跑通之后再慢慢缩。

4.3 串口没输出或者乱码

串口如果完全没输出，先检查虚拟终端的接线。VTERM 的 RXD 必须连接 STM32 的 TX，也就是 PA9。接反了肯定没输出。然后检查波特率，虚拟终端右下角设置的波特率必须和 CubeMX 里 USART1 配置一样。

如果是乱码或者输出了一堆不可见字符，十有八九是时钟配置和 Proteus 仿真环境不一致。CubeMX 里用的是 HSE 8MHz，Proteus 电路里却没放晶振，或者换成了别的频率，这样 USART 波特率计算必然出错。另外还有一个隐蔽坑，就是用了 HSI 做系统时钟，但串口参数里 Configure 时误以为时钟是 72MHz，实际上 HSI 模式很难跑到 72MHz，建议工程里统一用 HSE 加 72MHz PLL，别在仿真阶段折腾 HSI。

4.4 仿真速度慢得像蜗牛

Proteus 上的 STM32 仿真本来就比真实芯片慢不少，FreeRTOS 的调度又引入了额外的上下文切换开销，所以仿真速度慢很正常。如果感觉慢到没法看，可以优化一点。第一，关掉 Proteus 的动画效果，把 Animation Options 里的实时帧率调到最低，减少图形渲染的工作量；第二，减少串口打印内容，打印越是频繁，仿真越慢；第三，LED 翻转和定时器周期不要太短，尽量用 500ms 甚至 1000ms 级别的延时，否则每个仿真步进都在大量中断，慢得更明显。

我实测下来，虚拟终端每秒钟打印 2 到 3 行日志，整套仿真在普通电脑上还是能流畅观察的，再多就有点卡了。

4.5 Keil 编译报错 q0147e 无法创建目录

这个问题可能不少新人会遇到，报错信息类似这样：

.\obj\freertos.hex: error: q0147e: failed to create directory .\obj\freertos

实际上 Keil 试图在工程目录下创建 obj 文件夹，但目录不存在或者用户的写权限不足，或者该路径下的 obj 是一个已经存在的同名文件而非文件夹，都会触发这个错误。解决办法很简单：在 Options for Target -> Output -> Select Folder for Objects 里，手动把输出目录改成一个已经存在且可写的路径，比如工程目录下的 Output 文件夹，然后重新编译。这种报错经常出现在你改了工程名、移动了工程文件夹之后，路径一旦变化，旧配置就会失效。

4.6 修改 CubeMX 参数后 Proteus 里还是老行为

这是很多新手容易犯的失误。CubeMX 生成新代码后，Keil 并不会自动重新编译 hex，Proteus 里加载的仍然是旧 hex。我一般会养成一个习惯：每次修改 CubeMX 配置后，在 Keil 里 Clean 一下再重新 Build，同时确认工程输出路径下 hex 文件的修改时间是最新的。

另一个相关的问题是，Keil 虽然编译成功，但生成的 hex 路径和 Proteus 里配置的路径不一致。比如 CubeMX 生成工程时默认输出到 Debug 或者 Release 目录，而你后来手动改了 Output 目录，Proteus 还指向旧路径，那仿真跑的就是一个非常老的固件。最好的办法是每次仿真前手动确认 Proteus 里 Program File 的路径，别只看文件存在就投放。

5. 如何用这套仿真更深入理解 RTOS 行为

5.1 用任务挂起和恢复模拟事件触发

仿真的价值不只是验证代码能跑，还在于可以主动构造各种事件来观察调度器行为。FreeRTOS 里最常用的控制接口是 vTaskSuspend 和 vTaskResume。我做过一个例子：默认情况下 LED2 任务处于挂起状态，并不执行，串口收到一个指定字符后，调用 vTaskResume 唤醒 LED2，然后 LED2 才开始闪烁。

这个实验能直观地展示任务状态迁移，比干看书上的状态图有用得多。如果你让串口输入由虚拟终端的键盘发送，甚至可以实现“键盘按键控制任务”的交互效果。在课程设计答辩时，这种可视化演示很容易讲清楚。

5.2 利用软件定时器做周期任务

除了任务，FreeRTOS 还有软件定时器机制。软件定时器的回调是在定时器守护任务的上下文里执行的，不能调用阻塞型 API。我建议起码跑通一个简单例子：用 xTimerCreate 创建一个 2 秒周期的定时器，回调里翻转一个 LED。

void Timer_Callback(TimerHandle_t xTimer) { HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_1); } TimerHandle_t xTimer = xTimerCreate( "Timer", pdMS_TO_TICKS(2000), pdTRUE, NULL, Timer_Callback); xTimerStart(xTimer, 0);

跑通之后你会发现，软件定时器的回调周期和任务的优先级完全没有关系，它由独立的内核机制驱动。理解这个区别，对后面做实际项目很有帮助。

5.3 用 vTaskGetRunTimeStats 看 CPU 占用

如果你把configGENERATE_RUN_TIME_STATS打开，并提供一个高频计时时钟，就可以用 vTaskGetRunTimeStats 获取每个任务占用 CPU 的时间百分比。在 Proteus 里，这个计时源不太好搞，但可以用 SysTick 计数近似替代。跑出来的数据虽然不像真实板卡那么精确，但能让你直观感受到两个任务之间的 CPU 分配情况，加深对优先级和时间片轮转的理解。

5.4 进阶方向：加入 LCD 和外部传感器

Proteus 8.9 自带了 LCD 模型和一些常见的 I2C/SPI 传感器模型，如果把 FreeRTOS 的显示任务和传感器采集任务分开，可以做出一个具备完整业务逻辑的仿真项目。比如用 I2C 接口挂一个温湿度传感器，采集任务每隔 2 秒读一次数据，通过队列发送给显示任务，LCD 显示实验结果。这个过程里，你能真正体会到 RTOS 多任务通信在实际应用中的价值。

我自己在实际操作中的体会是，Proteus 里的 FreeRTOS 仿真最适合当做一个“教学沙盘”，它把抽象的调度过程变成了肉眼可见的 LED 闪烁和串口日志。当你亲眼看到两个 LED 以不同频率各自闪烁，再回到代码里分析优先级和 tick 配置，理解和记忆都会扎实很多。如果将来到了真实开发板，你只需要调整时钟和引脚配置，剩下 RTOS 这部分经验依然是通用的。