“Arm Cortex M23-Based MCUs Feature FreeRTOS Kernel Support”——这句话如果放在十年前，很多人会嗤笑一声：Cortex M0级别的资源，跑什么RTOS？裸机循环就够了。但这两年实际做过低功耗产品、传感器节点、电池供电设备的嵌入式工程师，应该都能感受到风向变了。Cortex M23作为Arm v8-M架构的入门核心，本来就不是单纯的“M0升级版”，它带了TrustZone安全扩展，主频通常不高（大多在40MHz到72MHz之间），Flash多在64KB到512KB之间，RAM更是抠抠搜搜地给到8KB到128KB。就这么点资源，FreeRTOS不仅能跑，还跑得相当稳，原因用一句话说清楚：FreeRTOS内核本身只需要不到6KB的代码空间，一个最小任务栈只要几百字节就能转起来，这和M23的定位恰好对上了。
这篇文章我想围绕“M23 + FreeRTOS”这套组合，从架构特性、选型逻辑、移植步骤、踩坑实录四个层面展开。适合正在做低功耗物联网终端、Sensor Hub、电机控制副核、或准备把裸机代码迁到RTOS但手里只有一块小容量MCU的工程师看。我尽量把工程中真正会遇到的问题写透，而不是停留在“哪个函数调用哪个API”的层面。
1. 整体设计与架构拆解
1.1 Cortex M23 到底是一颗什么样的内核
很多工程师对Cortex M23的第一印象是“M0+换皮”。严格来说，这种说法只对了一半。M23是Arm在2016年底随v8-M架构一起发布的入门级处理器，它保留了M0/M0+的极低门数和低功耗优势，但指令集层面却往前迈了一大步。
从架构特性来看，Cortex M23的亮点集中在几个方面：
- 支持TrustZone安全分区，这是M0/M0+完全没有的能力。通过SAU（Security Attribution Unit）和IDAU，可以把Flash、RAM、外设划分为安全和非安全两个世界，FreeRTOS跑在非安全侧，安全侧放密钥和secure boot代码，硬件层面隔离，攻击面大幅缩小。
- 可选的MPU（Memory Protection Unit），虽然只有8个region，但足以给任务栈、内核数据区做基本保护。
- 采用ARMv8-M Baseline指令集，硬件除法、原子操作（LDREX/STREX）都成了标配，这比M0+强在同步原语上，FreeRTOS的临界区实现可以直接用原子操作来优化。
- 中断延迟比M0/M0+更低，一般能做到15个周期左右，这对实时任务响应非常友好。
- 调试能力支持SWD和JTAG，部分型号还支持ETM trace。
但要注意，M23的“技术规格”并不包括一颗MCU的整体实力。芯片厂商在M23内核外面挂多少Flash、多少SRAM、哪些低功耗模式、哪些外设，直接决定了这板子实用不实用。以瑞萨RA2系列、NXP LPC8xx系列、Nordic nRF91系列里的应用处理器部分为例，它们普遍把功耗做到几十微安/MHz级别，同时在睡眠模式下还能保留RAM数据和RTC唤醒，这才让“M23 + FreeRTOS + 低功耗”成为可落地的方案。
1.2 FreeRTOS 是怎么在这点资源里转起来的
FreeRTOS的体积优势不是玄学，而是切实的内核设计取舍。它没有使用传统Unix风格的进程模型，而是轻量级任务（task）模型，所有任务共享同一个地址空间，任务间的隔离靠程序员自律和可选的MPU。内核对象只有任务控制块TCB、队列、信号量、互斥量、事件组、软件定时器，每种对象的数据结构都尽可能精简。
我实测过在IAR和GCC下编译：
- 只开任务调度 + 信号量 + 队列，ROM占用大约4.5KB到6KB；
- 如果把软件定时器、事件组、互斥量全部打开，ROM也就8KB出头；
- 每个任务额外的RAM开销主要来自TCB（约90到120字节）+ 任务栈（由用户指定，最小可用128字节，但实际建议至少256字节起步）。
听起来还是不少？但注意，M23 MCU出厂时往往带着至少64KB Flash和16KB RAM，对一颗跑FreeRTOS的芯片来说，这个容量已经够跑4到8个有实际意义的任务了。比如一个典型的传感器终端，拆成采集任务、处理任务、通信任务、电源管理任务，每个任务栈给512字节，总共也就4KB左右的RAM开销，加上内核heap，依然留有余量。
1.3 M23 对比 M0+、M3/M4，为什么偏偏选它
低端MCU选型是个永恒话题。M0+够便宜、够普遍，但遇到需要固件安全升级、密钥保护、更快的开关中断速度、硬件原子操作的场景时，就有点力不从心。M3/M4性能当然更好，但功耗和成本对电池供电的小设备也是包袱。
我习惯用一张表来对比：
| 维度 | Cortex M0+ | Cortex M23 | Cortex M3/M4 |
|---|---|---|---|
| 架构版本 | ARMv6-M | ARMv8-M Baseline | ARMv7-M |
| TrustZone | 不支持 | 支持（可裁剪） | 不支持（M23优势点） |
| 硬件除法 | 无 | 有 | 有 |
| MPU | 可选，通常4-8个region | 可选，通常8个region | 可选，8个region |
| 中断延迟 | 约16周期 | 约15周期 | 约12周期 |
| 指令集 | 56条 | 81条左右 | 大体一致但更丰富 |
| 典型主频 | 48MHz以下 | 72MHz以下 | 100MHz以上 |
M23在Arm内核序列里其实是“性价比安全核”的定位。如果你想做一款带OTA升级、需要防抄板、防固件被读出来的产品，M0+裸奔很难处理，M3/M4成本又偏高，M23配TrustZone是刚好的中间路线。而且M23功耗曲线很漂亮，动态功耗和M0+基本持平，所以这几年很多低功耗无线SoC内部集成的应用处理器都选了M23。
2. 为什么要用 FreeRTOS，而不是继续裸机
2.1 裸机状态机的痛点，在复杂业务下会放大
“裸机 + 状态机 + 定时器中断”这套方法论在简单项目里完全够用，我至今不觉得裸机是过时的技术。但当业务复杂到一定规模，比如设备要同时处理传感器轮询、无线协议栈回调、上位机命令解析、参数存储、异常恢复，裸机的主循环会变得非常痛苦。
具体表现是：状态机事件满天飞，中断里不小心执行了耗时操作，主循环里的标志位互相牵扯，一个未处理的边缘情况可能导致整机挂死。更头疼的是，一旦来了新需求，比如加一个定时上报功能，你得在整个状态机里找出合适的插入点，牵一发而动全身。
FreeRTOS的思路是把并发问题从“事件编排”变成“任务划分”。每个业务模块一个任务，任务之间用队列和信号量通信。采集传感器就是一个while(1)里阻塞在队列上，收到采集命令才执行；通信模块收到数据就往解析队列里丢。这种东西在裸机上写出来也不是不可能，但可维护性差很多。
2.2 FreeRTOS 在 M23 上的真实资源开销
这里给出一组我在实际项目中的配置参考。以某款64KB Flash、16KB RAM的M23 MCU为例，我开了如下功能：
configUSE_PREEMPTION 1 configUSE_TICKLESS_IDLE 1 configUSE_IDLE_HOOK 0 configUSE_TICK_HOOK 0 configUSE_TIMERS 1 configUSE_MUTEXES 1 configQUEUE_REGISTRY_SIZE 8 configUSE_RECURSIVE_MUTEXES 0 configUSE_COUNTING_SEMAPHORES 1 configSUPPORT_STATIC_ALLOCATION 1 // 全部用静态分配，不用heap编译后ROM占用约5.8KB，RAM除了任务栈之外，内核自身占用约1.2KB。也就是说，留给业务代码的空间依然很宽裕。如果连这点开销都不想给，说实话就不该用RTOS，继续裸机就好。
2.3 同类轻量内核的横向对比
Cortex M23能跑的RTOS不止FreeRTOS。我之前也评估过RT-Thread Nano、Zephyr、Keil RTX5：
- RT-Thread Nano：国内生态好，组件丰富，但它的调度器抢占逻辑做得比FreeRTOS“重”，在极小RAM上不如FreeRTOS灵活。
- Zephyr：功能全面、支持设备树，但本身的学习成本和代码体积都偏大，更适合资源相对宽裕的M33或M4平台。
- RTX5：配合Keil MDK使用时集成度极高，CMSIS-RTOS v2接口原生支持，但出了Keil生态反而不如FreeRTOS通用。
FreeRTOS最大的价值在于：它已经被AWS收购后持续维护，有大量商业级项目背书，且几乎每种MCU厂商的SDK都默认集成了移植层。你换一颗芯片，SDK里拉出来就能跑。这种“行业默认选项”的便利性是其他内核很难替代的。
3. 工程搭建与移植实操
3.1 准备一份可用的工程骨架
我们不讨论具体某款芯片的厂商SDK，只说通用步骤。M23平台移植FreeRTOS，最关键的不是复制粘贴文件，而是理解三个层面的东西：
- 内核代码本身：即
tasks.c、queue.c、list.c、timers.c等，这部分与芯片无关。 - 移植层：就是
portable/目录下的代码，M23一般使用GCC/ARM_CM33_NON_SECURE或RVDS/ARM_CM33_NON_SECURE这类port，注意，FreeRTOS官方没有单独的ARM_CM23 port，因为v8-M Baseline和v8-M Mainline在调度器层面用的是同一套机制，官方port直接兼容M23。 - 配置文件
FreeRTOSConfig.h：这是整个移植的“灵魂”。
工程目录建议这样组织：
project_root/ ├── bsp/ // 芯片启动文件、时钟、GPIO、UART等 ├── freertos/ // FreeRTOS 内核源码 │ ├── include/ │ ├── portable/ │ └── src/ ├── app/ // 业务任务 │ ├── main.c │ ├── sensor_task.c │ └── comm_task.c └── linker/ // 链接脚本3.2 移植中最容易被忽略的三个点
第一，FreeRTOSConfig.h里的configCPU_CLOCK_HZ必须和实际系统时钟一致。很多新手把时钟树改到48MHz，配置文件里还写着32MHz，导致vTaskDelay(1000)实际只等了600ms或1.5秒。排查半天，结果是个配置错误。
第二，M23的PendSV和SysTick中断优先级必须设为最低。具体值是NVIC_SYSPRI2寄存器里PendSV和SysTick的优先级都配置为0xFF。如果这两个异常优先级不是最低，一旦在中断里调用了会导致任务切换的API，系统就会进入HardFault。这部分代码通常在port.c或startup_M23.s里，要确认一下。
第三，当使用TrustZone时，FreeRTOS任务默认运行在Non-Secure状态。Secure状态下的中断如果触发了FreeRTOS API调用，需要经过TZ_相关的安全非安全调用接口转换，否则会权限错误。简单项目可以直接关闭TrustZone功能，把M23当普通M0+用，但这样就浪费了核心卖点。
还有一个链接脚本问题：如果开了MPU，任务栈必须按照MPU region对齐要求分配。M23的MPU region最小是32字节，最大4GB，但多数情况下建议让任务栈按8字节或16字节对齐，避免栈指针在入栈时产生非对齐访问。
3.3 写一个最小可运行的示例
下面给出一段最小示例，基于CMSIS-RTOS v2接口，因为新版FreeRTOS默认推荐这套接口，而且厂商SDK几乎都支持。
#include "FreeRTOS.h" #include "task.h" #include "queue.h" static void vTask1(void *argument) { for (;;) { // 采集传感器数据，或者处理某个业务 vTaskDelay(pdMS_TO_TICKS(500)); } } static void vTask2(void *argument) { for (;;) { // 通信处理 vTaskDelay(pdMS_TO_TICKS(1000)); } } int main(void) { /* 初始化时钟、外设 */ BSP_Init(); /* 如果启用TrustZone，必须先完成安全侧初始化 这里简化为直接非安全模式启动 */ xTaskCreate(vTask1, "Task1", 256, NULL, 1, NULL); xTaskCreate(vTask2, "Task2", 256, NULL, 2, NULL); vTaskStartScheduler(); /* 正常情况下不会走到这里 */ for (;;) { } }任务栈大小我用的是256字（即1024字节），这是绝大多数任务的“安全起步值”。如果是中断里解析Modbus、JSON这类可能消耗栈的函数，建议直接给到512字甚至更高，宁可多给，不要让栈溢出。
3.4 Heap 与内存规划经验
如果configSUPPORT_DYNAMIC_ALLOCATION为1，FreeRTOS会用一个heap_x.c文件管理内存。x取1到5，实现各有不同：
heap_1.c：只分配，不释放，适合永不删除任务的场景；heap_2.c：支持释放，但不会合并相邻空闲块，容易碎片化，已被官方标记为不推荐用于新设计；heap_3.c：直接包一层malloc/free，需要C库支持；heap_4.c：首次适配算法 + 相邻空闲块合并，最常用的方案；heap_5.c：在heap_4基础上支持非连续内存块，适合RAM有多个物理分区的芯片。
M23平台我默认推荐heap_4.c，用configTOTAL_HEAP_SIZE指定堆大小。工程里如果RAM有16KB，任务栈静态分配占掉8KB，那么heap可以给4KB，剩下4KB留给全局变量和内核。
实际项目中我更喜欢全静态分配，也就是把configSUPPORT_DYNAMIC_ALLOCATION设为0。这样做的好处是内存占用在编译期就完全确定，不会在运行时出现malloc失败导致的偶发问题，代码评审也更简单。
4. 常见问题与排查技巧实录
4.1 HardFault 到底是谁踩了别人的栈
RTOS下最恼人的问题就是HardFault，尤其是M23这种没有硬件浮点单元的内核，出错现场非常隐蔽。根据我多次定位经验，按出现频率排序：
- 任务栈溢出。M23没有像M3/M4那种可配置的栈溢出检测硬件机制，所以要靠FreeRTOS的软件检测。把
configCHECK_FOR_STACK_OVERFLOW设为2，再补一个vApplicationStackOverflowHook钩子函数。这个钩子触发后，用调试器查看当前任务的栈指针附近数据，就能知道是谁干的。 - 数组越界。这跟RTOS没直接关系，但在多任务环境下会被放大。建议开MPU，给关键任务栈设置region，越界立刻触发MemManage Fault，比事后猜快得多。
- 中断里调用阻塞API。比如在UART中断里直接
xQueueSend超时等待，这是完全禁止的。中断函数里只能用带FromISR后缀的API。 - 在临界区里执行耗时操作。因为M23的
taskENTER_CRITICAL()会屏蔽所有可屏蔽中断，临界区里跑一个Flash写入或大数组拷贝，会导致中断延迟飙升，严重时看门狗复位。
排查工具方面，强烈建议用Ozone或Keil的RTX/FreeRTOS插件查看任务状态和栈高水位。如果条件有限，最简单的方法是做一个“心跳任务”——一个最高优先级的任务，每100ms翻转一次调试IO，用示波器看它是否还活着，这能快速区分“系统崩溃”还是“某任务卡死”。
4.2 Tickless 低功耗模式下的坑
M23主打低功耗，FreeRTOS也提供了configUSE_TICKLESS_IDLE。这个功能让MCU在空闲时进入睡眠，SysTick停止计数，用低功耗定时器来补时间。听起来完美，但有一类问题很典型：唤醒后任务调度出现时钟漂移。
原因是“睡眠时间计算”依赖vApplicationSleep钩子函数，如果你在钩子里没有正确配置唤醒定时器的重新加载值，下一次唤醒后的tick计数就会偏慢或偏快。我的建议是：低功耗产品第一版先把Tickless关掉，正常运行后再开启。开启后对照外部RTC或外部晶振秒信号，连续测48小时，确认漂移在可接受范围。
另外，必须考虑哪个外设能唤醒MCU。有些M23芯片的低功耗定时器在深睡眠模式下不工作，只能用外部GPIO唤醒。这时Tickless策略要做成“浅睡眠 + 短周期”，而不是一味追求长睡眠时间。
4.3 中断优先级和临界区的“玄学”问题
Cortex M23支持中断优先级，但不同芯片厂商实现的可编程优先级位数不一样，有的只支持2位，也就是只有4个优先级等级。FreeRTOS里用configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY来限制“能调用FreeRTOS API的中断优先级”。
如果某个中断优先级数值比这个限制更高（数值更小），它就跟SysTick抢占，同时又调用了任务切换API，结果就是不可预知的。这个问题的经典表现是：程序偶尔死机、被调试器暂停时停在奇怪的指令上、跑几个小时才出一次问题。
排查技巧：把configASSERT打开，FreeRTOS会在API调用前检查当前中断优先级是否合法，不合法直接触发断言。这个宏是调试神器，别再嫌它占空间了。
