STM32 on Blog

RTOS 正传（一）：FreeRTOS 的目录、移植层和配置文件

Mon, 17 Aug 2026 15:52:00 +0800

RTOS 正传（一）：FreeRTOS 的目录、移植层和配置文件

上一篇把启动文件、链接脚本和 CMake 都搭好了，这一篇就是正传，开始把 FreeRTOS 搬进来。

学习 RTOS，注重适配层而不是内核，这一点很关键。这种大型开源项目，本来就是一个组织、一群人在维护，想把里面所有东西全部理解，本身就很困难。

当然，这不是说你不能成为贡献者。真想走这条路，也可以学阿酥在 Coding 那样一路混到大厂 Offer。但如果眼前只是想把 F407 上的系统跑起来，那就先把下面几个问题弄明白：

哪些 FreeRTOS 文件要编进工程？
F407 + GCC 应该选哪个端口？
堆实现到底选哪个？
FreeRTOSConfig.h 里一大堆宏，哪些真的要管？
哪些中断可以调用 xxxFromISR()？

这些问题先弄明白，系统就不再是“复制一个 Demo，能亮就算成功”的黑盒。

RTOS 到底适合什么场景

我们接下来就依照 FreeRTOS 来介绍。OS 本质上就是调度器，就是多任务处理，所以它明显更适合业务逻辑复杂、控制频率没到 us 级的场景，比如智能穿戴和飞控。

没错，我这里把飞控也算作低频率控制系统。一是因为它的数据处理很复杂，二是因为电调本身的控制频率也不高，PX4 就是跑在 NuttX 上的。

但你说我搞高精度伺服、工业电机驱动，上个 RTOS，这就不符合应用场景了。这是很关键的问题。

先把内核仓库拉下来

这次直接看官方的 FreeRTOS-Kernel 仓库。它只放内核源码、头文件和各种 CPU/编译器端口，比把 FreeRTOS-Plus、TCP、MQTT 全带上的聚合仓库清爽得多。

只学习当前版本的话，浅克隆就够了：

1
2


git clone --depth 1 --branch V11.3.0 \
 https://github.com/FreeRTOS/FreeRTOS-Kernel.git

官方文档在 www.freertos.org。内容肯定最全，但第一次打开确实像面对一本全英文词典：每个 API 都能查，问题是根本不知道应该先查哪个。

我还是那个观点，没有什么比上手更重要。应用本来就比原理简单，设计岗薪资更高这一点事实足以佐证。所以这篇不准备逐行做源码解析，只介绍文件作用、怎么裁剪，以及核心移植层是怎么做的。源码主要还得靠自己慢慢啃，工程先跑起来再说。

克隆下来为什么这么吓人

点开目录第一眼确实容易晕：一个 tasks.c 就有 8872 行，旁边还躺着一堆不认识的配置文件。别慌，真正要烧进 F407 的内容并没有这么多。

这个仓库里的东西大致分成四类：

tasks.c、queue.c、list.c 这些通用内核源码；
portable/ 下面针对不同 CPU 和编译器准备的移植代码；
include/ 里的公共 API 和内核头文件；
GitHub、合规、发布和文档文件。

后面不再给每个文件单独截一张图了。最好把仓库放在旁边，对着目录往下看，会比只看文章顺得多。

先分清自己站在哪一层

这里最关键的不是记文件名，而是先搞清楚自己现在扮演什么角色。

应用开发者主要使用 task.h、queue.h、semphr.h 这些 API，再根据业务配置 FreeRTOSConfig.h。任务怎么分、栈给多少、优先级怎么排，这些才是日常工作。

移植者要把内核接到具体 CPU 和工具链上。F407 已经有官方 ARM_CM4F 端口，我们只需要选对、编进来，再接好 SysTick、PendSV、SVC 和中断优先级，不用自己从零写上下文切换。

内核维护者才需要深挖 tasks.c、queue.c、list.c，研究就绪链表、阻塞链表、优先级继承和调度细节。

还有一类是仓库维护者。.github/、MISRA、SPDX、拼写检查这些文件主要服务于 FreeRTOS 项目本身。它们不是垃圾，只是不会进入我们的固件。

顶层目录先过一遍

把截图里的内容整理一下，大概就是这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


FreeRTOS-Kernel/
├── .github/ # CI、Issue/PR 模板、贡献规范
├── examples/ # CMake 示例和配置模板
├── include/ # 内核头文件
├── portable/ # CPU、编译器和堆的移植实现
├── tasks.c # 任务和调度器
├── queue.c # 队列、信号量、互斥锁
├── list.c # 内核链表
├── timers.c # 软件定时器
├── event_groups.c # 事件组
├── stream_buffer.c # Stream/Message Buffer
├── croutine.c # 旧式协程
├── CMakeLists.txt # 官方 CMake 入口
├── README.md # 仓库说明
├── History.txt # 版本历史
├── LICENSE.md # MIT 许可证
├── MISRA.md # MISRA 合规与偏离说明
├── manifest.yml # 发布元数据
├── cspell.config.yaml # 英文拼写检查
├── .gitattributes # Git 文件属性
├── .gitmodules # 第三方端口子模块
├── .git-blame-ignore-revs # blame 时忽略格式化提交
├── *SPDX2.3.spdx* # 多种格式的 SBOM
├── GitHub-FreeRTOS-Kernel-Home.url
└── Quick_Start_Guide.url # 网页快捷方式

看起来还是不少，但真正的内核主体其实就是根目录那几个 .c。

根目录的 7 个 `.c`

tasks.c 是调度器主体。任务创建、删除、延时、优先级、就绪与阻塞状态，最后都绕不开它。应用开发者先理解任务状态怎么变化就够了；真要维护内核，再进去研究各条链表怎么转。

queue.c 不只实现 Queue。Semaphore、Mutex、Recursive Mutex、Queue Set 也复用了它的队列结构。应用层最值得先搞懂的是阻塞超时和 Mutex 的优先级继承。

list.c 只有两百多行，却是内核调度的地基。就绪任务、延时任务、挂起任务都要挂到链表上。应用不会直接调用它，内核维护者则必须把它看明白。

上面三个是所有端口都要带的通用内核文件。剩下四个按功能看：

timers.c：软件定时器和 Timer Service Task；
event_groups.c：事件组；
stream_buffer.c：Stream Buffer 和 Message Buffer；
croutine.c：旧式协程，新项目基本不用。

官方 CMake 会把这 7 个文件都放进内核目标，再靠配置宏和链接器裁掉没启用的部分。所以这里说“按需使用”，不是让人刚入门就随手删源码。

`include/`：平时调用的 API 都在这儿

这个目录大部分是声明和宏，不是另一份内核实现。应用最常碰到的是：

1
2
3
4
5
6
7
8


FreeRTOS.h 总入口，读取 FreeRTOSConfig.h
task.h 任务、延时、通知、调度器 API
queue.h 队列和 Queue Set
semphr.h 信号量和互斥锁
timers.h 软件定时器
event_groups.h 事件组
stream_buffer.h Stream Buffer
message_buffer.h Message Buffer

下面这些就更偏内核和移植：

1
2
3
4
5


list.h 内核链表，应用不要直接依赖
portable.h 内核和端口层之间的接口
projdefs.h 通用类型、返回值和基础定义
stack_macros.h 栈溢出检查宏
atomic.h 原子操作宏

剩下的 mpu_*.h 是 MPU 端口用的，newlib-freertos.h、picolibc-freertos.h 负责 C 库适配；StackMacros.h 和 deprecated_definitions.h 主要照顾旧工程。现在知道它们大概在哪儿就行，不用每个都点开拜读。

应用层可以正常包含公共 API，但不要为了“适配板子”去改内核头文件。芯片和板级差异应该留在端口、中断入口和自己的 FreeRTOSConfig.h 里。

`portable/`：真正和芯片接上的地方

这个目录最大不是因为它最复杂，而是 FreeRTOS 要同时照顾 GCC、IAR、Keil，以及 Cortex-M、RISC-V、AVR、PIC 等一大群组合。基本规则就是：

1

portable/<编译器>/<CPU 架构>/

我们现在用的是 STM32F407VET6 + arm-none-eabi-gcc。F407 是带 FPU 的 Cortex-M4，所以选：

1
2
3


portable/GCC/ARM_CM4F/
├── port.c
└── portmacro.h

port.c 负责初始任务栈、启动第一个任务，以及 SysTick、PendSV、SVC 这些和上下文切换有关的东西。portmacro.h 则定义栈类型、字节对齐、临界区和任务切换宏。

其他 CPU 和编译器目录都不用编译。你不是在做一个全架构发行版，没必要把整个 portable/ 一锅端进工程。

portable/MemMang/ 下面还有 5 个堆实现：

heap_1.c：只能分配，不能释放，最简单；
heap_2.c：能释放但不合并相邻空闲块，新项目一般不选；
heap_3.c：包装 C 库的 malloc() 和 free()；
heap_4.c：能释放，也会合并空闲块，普通 MCU 工程最常用；
heap_5.c：能力类似 heap_4.c，但支持多个不连续内存区。

动态分配时只能选一个。这里先用 heap_4.c，别把五个一起编进去开会。

那些不会进固件的文件

根目录剩下的东西也简单过一下，免得每次看到都怀疑是不是漏编了：

.github/：CI、测试、PR 模板和贡献流程；
examples/：CMake 示例、Coverity/MISRA 示例和 FreeRTOSConfig.h 模板；
CMakeLists.txt：官方构建入口；
README.md、History.txt、LICENSE.md：说明、历史和许可证；
MISRA.md：MISRA C:2012 的合规范围和偏离理由；
manifest.yml：发布系统读取的版本和许可证信息；
cspell.config.yaml：英文拼写检查；
.gitattributes、.gitmodules、.git-blame-ignore-revs：Git 自己用的配置；
4 个 SPDX2.3 文件：同一份 SBOM 的文本、JSON、XML、YAML 版本；
两个 .url：官方主页和快速入门的网页快捷方式。

它们都不会被编译器变成 MCU 指令。想给 FreeRTOS 官方仓库提 PR 时再认真研究，现在知道不用塞进 F407 工程就够了。

F407 工程最后到底拿哪些

绕了一圈，真正需要的东西可以缩成这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


FreeRTOS-Kernel/
├── tasks.c
├── queue.c
├── list.c
├── timers.c # 开软件定时器时使用
├── event_groups.c # 开事件组时使用
├── stream_buffer.c # 开 Stream/Message Buffer 时使用
├── include/
└── portable/
 ├── GCC/ARM_CM4F/
 │ ├── port.c
 │ └── portmacro.h
 └── MemMang/heap_4.c

自己的工程/
└── FreeRTOSConfig.h

边界也就清楚了：内核维护者去深究 tasks.c + queue.c + list.c；做新端口的人研究 port.c、portmacro.h 和异常机制；我们现在主要负责选对 ARM_CM4F 端口，再把任务、内存和中断规则写进 FreeRTOSConfig.h。

这个配置文件不在内核根目录，因为它本来就属于具体应用。官方只在 examples/template_configuration/FreeRTOSConfig.h 放了一份模板。接下来就开始拆它。

`FreeRTOSConfig.h` 配置分类

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


FreeRTOSConfig.h
├── 1. 时钟与时间
├── 2. 调度器与任务
├── 3. 任务附加能力
├── 4. 任务通信与同步
├── 5. 软件定时器
├── 6. 内存、堆和任务栈
├── 7. 中断与临界区
├── 8. Hook 回调
├── 9. 故障检测、断言、调试统计
├── 10. C 库、POSIX 兼容
├── 11. 旧协程
├── 12. MPU、TrustZone、安全隔离
├── 13. 多核 SMP
└── 14. API 裁剪开关

先说好，这 14 类不是让你全背下来。第一版真能把人折磨疯的，其实就时钟、中断优先级、任务栈、堆和几个调试开关。剩下那些 MPU、TrustZone、多核，看见名字很高级，但和现在这颗 F407 没啥关系，先别给自己加戏。

我们还是一组一组过，不然后面报错了连该骂谁都不知道。

1. 时钟与时间

1
2
3
4
5


configCPU_CLOCK_HZ
configSYSTICK_CLOCK_HZ
configTICK_RATE_HZ
configTICK_TYPE_WIDTH_IN_BITS
configUSE_TICKLESS_IDLE

这组就是告诉 FreeRTOS：CPU 到底跑多快，一秒钟产生多少个 Tick。

最容易写错的是 configCPU_CLOCK_HZ。它填的是启动调度器时真正生效的 HCLK，不是芯片宣传页上的最高主频。假如时钟还没配，现在实际跑的是 16 MHz，那就老老实实填 16 MHz。你代码根本没切到 168 MHz，却在这里写个 168 MHz，后面的延时自然全是歪的。

configSYSTICK_CLOCK_HZ 只有在 SysTick 和 CPU 时钟不同源时才需要单独写。现在两边一样就别重复定义，省得以后改了一个忘了另一个。

configTICK_RATE_HZ 第一版用 1000 就行，也就是 1 Tick = 1 ms。写延时的时候别偷懒：

1

vTaskDelay(pdMS_TO_TICKS(10));

直接写 vTaskDelay(10) 看起来很爽，但哪天 Tick 频率一改，这个 10 就不一定还是 10 ms 了。

F407 用 32 位 Tick：

1

#define configTICK_TYPE_WIDTH_IN_BITS TICK_TYPE_WIDTH_32_BITS

configUSE_TICKLESS_IDLE 是低功耗用的，空闲时把周期 Tick 停掉。第一版先关，系统都还没跑稳就别急着省那点电。

2. 调度器与任务

1
2
3
4
5


#define configUSE_PREEMPTION 1
#define configUSE_TIME_SLICING 1
#define configMAX_PRIORITIES 5
#define configIDLE_SHOULD_YIELD 1
#define configUSE_PORT_OPTIMISED_TASK_SELECTION 1

configUSE_PREEMPTION = 1 就是抢占式调度。高优先级任务一旦就绪，不需要等低优先级任务自己良心发现让出 CPU，直接抢过来运行。

configUSE_TIME_SLICING = 1 是让同优先级任务轮流跑。两个任务优先级一样，又都不阻塞，那就每个 Tick 换一次。

configMAX_PRIORITIES 也不是越大越牛逼。第一版 5 级其实就够分了：控制、采样通信、普通业务、显示日志、Idle。你一上来开几十个优先级，最后只会得到一张自己都看不懂的任务关系网。

ARM_CM4F 可以打开 configUSE_PORT_OPTIMISED_TASK_SELECTION，让内核用 Cortex-M 的指令快速找最高优先级任务。不过开了以后 configMAX_PRIORITIES 不能超过 32，这点记住就行。

3. 任务附加能力

1
2
3
4
5


#define configMAX_TASK_NAME_LEN 16
#define configMINIMAL_STACK_SIZE 128
#define configTASK_NOTIFICATION_ARRAY_ENTRIES 1
#define configNUM_THREAD_LOCAL_STORAGE_POINTERS 0
#define configUSE_APPLICATION_TASK_TAG 0

任务名长度设 16，调试器里能看清名字就行。通知槽第一版一个也够用，线程局部指针和 Task Tag 暂时都关掉。

重点还是 configMINIMAL_STACK_SIZE。这个 128 不是 128 字节。ARM_CM4F 的 StackType_t 是 32 位，所以这里实际是：

1

128 word × 4 byte = 512 byte

而且它主要是 Idle Task 的栈大小，不代表所有任务都照着 128 抄。任务里要是有大数组、浮点计算、printf，栈很快就能给你吃干净。后面一定要看栈水位，不能凭感觉拍一个数字。

4. 任务通信与同步

1
2
3
4
5
6
7


#define configUSE_TASK_NOTIFICATIONS 1
#define configUSE_MUTEXES 1
#define configUSE_RECURSIVE_MUTEXES 0
#define configUSE_COUNTING_SEMAPHORES 1
#define configUSE_QUEUE_SETS 0
#define configUSE_EVENT_GROUPS 0
#define configUSE_STREAM_BUFFERS 0

这一组看着多，其实就是任务之间怎么说话。

Task Notification：一对一通知，快而且省内存，能用它就先用它。
Queue：真的有数据要传，比如传一帧传感器结构体，就用队列。
Semaphore：做事件同步或者资源计数。
Mutex：保护共享资源，它有优先级继承，不要拿二值信号量硬顶。
Event Group：用几个 bit 同时等多个事件。
Stream Buffer：连续字节流，串口接收这类场景比较常见。
Message Buffer：底层还是 Stream Buffer，但是会保留消息边界。

Queue、Semaphore、Mutex 都主要在 queue.c 里；Event Group 需要 event_groups.c；Stream 和 Message Buffer 需要 stream_buffer.c。

中断里又是另一套规矩，只能调用带 FromISR 的接口：

1
2
3
4


BaseType_t xHigherPriorityTaskWoken = pdFALSE;

vTaskNotifyGiveFromISR(xTaskHandle, &xHigherPriorityTaskWoken);
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);

最后这个 portYIELD_FROM_ISR() 不是装饰品。中断唤醒了更高优先级任务，就应该让它在退出中断后马上运行。

5. 软件定时器

1
2
3
4


configUSE_TIMERS
configTIMER_TASK_PRIORITY
configTIMER_TASK_STACK_DEPTH
configTIMER_QUEUE_LENGTH

软件定时器开启以后，FreeRTOS 会多创建一个 Timer Service Task。所有软件定时器到期，最终都是这个任务来执行回调。

所以它和硬件定时器完全不是一回事。回调不是在某个神秘的精准时刻凭空执行，它得排队，还会受 Timer Task 优先级和其他回调耗时影响。

第一版不用就直接：

1

#define configUSE_TIMERS 0

要用就把 timers.c 编进来，再配置任务优先级、栈和命令队列长度。回调里别延时，别疯狂打印，更别塞一大坨计算。一个回调卡住，后面的定时器全跟着排队。

6. 内存、堆和任务栈

1
2
3
4
5
6
7


#define configSUPPORT_STATIC_ALLOCATION 0
#define configSUPPORT_DYNAMIC_ALLOCATION 1
#define configTOTAL_HEAP_SIZE (32 * 1024)
#define configAPPLICATION_ALLOCATED_HEAP 0
#define configSTACK_ALLOCATION_FROM_SEPARATE_HEAP 0
#define configENABLE_HEAP_PROTECTOR 0
#define configHEAP_CLEAR_MEMORY_ON_FREE 0

这里先按 heap_4.c + 动态分配 来。heap_4.c 能释放，也会合并相邻空闲块，对这种普通 MCU 工程够用了。

configTOTAL_HEAP_SIZE 是 FreeRTOS 自己的堆，动态创建出来的任务栈、TCB、队列和信号量都从这里拿内存。它和链接脚本里的 C 库堆不是一回事，也不会自动接管普通 malloc()。

上面写 32 KB 只是一个起步例子，不是说所有工程都必须 32 KB。最后到底要多少，得把每个任务栈、队列长度、对象数量都算进去，再配合：

1
2
3


xPortGetFreeHeapSize();
xPortGetMinimumEverFreeHeapSize();
uxTaskGetStackHighWaterMark();

这里还有个经典坑：configTOTAL_HEAP_SIZE 的单位是字节，但是 xTaskCreate() 的栈深度在 ARM_CM4F 上通常是 32 位 word。两个数字放在一起很像，单位完全不一样。

configAPPLICATION_ALLOCATED_HEAP = 0 表示 ucHeap[] 还是由 heap_4.c 自己定义；设成 1 以后就得由应用提供。任务栈单独放进另一块内存、释放时清零、堆指针保护这些东西第一版也先关，真有对应需求再开。

静态分配以后再单独讲。它不是把开关改成 1 就结束了，Idle Task 的静态内存得自己提供；如果开了软件定时器，Timer Task 的内存也一样。

7. 中断与临界区

这一组真得认真看。前面那些东西配错，大不了功能不对；中断优先级配错，经常是平时能跑，一上负载就随机爆炸，最恶心。

STM32F407 有 4 个 NVIC 优先级位。这里按 4 位全部用于抢占优先级、不分子优先级来配：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


#define configPRIO_BITS 4
#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 15
#define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5

#define configKERNEL_INTERRUPT_PRIORITY \
 (configLIBRARY_LOWEST_INTERRUPT_PRIORITY << (8 - configPRIO_BITS))

#define configMAX_SYSCALL_INTERRUPT_PRIORITY \
 (configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY << (8 - configPRIO_BITS))

#define configCHECK_HANDLER_INSTALLATION 1

Cortex-M 的优先级数字越小，实际优先级反而越高，这个反人类设计先接受。

按上面这套配置：

1
2
3


优先级 0 ~ 4 不会被 FreeRTOS 临界区挡住，但禁止调用 FreeRTOS API
优先级 5 ~ 15 可以调用对应的 xxxFromISR() API
优先级 15 给 SysTick 和 PendSV，放到最低

configMAX_SYSCALL_INTERRUPT_PRIORITY 千万不能填 0。还有，CMSIS 里写的优先级 5 是没左移的逻辑值，FreeRTOS 这里要的是左移后写进寄存器的值。网上很多教程两个混着写，抄完还能跑只能说命硬。

configCHECK_HANDLER_INSTALLATION = 1 会检查 SVC 和 PendSV 有没有正确挂进向量表，但它依赖 configASSERT。这两个要一起开，不然新版内核会直接编译报错。

8. Hook 回调

1
2
3
4
5


#define configUSE_IDLE_HOOK 0
#define configUSE_TICK_HOOK 0
#define configUSE_MALLOC_FAILED_HOOK 1
#define configUSE_DAEMON_TASK_STARTUP_HOOK 0
#define configUSE_SB_COMPLETED_CALLBACK 0

Hook 就是 FreeRTOS 在几个固定时机回调你写的函数。

Idle Hook 会跟着 Idle Task 跑，Tick Hook 每个 Tick 都会进，而且是在中断上下文里。第一版都先关，尤其别在 Tick Hook 里打印日志，那是在给自己制造新问题。

但是 configUSE_MALLOC_FAILED_HOOK 我建议调试阶段直接打开：

1
2
3
4
5
6
7
8


void vApplicationMallocFailedHook(void)
{
 taskDISABLE_INTERRUPTS();

 for (;;)
 {
 }
}

内存分配失败以后停在这里，至少调试器能告诉你是堆没了。不开的话，错误可能继续往后传，最后在一个毫不相干的地方炸掉，到时候又要查半天。

9. 故障检测、断言与统计

1
2
3
4
5


#define configCHECK_FOR_STACK_OVERFLOW 2
#define configGENERATE_RUN_TIME_STATS 0
#define configUSE_TRACE_FACILITY 0
#define configUSE_STATS_FORMATTING_FUNCTIONS 0
#define configQUEUE_REGISTRY_SIZE 0

configCHECK_FOR_STACK_OVERFLOW = 2 会检查任务栈末尾的填充值有没有被踩。开了以后还要实现：

1

void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName);

然后是 configASSERT，调试阶段别关：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


#define configASSERT(x) \
 do \
 { \
 if ((x) == 0) \
 { \
 taskDISABLE_INTERRUPTS(); \
 for (;;) \
 { \
 } \
 } \
 } while (0)

FreeRTOS 很多错误不是靠返回一个 error 告诉你，而是靠断言把程序钉在现场。中断优先级配错、参数不合法、Handler 没挂好，都可能从这里抓出来。

运行时间统计、Trace、格式化任务列表先关。它们当然有用，但运行时间统计还需要额外的高频计数器，格式化函数又会把字符串处理带进来。先把系统跑起来，后面需要分析 CPU 占用时再开。

10. C 库与 POSIX 兼容

1
2
3


#define configUSE_NEWLIB_REENTRANT 0
#define configUSE_POSIX_ERRNO 0
#define configENABLE_BACKWARD_COMPATIBILITY 0

这一组第一版全关。

configUSE_POSIX_ERRNO 只是让每个任务有自己的 FreeRTOS_errno，不是说打开以后 FreeRTOS 就突然变成 Linux 了。

configUSE_NEWLIB_REENTRANT 会给每个任务塞一份 Newlib 重入状态，内存开销也会跟着涨。而且它不等于“从此 printf 随便多线程调用都安全”。串口日志最好还是统一丢给一个日志任务，或者至少用互斥锁保护。

新工程也没必要兼容一堆旧 API 名字，所以 configENABLE_BACKWARD_COMPATIBILITY 关掉。

11. 旧协程

1
2


#define configUSE_CO_ROUTINES 0
#define configMAX_CO_ROUTINE_PRIORITIES 0

这个东西是给 RAM 极小的老设备准备的。它没有普通任务那样的独立栈，走的还是合作式调度。

F407 又不是穷到这点内存都没有，没必要为了省一点 RAM 同时养两套调度模型。关掉，也不用编译 croutine.c。

12. MPU、TrustZone 与安全隔离

1
2
3
4


configENABLE_MPU
configENABLE_TRUSTZONE
configRUN_FREERTOS_SECURE_ONLY
configENABLE_FPU

这几个宏出现在通用模板的 ARMv8-M 配置区里。F407 是 ARMv7-M Cortex-M4F，没有 TrustZone，所以不要照着模板把它们全抄进来。

F407 自己有 MPU，但我们现在选的是标准 portable/GCC/ARM_CM4F，不是 ARM_CM4_MPU。只定义一个 configENABLE_MPU 没用，真正做 MPU 隔离还得换端口、划内存区域、区分特权任务和非特权任务，这已经是下一阶段的东西了。

configTOTAL_MPU_REGIONS 和 configUSE_MPU_WRAPPERS_V1 也都是 MPU 端口才会认真处理的东西。标准 ARM_CM4F 端口下先不用管。

至于 FPU，选中 ARM_CM4F 端口并使用正确的浮点编译参数后，端口会负责浮点上下文；这里也不用额外定义 configENABLE_FPU。这个宏主要是给模板里对应的 ARMv8-M 端口准备的。

13. 多核 SMP

1
2
3


#define configNUMBER_OF_CORES 1
#define configRUN_MULTIPLE_PRIORITIES 0
#define configUSE_CORE_AFFINITY 0

STM32F407 就一个 Cortex-M4F 核心，这组没什么好纠结的。核心数设 1，亲和性关掉，定时器任务绑哪个核这种问题也和我们没关系。

所以 configTASK_DEFAULT_CORE_AFFINITY、configTIMER_SERVICE_TASK_CORE_AFFINITY 这些宏可以直接忽略，它们是多核开启以后才有意义。

官方模板是给所有端口看的，所以里面出现 SMP 不代表 F407 突然长出了第二个核。

14. API 裁剪开关

最后这组 INCLUDE_* 不是在选择调度模式，它只是决定某个 API 要不要编进来。

比如：

1

#define INCLUDE_vTaskDelay 1

开了以后才能用 vTaskDelay()。第一版我会先保留这些：

1
2
3
4
5
6


#define INCLUDE_vTaskDelay 1
#define INCLUDE_xTaskDelayUntil 1
#define INCLUDE_vTaskDelete 1
#define INCLUDE_xTaskGetSchedulerState 1
#define INCLUDE_xTaskGetCurrentTaskHandle 1
#define INCLUDE_uxTaskGetStackHighWaterMark 1

周期任务尽量用 xTaskDelayUntil()，它是按固定时间点唤醒，比“运行完再延时一段时间”更适合做稳定周期。

下面这些没有明确需求就先关：

1
2
3
4
5
6


#define INCLUDE_vTaskSuspend 0
#define INCLUDE_eTaskGetState 0
#define INCLUDE_xTaskAbortDelay 0
#define INCLUDE_xTaskGetHandle 0
#define INCLUDE_xTimerPendFunctionCall 0
#define INCLUDE_xTaskResumeFromISR 0

尤其别把 vTaskSuspend() 当成万能同步工具。任务之间有事件关系，就老老实实用通知、信号量或者队列，不然代码跑着跑着就不知道是谁把谁挂起了。

总结一下

这么一大串看完，其实真正的优先级就几条：

先确认 CPU 真实时钟和 Tick 频率，不然所有时间都是假的。
把 NVIC 分组和 FreeRTOS 中断优先级配对，搞清楚哪些中断能调用 FromISR。
打开 configASSERT、栈溢出检查和 Malloc Failed Hook，让程序死也死得明白。
算任务栈和 FreeRTOS 堆，别拿“现在还没崩”当内存够用的证据。
软件定时器、事件组、Stream Buffer 用到哪个再开哪个。
协程、MPU、TrustZone、SMP 暂时全部放一边。

所以 FreeRTOSConfig.h 不是官方宏大全，更不是把所有功能都设成 1 就完事。它应该老老实实记录这块板子现在跑多快、任务怎么调度、中断能做到什么程度、内存又准备拿出多少。这个文件配明白了，FreeRTOS 才算真的进了自己的工程，而不是从别人的 Demo 里复制过来勉强亮机。

RTOS 前传：先把IDE的编译黑盒拆了

Sun, 16 Aug 2026 01:42:00 +0800

RTOS 前传：先把IDE的编译黑盒拆了

之前其实学过 RTOS，但那时候纯纯把它当黑盒来用：会创建任务、会调度，能跑起来就完事了。CMake 也差不多，自己甚至没怎么手写过。

我发现自己每次开学，工程能力都会 ++；每次一放长假，又会再进化一次。原因可能也很简单：假期里有时间把那些最基础、最底层的东西重新磨一遍。刀磨了一整个假期，开学当然砍得更快。

所以接下来准备更新一个新篇章，重新学 RTOS。这次以 STM32F407VET6 为例，不急着上操作系统，先从最基础的工程开始：补齐启动文件、系统初始化文件和链接脚本，再亲手写好 CMake，让它真的编译起来。

这一篇就是前传。看懂它最好有一点汇编语言和微机原理基础，不然中间可能会有点吃力。

本系列均使用编辑器 + CLI，拒绝一切丑陋的 IDE，比如 Keil CubeMX。用 Keil 的你一辈子没法成长 ,就等着找底薪工作吧。

先把官方仓库拉下来

先克隆 ST 官方的 STM32CubeF4 仓库。里面有一堆库、驱动和例程，也有我们需要的启动文件。

这个仓库其实挺大，只想拿来搭工程的话，浅克隆就够了：

1

gh repo clone STMicroelectronics/STM32CubeF4 -- --depth 1 --recursive

相比完整克隆，体积能小一半以上，快多了。没必要为了三个文件把整个 Git 历史请回家供着。

接下来把工具配齐：

arm-none-eabi-gcc
gdb-multiarch
cmake
ninja
openocd

我自己都安装过了，这里就不演示了。

一个最小工程需要什么

先从 CubeF4 里复制三个关键文件：

1
2
3
4


F407_RTOS_EXAMPLE/
├── Startup/startup_stm32f407xx.s
├── Platform/system_stm32f4xx.c
└── linker/STM32F407VETX_FLASH.ld

官方仓库里比较容易找到的是 STM32F407VGTX_FLASH.ld。它也能拿来改，但一定要注意：F407VGT6 有 1 MB Flash，这里使用的 F407VET6 只有 512 KB Flash。复制之后要把链接脚本改对，最好顺手重命名，免得哪天把自己也骗了。

最基础的文件结构大概这样：

这几个文件到底是干啥的？这就要从编译开始说了。之前说用 IDE 的永远不会成长，原因就在这里：一点 Build，后面的东西全黑了。你只知道没报错，牛逼，可以烧录；或者突然蹦出一个 error，卧槽，牛魔的，快修改。

但我们写的一堆 .c、.h，到底是怎么变成 MCU 能执行的机器码的？大致流程其实就这一条：

1
2
3
4
5
6
7
8
9


C / 汇编源码
 ↓ 编译、汇编
.o 目标文件
 ↓ 链接脚本安排地址
ELF
 ↓ objcopy
BIN / HEX
 ↓ OpenOCD
STM32 Flash

`arm-none-eabi` 这一家子

先简单认一下工具链，后面报错时至少知道该骂谁：

工具	作用
`arm-none-eabi-gcc`	编译 C，也可以统一调用汇编器和链接器
`arm-none-eabi-as`	把汇编代码变成`.o`
`arm-none-eabi-ld`	把一堆`.o` 链接成 ELF
`arm-none-eabi-objcopy`	把 ELF 转成 BIN 或 HEX
`arm-none-eabi-objdump`	看段信息和反汇编
`arm-none-eabi-nm`	看符号和地址
`arm-none-eabi-size`	看 Flash 和 RAM 占用
`arm-none-eabi-gdb`	调试正在运行的程序

arm-none-eabi 也不是什么神秘咒语：

1
2
3


arm → 目标架构是 ARM
none → 不针对某个操作系统
eabi → 使用嵌入式应用二进制接口

至于 MCU 是哪个内核，则由编译参数告诉 GCC，比如 F407 是 Cortex-M4，F1 常见型号是 Cortex-M3。-mcpu=cortex-m4 -mthumb 这类参数就该出现在工具链或 CMake 配置里。

真正决定“代码放到 Flash 哪儿、变量放到哪块 RAM”的，是下面这个文件。

1. 链接脚本：告诉链接器这个家有多大

文件：linker/STM32F407VETX_FLASH.ld

链接脚本干的事很直接：

老子是什么型号？RAM、Flash 多大？每一段程序到底放哪里？

首先是程序入口：

1

ENTRY(Reset_Handler)

这表示固件的入口符号是启动文件里的 Reset_Handler。

然后计算栈顶：

1

_estack = ORIGIN(RAM) + LENGTH(RAM);

再描述物理内存。以 STM32F407VET6 为例：

1
2
3
4
5
6


MEMORY
{
 CCMRAM (xrw) : ORIGIN = 0x10000000, LENGTH = 64K
 RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
 FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
}

这里必须和手上的芯片对得上。写小一点一般只是浪费空间，写大了却可能把程序链接到根本不存在的 Flash 里，到时候就不是“为什么没亮”这么温柔了。

所以 IDE 里选择芯片型号，不只是让界面左上角多一串字；它背后也在替你选启动文件、链接脚本和编译参数。IDE 帮你做了不代表这些东西不存在，只是以前它们被藏起来了。

一句话总结：arm-none-eabi-ld 负责链接，.ld 负责告诉它怎样安排 STM32 的内存。

2. `startup_stm32f407xx.s`：上电后第一棒

第二个关键文件是：Startup/startup_stm32f407xx.s。

它有两重身份。构建时，它先被汇编成目标文件，再和 main.o、system_stm32f4xx.o 一起链接：

1
2
3
4
5
6
7


startup_stm32f407xx.s
 ↓ 汇编
startup_stm32f407xx.o
 ↓ 和其他 .o 一起链接
app.elf
 ↓ 烧录
STM32 Flash

它主要贡献几块内容：

1
2
3


.isr_vector 中断向量表
.text.Reset_Handler 复位启动代码
.text.Default_Handler 默认中断处理代码

链接器再根据 .ld 文件，把向量表和代码放进 Flash。

不过，CPU 并不是从 .s 文件第一行开始往下读。像 .syntax、.cpu、.section、.word 这些，大多是给汇编器看的指令或者数据，不是 CPU 上电后逐句执行的代码。

假设 BOOT0 = 0，芯片从内部 Flash 启动，硬件会先读取向量表前两项：

1
2


0x08000000 的 32 位数 → 装进 MSP，成为初始栈顶
0x08000004 的 32 位数 → 装进 PC，跳到复位入口

对应到启动文件里就是：

1
2
3


g_pfnVectors:
 .word _estack
 .word Reset_Handler

于是整个过程变成：

1
2
3
4
5
6
7
8
9


上电 / 复位
 ↓
CPU 读取 _estack
 ↓
CPU 读取 Reset_Handler 地址
 ↓
跳进 Reset_Handler
 ↓
SystemInit → 初始化 .data/.bss → main

所以更准确的说法不是“CPU 从 startup 第一行开始执行”，而是：

CPU 根据 startup 生成的向量表找到 Reset_Handler，再开始执行它生成的复位代码。

到这里，.s 文件也没那么吓人了。它本质上就是在 C 世界开门之前，先把栈、内存和入口准备好。

3. `system_stm32f4xx.c`：终于回到舒适区

最后一个关键文件是 Platform/system_stm32f4xx.c。唯一一个 .c，是不是瞬间亲切多了？

这个文件来自 CMSIS，处在 startup 和 main() 之间：

1
2
3
4
5
6
7


Reset_Handler
 ↓
SystemInit() ← system_stm32f4xx.c
 ↓
初始化 .data/.bss
 ↓
main()

启动文件里会调用：

1

bl SystemInit

但 startup.o 自己没有这个函数。链接时，ld 会去 system_stm32f4xx.o 里把同名符号找出来。之前那一大家子工具到这里终于串上了。

这个文件里最值得先认识的是三个东西：

1
2
3


void SystemInit(void);
void SystemCoreClockUpdate(void);
uint32_t SystemCoreClock;

`SystemInit()`

它会在复位后、进入 main() 前运行，主要负责把 RCC 恢复到一个确定的基础状态、打开 HSI、处理 FPU 访问权限，以及按配置设置向量表或外部存储器。

它一般不会替你完成这些事：

配置最终的 168 MHz 主频
初始化 GPIO 和串口
初始化 HAL
初始化 FreeRTOS

这些还是后面的板级初始化代码来干。

这时候就有看到这里的吴彦祖、彭于晏困惑了：我不是已经在 CubeMX 的时钟树里把主频改成 168 MHz 了吗，怎么这里还是 16 MHz？

因为 CubeMX 生成的时钟配置，是进入后续初始化阶段才执行的。SystemInit() 只是先把芯片送回一个大家都认识的起点，然后你的代码再去开 HSE、配 PLL、切系统时钟。

`SystemCoreClock`

1

uint32_t SystemCoreClock = 16000000;

它只是一个记录当前 HCLK 的软件变量，很多地方会拿它计算 SysTick、RTOS Tick、串口波特率和定时器参数。

注意，它不是许愿池。你直接写：

1

SystemCoreClock = 168000000;

并不会让 MCU 原地超频到 168 MHz，只会让软件以为它已经到了。真正的时钟还是得改 RCC 寄存器，然后调用 SystemCoreClockUpdate() 重新读取并计算。

`HSE_VALUE`

HSE_VALUE 表示软件认为外部晶振是多少 Hz：

1
2
3


#ifndef HSE_VALUE
#define HSE_VALUE 25000000U
#endif

这不代表程序已经启用了 25 MHz HSE，更不代表你板子上真的焊了 25 MHz 晶振。板子是 8 MHz，就应该通过编译宏传入正确的值：

1

target_compile_definitions(app PRIVATE HSE_VALUE=8000000U)

要不然硬件跑它的，软件算软件的，最后两边各过各的。

还有一个容易漏掉的点：这份启动文件会在 .data 复制和 .bss 清零之前调用 SystemInit()。所以它不能随便依赖已经初始化好的普通全局变量、堆或者完整的 C 运行库，主要还是直接操作硬件寄存器。

一句话总结：

startup 负责把 C 程序的运行环境搭起来，system_stm32f4xx.c 负责把 Cortex-M4 和 STM32F4 拉回一个确定的基础状态，后面的 Platform 代码再配置这块板真正需要的时钟和外设。

最后交给 CMake

必备文件当然还有 main.c，这我就懒得说了。剩下主要是两个和 CMake 有关的文件：

1
2


arm-none-eabi-gcc.cmake # 指定交叉编译工具链和 CPU 参数
CMakeLists.txt # 描述源文件、头文件、链接脚本和产物

工具链文件告诉 CMake 去哪里找 arm-none-eabi-gcc，目标是 Cortex-M4，要使用什么浮点 ABI；CMakeLists.txt 再把 startup、system、main 和链接脚本串起来，最后顺手生成 .elf、.bin、.hex。

具体 CMake 我这里就不展开了。了解基本逻辑之后完全可以让 AI 写，再自己检查参数和路径。这里还要顺便吐槽一下 py：这种东西简单到极致，有啥难度，用的时候学就行了，我完全不知道刻意学习的意义在哪里。

写好之后，工程结构如下：

然后：

1
2


cmake -S . -B build -G Ninja
cmake --build build

哦也，能编译了。

恭喜你亲手拆开了 IDE 的编译黑盒。下一步再往里面塞 RTOS，至少这次知道它到底站在什么东西上面了。牛逼吧。

华为比赛复盘：差一点赶不上飞机，也差一点打得更好

Fri, 10 Jul 2026 00:20:00 +0800

华为比赛复盘：差一点赶不上飞机，也差一点打得更好

回忆一下 7.4 的华为比赛。

事情从 7.3 晚上就开始离谱了。那天晚上十点半左右，我一度真以为自己要赶不上飞机了，结果突然发现航班延期到了第二天凌晨一点。只能说，还好还好。

本来想着到机场之后，或者上飞机之后，还能再复习一点比赛相关的东西。结果刚坐上去，整个人就被期末熬夜攒下来的疲惫直接击昏，进入昏迷模式。再醒过来的时候，已经快到南京机场了，时间差不多是凌晨两点半。

然后又出了一个很蠢的问题。

因为换了书包，我完全忘记自己昏迷前把机票和身份证塞到了哪里。下飞机之后翻了半天没找到，还以为落在飞机上了，于是在行李等候区硬等了一个小时。地勤都快劝我走了，结果我刚坐上网约车，就发现东西其实一直在书包的一个小口袋里。

只能说，人困到一定程度，智商是真的会掉线。

最后到酒店洗完澡，已经凌晨四点半了。睡了大概三个小时，第二天就直接去比赛。

比赛本身

这次华为比赛给我的第一感觉，是它比我预想中正式很多。

一开始我对这类企业比赛多少有点刻板印象，总觉得可能只是喊大学生来做点便宜方案，或者做一场偏宣传性质的活动。但实际体验下来，华为的硬件终端和赛题设计都挺认真，至少不是随便糊一个题目出来应付学生。

可惜最大的问题还是状态。

因为前面一直被期末周压着，我们其实没能充分准备。赛题整体围绕 STM32F103 开发，一个方向偏硬件，涉及激光雷达后端信号、运放和数据处理；另一个方向偏软件，主要是触控笔的无线充电和软件开发。

我们比较不幸，抽到了第一个方向。

现场十六强队伍水平都还可以，基本是 211、985 的研究生，甚至还有博士生，不少人还是 DSP、电机控制相关方向的。这个阵容放在那里，压力还是很明显的。

现场做题

第一问是恢复高电压输出。

本质上其实就是 EN 没开。那个 Boost 电路做得挺厉害，可以从 5.5V 升到 85V 左右，高压输出恢复得还算轻松。

但后面的串口打印 ADC 数据就开始卡了。

一方面是 CubeIDE 用得确实不多，临场切环境本来就不顺手；另一方面是 HAL 库的字节发送接口更偏 8bit 数据，而 ADC 返回的是 32 位结构。怎么把数据正确转换、组织、发送出去，我们现场试了几种方式都没完全打通。

这部分确实有点难受。

第二问是实现高压输出电压调节。

这个相对简单，用 PWM 模拟 DAC，影响反馈端 FB，进而调节高压输出，基本就能解决。中间还被高压电了两下，倒不是特别疼，但确实有点麻。只能说，做这种题还是要对硬件保持敬畏。

第三问是信号运放问题，要求调整输入输出，让波形尽量不失真。

这部分更能感受到课本知识和现场工程之间的差距。课本上学过运放，知道一些基本概念，但真正到了现场，要根据实际信号、实际电路、实际现象去调整，完全是另一回事。这一方面感觉还是得学一下。我们的方向其实已经找对了，只是时间不够，没能把结果继续往前推。

赛后先是下午茶和领取纪念品,之后是答辩,晚饭去园区的海底捞狠狠猪了一把,一桌900额度也可以说是吃到爽哈哈哈。

结果和复盘

整体来说，这次题目不算特别离谱，甚至可以说没有想象中那么难。但因为备赛、环境、状态这些问题叠在一起，最后结果不算理想。

说白了，还是菜。

不过没想到的是，这样最后还能拿到第六名。算下来，这应该是我目前技术比赛里拿到的最高奖项了。短时间、高压力、现场出问题的比赛，确实最能看出一个人的综合水平：基础够不够扎实，环境熟不熟，状态扛不扛得住，临场判断稳不稳，全都会暴露出来。

这次喜提 2k，虽然其中 1k 直接变成了机票钱，但至少没给实验室丢脸。

另外也认识了一些 HR，聊下来能感觉到他们确实很懂就业，也能从企业视角看到很多学生平时不太会注意的东西。这部分收获也挺重要。

总的来说，这次比赛有遗憾，但也有价值。

遗憾是明明可以打得更好，价值是它把很多短板直接摆到了面前：准备不够、工具链不够熟、临场状态不够好，对硬件题的处理经验也还不够。

就这样。

来年必须干回来。

工具链搭建完成

Mon, 18 May 2026 00:00:00 +0000

工具链搭建完成

这段时间主要在折腾自己的嵌入式工具链。到 5.18 这一天，基本可以算是阶段性搭建完成了。

以前做嵌入式，很多流程其实是被厂商 IDE、图形配置工具和各种零散脚本拖着走。能跑是能跑，但每次换平台、换板子、换环境，都像是在重新和工具链打一架。现在我更想把这些东西统一到一套可复现、可调用、可交给 agent 执行的流程里：构建、烧录、检查、日志、错误定位，都尽量走明确的命令和工程结构。

这次最重要的成果，是测试成功了两条 ARM 架构相关的烧录链路。

一条是经典的 STM32F1。这基本算是我最熟悉的一类 MCU，也是很多嵌入式开发者绕不开的起点。能把它从传统开发方式里抽出来，用现代一点的工程结构完成构建和烧录，对我来说像是把老朋友重新接进新的工作流。

另一条是 TI MSPM0。相比 STM32F1，它更像是一个新的切入点：同样是 ARM 生态，但厂商工具、SDK 组织方式、烧录链路和调试习惯都不完全一样。把 MSPM0 也跑通，说明这套工具链不是只为某一个芯片临时拼出来的，而是有机会扩展成更通用的嵌入式开发底座。

从结果看，STM32F1 和 MSPM0 两边都能完成烧录验证，这件事让我很兴奋。工程流开始从“某个项目能跑”变成“某类流程能复用”。只要构建、烧录、调试这些基础动作足够稳定，后面再接入更多芯片、板卡和模板，就不用每次都从一片混乱里重新开始。

下一步：认识 Zephyr

工具链跑通之后，我开始对 Zephyr 这个 RTOS 产生兴趣。

以前接触 RTOS，更多是从裸机工程往上加：任务、调度、信号量、队列、驱动抽象，一层一层把东西堆起来。这样学很扎实，但也容易停留在“我会移植一个系统”或者“我会用一套接口”的阶段。

Zephyr 给我的感觉不太一样。它不像只是一个单纯的内核，更像一整套面向现代嵌入式工程的系统：设备树、配置系统、构建系统、驱动模型、板级支持、跨平台抽象，这些东西组合在一起，才接近我想理解的“工程化嵌入式”。

我想认识它，不只是为了会用一个新的 RTOS，而是想看看成熟的嵌入式系统到底怎么组织复杂性。为什么它能支持那么多板子，为什么驱动可以被抽象成统一模型，为什么配置和构建能被系统化管理，这些问题都值得拆开看。

工具链搭好只是第一步。烧录跑通代表入口打通了，有意思的事情还在后面：把底层硬件、构建系统、RTOS 思想和 agent 工作流接到一起，形成一套自己能长期维护、长期扩展的嵌入式工程体系。

这是我接下来想继续推进的方向。

STM32 on Blog

RTOS 正传（一）：FreeRTOS 的目录、移植层和配置文件

RTOS 正传（一）：FreeRTOS 的目录、移植层和配置文件

RTOS 到底适合什么场景

先把内核仓库拉下来

克隆下来为什么这么吓人

先分清自己站在哪一层

顶层目录先过一遍

根目录的 7 个 .c

include/：平时调用的 API 都在这儿

portable/：真正和芯片接上的地方

那些不会进固件的文件

F407 工程最后到底拿哪些

FreeRTOSConfig.h 配置分类

1. 时钟与时间

2. 调度器与任务

3. 任务附加能力

4. 任务通信与同步

5. 软件定时器

6. 内存、堆和任务栈

7. 中断与临界区

8. Hook 回调

9. 故障检测、断言与统计

10. C 库与 POSIX 兼容

11. 旧协程

12. MPU、TrustZone 与安全隔离

13. 多核 SMP

14. API 裁剪开关

总结一下

RTOS 前传：先把IDE的编译黑盒拆了

RTOS 前传：先把IDE的编译黑盒拆了

先把官方仓库拉下来

一个最小工程需要什么

arm-none-eabi 这一家子

1. 链接脚本：告诉链接器这个家有多大

2. startup_stm32f407xx.s：上电后第一棒

3. system_stm32f4xx.c：终于回到舒适区

SystemInit()

SystemCoreClock

HSE_VALUE

最后交给 CMake

华为比赛复盘：差一点赶不上飞机，也差一点打得更好

华为比赛复盘：差一点赶不上飞机，也差一点打得更好

比赛本身

现场做题

结果和复盘

工具链搭建完成

工具链搭建完成

下一步：认识 Zephyr

根目录的 7 个 `.c`

`include/`：平时调用的 API 都在这儿

`portable/`：真正和芯片接上的地方

`FreeRTOSConfig.h` 配置分类

`arm-none-eabi` 这一家子

2. `startup_stm32f407xx.s`：上电后第一棒

3. `system_stm32f4xx.c`：终于回到舒适区

`SystemInit()`

`SystemCoreClock`

`HSE_VALUE`