在极端资源受限的微控制器上启用FreeRTOS的可选协程特性可以大幅节省任务控制块的内存占用

一、微控制器的“内存焦虑”有多真实？

很多做嵌入式开发的朋友，尤其是玩小芯片的，大概率都遇到过这种糟心事：手里的微控制器（比如8位的AVR、32位的STM8，或者小RAM的STM32F0），RAM就那么点，几KB甚至不到1KB，却要跑个操作系统、接几个传感器、处理点数据，最后卡到动不了，甚至直接跑飞。

为啥会这样？很多人第一反应是代码写得烂、变量开太多，但其实还有个容易被忽略的点：操作系统的任务管理本身占内存。就拿大家常用的FreeRTOS来说，它的任务控制块（TCB）是专门存每个任务状态的，每个TCB的大小是固定的，哪怕这个任务只是个“打酱油”的小任务，也得占这么多空间。

举个最常见的场景：你要做个智能水杯，得有四个小任务：一个每隔10秒测一次水温、一个每隔5秒测一次电池电压、一个每隔20秒发一次数据到蓝牙、一个每隔1秒闪一次指示灯。这四个任务里，除了闪灯是高频的，其他三个都是“很久才动一次”的小任务。要是用普通的FreeRTOS任务，每个都得占TCB的内存，要是RAM本来就小，这四个TCB可能就占了好几百字节，直接把原本留给变量的空间挤没了。

这时候，FreeRTOS的协程特性就派上用场了——它能把多个小任务合并成一个TCB，相当于“多个小任务共用一个内存块”，能大幅省出内存。

二、FreeRTOS协程到底是什么？和普通任务有啥不一样？

很多人一听到“协程”就觉得是高大上的概念，其实用大白话讲，FreeRTOS的协程就是“多个小任务打包成一个大任务”。

普通FreeRTOS任务是“独立个体”：每个任务都有自己的TCB、自己的栈，系统调度的时候，是在多个任务之间切换，切换的时候要保存所有任务的状态，占内存大，切换速度也慢。

协程是“共享团队”：多个协程（也就是之前说的小任务）会被打包成一个“协程任务”，这个协程任务只有一个TCB、一个栈，系统调度的时候，是在这个协程任务内部的多个协程之间切换，切换的时候只需要保存少数几个状态，占内存小，切换速度也快。

而且协程有个专门的调度机制：它是“协作式”的，意思是协程之间不会抢着占CPU，一个协程执行完自己的任务后，会主动把CPU让给下一个协程，直到所有协程都执行完一轮，才会回到操作系统的调度队列，等下一轮再执行。

这里要特别说下FreeRTOS协程的核心配置：要启用协程，得先在FreeRTOS的配置文件里把configUSE_CO_ROUTINES这个宏定义设成1，不然协程功能是关着的。

三、协程的核心优势：省内存的具体逻辑

为什么协程能省内存？核心原因就是“共享TCB和栈”。

我们拿刚才的智能水杯例子来算一笔账：假设普通FreeRTOS的TCB大小是128字节（不同芯片可能有差异，这个数是合理的），每个任务的栈大小是256字节（小任务的最小栈），那四个独立任务的总内存是：(128 + 256) * 4 = 1536字节。

要是用协程呢？四个协程打包成一个协程任务，TCB只有一个（128字节），栈也只有一个（256字节），总内存是128 + 256 = 384字节。这就省出了1536 - 384 = 1152字节的内存！这对只有几KB甚至不到1KB RAM的微控制器来说，简直是救命的空间。

除了省内存，协程还有个小优势：切换速度快。因为协程切换的时候，只需要保存几个寄存器的状态，而普通任务切换要保存整个栈的内容，所以协程切换的时间更短，适合对实时性要求不高、但对内存要求高的场景。

四、协程的完整使用示例（基于STM32F0的FreeRTOS）

4.1 技术栈说明

本次示例使用的技术栈为：STM32F0系列微控制器（以STM32F030F4P6为例，RAM仅4KB）、FreeRTOS v10.4.6、Keil MDK开发环境。

4.2 配置FreeRTOS启用协程

首先要修改FreeRTOS的配置文件FreeRTOSConfig.h，添加或修改以下配置：

// 启用协程功能
#define configUSE_CO_ROUTINES 1
// 定义协程任务的优先级（必须小于configMAX_PRIORITIES）
#define configMAX_CO_ROUTINE_PRIORITIES 2
// 定义协程任务的优先级（这里设为1）
#define configCO_ROUTINE_PRIORITY 1

4.3 编写协程任务

接下来编写四个协程，分别对应测水温、测电池电压、发蓝牙数据、闪指示灯，然后把它们打包成一个协程任务：

#include "FreeRTOS.h"
#include "croutine.h"  // 协程专用头文件
#include "stm32f0xx_hal.h"

// 协程任务的栈大小（比普通任务的栈小很多）
#define COROUTINE_STACK_SIZE 128
// 协程任务的优先级
#define COROUTINE_PRIORITY 1

// 模拟的硬件操作函数（实际项目中替换为真实硬件驱动）
void ReadTemperature() {
    // 模拟读水温：这里可以替换为I2C读DS18B20的代码
    HAL_Delay(10);
}

void ReadBatteryVoltage() {
    // 模拟读电池电压：替换为ADC读电压的代码
    HAL_Delay(5);
}

void SendBluetoothData() {
    // 模拟发蓝牙数据：替换为UART发HC-05的代码
    HAL_Delay(20);
}

void ToggleLED() {
    // 模拟闪灯：替换为GPIO翻转的代码
    HAL_Delay(1);
}

// 协程1：每隔10秒测一次水温
void vCoroutine1(CoRoutineHandle_t xHandle, UBaseType_t uxIndex) {
    // 协程的入口宏，必须放在每个协程的开头
    crSTART(xHandle);
    
    for (;;) {
        // 执行测水温的操作
        ReadTemperature();
        // 协程延时：等待10秒（10000毫秒）
        crDELAY(xHandle, 10000);
    }
    
    // 协程的出口宏，必须放在每个协程的结尾
    crEND();
}

// 协程2：每隔5秒测一次电池电压
void vCoroutine2(CoRoutineHandle_t xHandle, UBaseType_t uxIndex) {
    crSTART(xHandle);
    
    for (;;) {
        ReadBatteryVoltage();
        crDELAY(xHandle, 5000);
    }
    
    crEND();
}

// 协程3：每隔20秒发一次蓝牙数据
void vCoroutine3(CoRoutineHandle_t xHandle, UBaseType_t uxIndex) {
    crSTART(xHandle);
    
    for (;;) {
        SendBluetoothData();
        crDELAY(xHandle, 20000);
    }
    
    crEND();
}

// 协程4：每隔1秒闪一次指示灯
void vCoroutine4(CoRoutineHandle_t xHandle, UBaseType_t uxIndex) {
    crSTART(xHandle);
    
    for (;;) {
        ToggleLED();
        crDELAY(xHandle, 1000);
    }
    
    crEND();
}

// 协程任务：把四个协程打包在一起
void vCoroutineTask(void *pvParameters) {
    // 注册协程：把四个协程添加到这个协程任务中
    crINIT(1, vCoroutine1);
    crINIT(2, vCoroutine2);
    crINIT(3, vCoroutine3);
    crINIT(4, vCoroutine4);
    
    // 进入协程调度循环：会依次执行每个协程的代码
    crSCHEDULE();
}

// 主函数
int main(void) {
    // 初始化硬件（时钟、GPIO、UART、ADC等）
    HAL_Init();
    SystemClock_Config();
    
    // 创建协程任务
    xTaskCreate(
        vCoroutineTask,  // 协程任务的入口函数
        "CoroutineTask", // 协程任务的名称
        COROUTINE_STACK_SIZE, // 协程任务的栈大小
        NULL,  // 任务参数
        COROUTINE_PRIORITY, // 协程任务的优先级
        NULL  // 任务句柄（不需要的话设为NULL）
    );
    
    // 启动FreeRTOS调度器
    vTaskStartScheduler();
    
    // 调度器启动后不会走到这里，除非内存不足
    for (;;);
}

4.4 代码说明

每个协程都用crSTART和crEND包裹，这是FreeRTOS协程的固定格式，用来标记协程的入口和出口。
协程的延时用crDELAY，和普通任务的vTaskDelay不一样，crDELAY是协程内部的延时，不会占用整个协程任务的CPU，只会暂停当前协程，让其他协程继续执行。
协程任务的栈大小可以设得很小，因为多个协程共享一个栈，只要栈能容纳单个协程执行时的最大变量占用就行。

五、协程的应用场景、优缺点和注意事项

5.1 应用场景

协程最适合的场景就是“有大量小任务、内存紧张、实时性要求不高”的嵌入式系统，比如：

智能穿戴设备（手环、手表）：需要处理心率、步数、电池、蓝牙等多个小任务，内存只有几KB。
小型传感器节点：需要采集多个传感器数据、定时上传，内存很小。
低成本的智能家电：比如智能插座、智能灯泡，芯片内存有限，功能不多。
玩具类产品：比如遥控小车、电子宠物，功能简单，芯片成本低，内存小。

5.2 优缺点

优点

大幅节省内存：多个协程共享一个TCB和栈，内存占用比普通任务低很多。
切换速度快：协程切换只需要保存少数几个状态，切换时间比普通任务短。
适合小任务：对于“很久才执行一次、每次执行时间很短”的小任务，用协程比普通任务更划算。

缺点

实时性差：协程是协作式调度，一个协程如果执行时间太长，会阻塞其他协程的执行。比如如果测水温的协程执行了100毫秒，那其他三个协程都要等100毫秒才能执行，这对实时性要求高的场景（比如电机控制）是致命的。
栈溢出风险：多个协程共享一个栈，如果某个协程的变量占用太大，可能会导致栈溢出，而且栈溢出的问题比普通任务更难调试。
功能限制：协程不能调用普通任务的API（比如vTaskDelay、xSemaphoreTake），只能调用协程专用的API（比如crDELAY、crINIT），功能比普通任务少。

5.3 注意事项

协程任务的优先级：协程任务的优先级必须小于configMAX_PRIORITIES，而且不能和普通任务的优先级冲突。
协程的执行时间：每个协程的执行时间必须尽可能短，最好控制在1毫秒以内，避免阻塞其他协程。
栈大小的设置：协程任务的栈大小要足够容纳单个协程执行时的最大变量占用，建议比单个协程的变量占用大20%以上，避免栈溢出。
协程的数量：协程的数量没有限制，但如果协程太多，会导致协程任务的调度时间太长，影响整个系统的响应速度。
协程的调试：协程的调试比普通任务难，因为多个协程共享一个栈，所以调试的时候要特别注意栈的使用情况。

六、总结

在内存紧张的微控制器上，FreeRTOS的协程特性是一个非常实用的优化手段，它通过把多个小任务打包成一个协程任务，共享TCB和栈，大幅节省内存。对于有大量小任务、内存紧张、实时性要求不高的嵌入式系统，协程是一个非常好的选择。

不过协程也有自己的缺点，比如实时性差、栈溢出风险大、功能限制多，所以在使用协程的时候，要根据自己的项目需求来判断是否适合，不能盲目使用。如果项目对实时性要求高，或者内存足够，那还是用普通任务更合适。

最后要提醒大家，协程不是“银弹”，它只是FreeRTOS提供的一个可选特性，只有在合适的场景下使用，才能发挥它的最大价值。

在极端资源受限的微控制器上启用FreeRTOS的可选协程特性可以大幅节省任务控制块的内存占用

一、微控制器的“内存焦虑”有多真实？

二、FreeRTOS协程到底是什么？和普通任务有啥不一样？

三、协程的核心优势：省内存的具体逻辑

四、协程的完整使用示例（基于STM32F0的FreeRTOS）

4.1 技术栈说明

4.2 配置FreeRTOS启用协程

4.3 编写协程任务

4.4 代码说明

五、协程的应用场景、优缺点和注意事项

5.1 应用场景

5.2 优缺点

优点

缺点

5.3 注意事项

六、总结

评论

关联文章

AI助手

一、微控制器的“内存焦虑”有多真实？

二、FreeRTOS协程到底是什么？和普通任务有啥不一样？

三、协程的核心优势：省内存的具体逻辑

四、协程的完整使用示例（基于STM32F0的FreeRTOS）

4.1 技术栈说明

4.2 配置FreeRTOS启用协程

4.3 编写协程任务

4.4 代码说明

五、协程的应用场景、优缺点和注意事项

5.1 应用场景

5.2 优缺点

优点

缺点

5.3 注意事项

六、总结

同分类面试题

关联文章

AI助手