AVR单片机RTOS内核实现：从零构建抢占式调度器

1. 项目缘起：为什么要在AVR上折腾RTOS？

几年前，我接手了一个基于ATmega328P（就是Arduino Uno上那颗芯片）的小型工业控制器项目。需求很简单：周期性地采集几个传感器的数据，通过串口上报，同时监听几个按键，并根据按键状态控制几个继电器。最开始，我用一个超级循环（Super Loop）就搞定了，主函数里轮询各个模块，代码写得飞快，一切看起来都很美好。

直到客户提了一个“小”需求：在数据上报的间隙，需要增加一个液晶屏显示实时状态和菜单，菜单操作要流畅，不能卡住数据采集和通信。我尝试在循环里插入屏幕刷新和触摸检测，立刻发现事情不对劲了。屏幕刷新稍微慢一点，传感器采样周期就漂移了；等待触摸响应时，串口数据可能丢失。整个系统变得异常脆弱，任何一点改动都可能引发意想不到的时序问题。那段时间，我满脑子都是delay()和状态标志位，代码成了一团乱麻。

这就是典型的裸机编程遇到多任务需求时的困境。AVR单片机，尤其是像ATmega8/16/32、ATmega328P这类8位机，资源极其有限（通常只有几KB的RAM，几十KB的Flash），运行频率也在16MHz以下。在这种环境下谈“操作系统”，很多人第一反应是“杀鸡用牛刀”或者“根本跑不动”。但正是这种极端受限的环境，才是理解RTOS（实时操作系统）精髓的最佳舞台。在资源丰富的32位ARM Cortex-M核上，你可以很轻松地移植FreeRTOS或RT-Thread，它们提供了完善的功能，但同时也隐藏了许多底层细节。而在AVR上，你需要亲手从零搭建一个最核心、最精简的调度器，这能让你透彻理解任务切换、上下文保存、调度算法、信号量、消息队列这些核心概念到底是如何在硬件层面实现的。

所以，这个项目的目的不是要做出一个功能媲美商用RTOS的系统，而是通过亲手建立的过程，深入理解RTOS的“五脏六腑”。当你看到仅仅几百字节的代码，就能让几个任务“同时”跑起来，那种对计算机系统理解的提升，是看十本书都比不上的。这对于嵌入式开发者来说，是一次绝佳的“内功”修炼。

2. 核心概念扫盲：RTOS到底是什么？为什么需要它？

在深入动手之前，我们必须统一思想，搞清楚我们要做的到底是个什么东西。很多人对RTOS有误解，认为它像Windows、Linux一样庞大复杂。其实不然，尤其是在MCU领域，RTOS的核心价值在于任务管理和调度。

想象一下你的裸机程序，就像一个在厨房里忙碌的孤独厨师。他需要烧水、切菜、炒菜、摆盘。他只能做完一件事，再去做下一件。如果烧水需要10分钟，他就得傻等10分钟，或者不停地跑去看水开了没（这就是轮询）。这就是协同式单任务，效率低下，响应慢。

而RTOS引入了“任务”（Task）的概念。每个任务就像是一个独立的厨师，专注于一道工序。RTOS的核心——调度器（Scheduler）——则像一个厨房总管。总管的工作是决定在任何一个时刻，让哪个厨师使用唯一的灶台（CPU）。当一个厨师在等水开（任务延时或等待事件）时，总管会立刻把灶台让给另一个需要炒菜的厨师。从宏观上看，烧水、切菜、炒菜好像在同时进行。这就是抢占式多任务，极大地提高了CPU的利用率和系统的响应性。

对于我们的AVR项目，RTOS将主要解决以下几个裸机编程的痛点：

1. 模块化与解耦：每个功能（如按键扫描、屏幕刷新、数据采集）可以独立编写成一个任务，彼此之间通过RTOS提供的通信机制（如队列、信号量）交互，代码结构清晰，易于维护和扩展。
2. 实时性保证：通过设置任务优先级，可以确保关键任务（如紧急停止信号处理）总能及时得到执行，不会被非关键任务（如界面动画）长时间阻塞。
3. 解决忙等待：任务可以使用vTaskDelay()或等待信号量等函数主动让出CPU，而不是用while(!flag)空转，节省了宝贵的CPU周期。

那么，一个最最精简的RTOS内核（或称调度器）至少需要哪些部件呢？

• 任务控制块（TCB）：每个任务的“身份证”，保存了任务的状态（运行、就绪、阻塞等）、优先级、堆栈指针、以及任务函数入口地址。
• 就绪列表：一个数据结构（通常是数组或链表），用于管理所有处于“就绪”状态、等待运行的任务。
• 调度器：核心算法，根据就绪列表和优先级，决定下一个要运行的任务是谁。最常用的是基于优先级的抢占式调度。
• 上下文切换：这是最“魔法”的部分。当调度器决定从任务A切换到任务B时，它需要把任务A的当前运行现场（所有CPU寄存器的值）保存到任务A的私有堆栈中，然后把任务B堆栈中保存的现场恢复到CPU寄存器，并跳转到任务B上次暂停的地方继续执行。这个过程对于任务来说是透明的，它们都以为自己独占CPU。
• 系统时钟（SysTick）：一个周期性的中断源，为RTOS提供“心跳”。每次心跳，调度器可以检查是否有任务延时到期、是否需要发起一次调度。在AVR上，我们通常使用一个硬件定时器（如Timer1）来产生这个中断。

3. 动手前的抉择：AVR RTOS的设计与选型考量

在AVR上实现RTOS，每一步选择都关乎成败，因为资源实在太紧张了。我们不能像在Cortex-M上那样随心所欲。

3.1 调度策略：抢占式还是协作式？

• 协作式（Cooperative）：任务主动调用taskYIELD()之类的函数来让出CPU。实现简单，不需要考虑任务被任意打断时的资源保护（临界区），上下文切换开销小。缺点：一个任务不让出CPU，整个系统就会卡死。实时性无法保证。
• 抢占式（Preemptive）：调度器可以基于优先级或时间片强制打断当前任务，切换到更高优先级的任务。实时性好。缺点：实现复杂，必须处理临界区问题（通常通过关中断实现），上下文切换开销稍大。

我们的选择：基于优先级的抢占式调度。理由很简单，我们学习RTOS就是为了体验其核心的“抢占”特性。而且，通过精心设计，其开销在AVR上是可接受的。我们会使用一个简单的“禁止中断”来保护临界区代码。

3.2 任务堆栈：RAM消耗的大户

每个任务都需要独立的堆栈空间，用于保存局部变量、函数调用地址以及上下文切换时的寄存器现场。这是AVR RTOS最大的RAM消耗源。

• 堆栈大小估算：这是一个难点，给少了会溢出，给多了浪费。一个经验方法是：先给一个较大的值（比如200字节），在任务函数里写满特定的标记（如0xAA），运行一段时间后检查被修改的边界，从而估算出实际使用量。对于AVR上简单的任务，80-150字节可能就够了。
• 堆栈生长方向：AVR的堆栈是从高地址向低地址生长的。在初始化任务堆栈时，我们必须模拟一个“初始上下文”并压栈，让第一次切换到该任务时，能正确地从任务函数开始执行。

3.3 系统心跳时钟源

我们需要一个稳定的周期性中断来驱动调度器。AVR的Timer1（16位定时器）是个不错的选择。

• 时钟节拍（Tick）频率：通常设置为100Hz（10ms一次中断）或50Hz（20ms一次）。频率越高，时间精度越高，但系统开销也越大。对于大多数控制应用，100Hz足够用了。
• 中断服务程序（ISR）：在Tick中断里，主要做两件事：
  1. 更新系统时钟计数器（用于vTaskDelay）。
  2. 检查是否有阻塞的任务因延时到期而需要重新放入就绪列表。注意：在AVR中，复杂的中断服务程序要尽可能快，因此通常不在Tick中断里直接进行任务切换，而是设置一个调度标志，在中断退出后，由主调度器检查这个标志并执行切换。

3.4 开发环境与目标芯片

• 编译器：GCC（AVR-GCC）是绝对的主流，与GNU工具链完美集成。我们所有的代码都将基于C语言和GCC内联汇编。
• 芯片：为了有足够的资源进行实验，建议选择ATmega328P（32KB Flash, 2KB RAM）或ATmega128（128KB Flash, 4KB RAM）这类资源相对丰富的型号。ATmega8（8KB Flash, 1KB RAM）就太极限了，不适合学习。
• 编程器/调试器：可以使用USBasp、Arduino as ISP或者更专业的JTAGICE。配合Atmel Studio或VS Code + PlatformIO进行开发。

4. 从零构建：一个最小可运行的AVR RTOS内核

理论说再多不如一行代码。下面我们开始构建一个名为MiniAVROS的极简内核。我们将分模块实现。

4.1 数据结构定义：任务控制块与就绪列表

首先，在minios.h中定义核心数据结构。

// minios.h #ifndef _MINI_AVR_OS_H_ #define _MINI_AVR_OS_H_ #include <stdint.h> // 任务状态 typedef enum { TASK_READY, TASK_RUNNING, TASK_BLOCKED } task_state_t; // 任务控制块 (Task Control Block) typedef struct tcb { void *sp; // 任务堆栈指针，这是上下文切换的关键 task_state_t state; // 任务状态 uint8_t priority; // 任务优先级 (0最高) void (*task_func)(void*); // 任务函数指针 void *arg; // 任务函数参数 struct tcb *next; // 用于就绪列表链表 } tcb_t; // 系统最大任务数 (根据RAM调整) #define MAX_TASKS 4 // 系统API声明 void os_init(void); uint8_t os_task_create(void (*task)(void*), void *arg, uint8_t priority); void os_start_scheduler(void); void os_delay(uint32_t ticks); // 供汇编上下文切换函数使用的外部声明 extern void os_switch_context(void); extern tcb_t *current_task; extern tcb_t *ready_list; #endif

就绪列表我们用一个简单的单向链表来管理，链表头是ready_list。current_task指向当前正在运行的任务。

4.2 任务堆栈初始化与创建

这是最需要理解硬件细节的一步。当调度器第一次切换到某个任务时，CPU寄存器应该是什么状态？我们需要在任务堆栈里“伪造”一个初始现场。

在minios.c中：

// minios.c #include “minios.h” #include <avr/io.h> #include <avr/interrupt.h> // 全局变量定义 tcb_t task_table[MAX_TASKS]; tcb_t *current_task = NULL; tcb_t *ready_list = NULL; uint32_t system_tick = 0; // 每个任务的堆栈空间 #define STACK_SIZE 128 uint8_t task_stacks[MAX_TASKS][STACK_SIZE]; // 创建任务 uint8_t os_task_create(void (*task_func)(void*), void *arg, uint8_t priority) { static uint8_t task_id = 0; if (task_id >= MAX_TASKS) return 255; // 失败 tcb_t *new_task = &task_table[task_id]; uint8_t *stack_top = &task_stacks[task_id][STACK_SIZE - 1]; // AVR栈顶是高地址 // 1. 在堆栈上模拟中断返回现场 // AVR的PC是2字节，但为了对齐，我们按16位机常见做法，先压地址低位，再压高位。 // 首先，将任务函数的入口地址压栈，作为返回地址。 *stack_top-- = (uint8_t)((uint16_t)task_func & 0xFF); // PC低字节 *stack_top-- = (uint8_t)(((uint16_t)task_func >> 8) & 0xFF); // PC高字节 // 2. 压入SREG (状态寄存器)，初始值假设中断全局使能 *stack_top-- = (1 << SREG_I); // I位为1，使能全局中断 // 3. 压入通用寄存器 R31 ~ R0 (在AVR-GCC调用约定中，有些寄存器是调用者保存，有些是被调用者保存) // 为了简化，我们把所有通用寄存器初始化为0。在实际的上下文保存/恢复中，我们可能不需要保存全部。 // 这里我们压入足够多的空间，假设我们需要保存R2-R17, R28-R29 (Y指针)等。 // 我们计划在上下文切换汇编中保存R2-R17, R28-R29，共18个寄存器。 for (uint8_t i = 0; i < 18; i++) { *stack_top-- = 0x00; // 寄存器初始值 } // 4. 将最终的栈顶指针保存到TCB的sp成员 new_task->sp = (void*)stack_top; // 5. 初始化TCB其他字段 new_task->state = TASK_READY; new_task->priority = priority; new_task->task_func = task_func; new_task->arg = arg; new_task->next = NULL; // 6. 将新任务插入就绪列表（这里按优先级简单插入，实际可用更优算法） tcb_t **ptr = &ready_list; while (*ptr != NULL && (*ptr)->priority <= priority) { ptr = &((*ptr)->next); } new_task->next = *ptr; *ptr = new_task; task_id++; return (task_id - 1); // 返回任务ID }

关键点与避坑提示：

1. 堆栈生长方向：一定要记住AVR是递减栈，初始化时stack_top必须指向数组的最后一个元素（最高地址）。
2. 模拟现场的顺序：这必须与后面上下文切换汇编代码中出栈的顺序完全相反。我们这里是“后进先出”（LIFO）。通常顺序是：先压入任务函数地址（PC），然后是状态寄存器（SREG），最后是通用寄存器。在中断服务程序中，硬件会自动压入PC和SREG，所以我们的模拟要与之匹配。
3. 寄存器保存集合：保存哪些寄存器取决于编译器的调用约定。GCC for AVR使用R2-R17, R28-R29作为被调用者保存寄存器。为了简化，我们在学习版本中可以选择保存所有通用寄存器（R0-R31），但这会增大堆栈和切换开销。一个优化的版本会只保存必要的寄存器。
4. 对齐：虽然AVR是8位机，但地址是16位的，压栈时要注意高低字节顺序。

4.3 上下文切换的魔法：汇编语言实现

这是整个RTOS最核心、最硬件相关的部分。我们需要用汇编语言写一个函数，它能保存当前任务的上下文到其堆栈，并恢复下一个任务的上下文。

我们创建一个os_switch.S文件（GCC内联汇编也可，但单独文件更清晰）：

; os_switch.S ; 上下文切换函数: os_switch_context() ; 假设当前任务指针在 current_task，下一个任务指针在某个寄存器或全局变量中传递。 ; 这里我们实现一个最简单的版本：总是切换到 ready_list 中的第一个任务。 .global os_switch_context .global current_task .global ready_list os_switch_context: ; 第一部分：保存当前任务上下文 ; 假设进入此函数时，中断是关闭的（由调度器调用前关中断） ; 1. 将通用寄存器压入当前任务堆栈 push r2 push r3 ; ... 依次压入 r4 到 r17 .irp reg, 4,5,6,7,8,9,10,11,12,13,14,15,16,17 push r\reg .endr ; 保存Y指针 (r28:r29) push r28 push r29 ; 2. 将当前的栈指针保存到 current_task->sp ; 栈指针是SPH:SPL，在AVR中，我们可以用Y指针来传递地址 lds r28, current_task ; 加载current_task低地址 lds r29, current_task+1 ; 加载current_task高地址 ; Y指针现在指向 current_task 结构体 ; 将SP保存到 TCB的第一个成员 (sp) in r2, SPL in r3, SPH std Y+0, r2 ; TCB.sp 低字节 std Y+1, r3 ; TCB.sp 高字节 ; 第二部分：恢复下一个任务上下文 ; 3. 从 ready_list 获取下一个要运行的任务TCB地址 lds r28, ready_list lds r29, ready_list+1 ; 将 ready_list 赋值给 current_task sts current_task, r28 sts current_task+1, r29 ; 4. 从新的TCB中加载堆栈指针 ld r2, Y+0 ; 新任务 sp 低字节 ld r3, Y+1 ; 新任务 sp 高字节 out SPL, r2 out SPH, r3 ; 5. 从新堆栈中弹出通用寄存器 pop r29 pop r28 ; ... 依次弹出 r17 到 r2 (注意顺序与压栈相反) .irp reg, 17,16,15,14,13,12,11,10,9,8,7,6,5,4,3,2 pop r\reg .endr ; 6. 函数返回。ret指令会从堆栈中弹出PC，从而跳转到新任务继续执行。 ret

关键点与避坑提示：

1. 关中断：在调用os_switch_context之前，必须关闭全局中断，防止在切换过程中发生中断，破坏上下文。切换完成后再打开。这个操作通常由调度器函数完成。
2. 保存哪些寄存器：这里保存了R2-R17和R28-R29，这是GCC的被调用者保存寄存器。如果你在任务函数中使用了R18-R27等调用者保存寄存器，并且调度器函数（C语言）也使用了它们，那么可能也需要保存。最保险的方法是保存所有寄存器（R0-R31），但开销大。需要仔细分析你的C代码和汇编的交互。
3. 栈指针操作：in和out指令用于读写IO空间的SP寄存器。保存和恢复SP是上下文切换的灵魂。
4. ret指令的魔力：最后的ret指令从堆栈中弹出一个16位地址到PC。在我们初始化任务堆栈时，我们压入的是task_func的地址。因此，当第一次切换到该任务时，ret就会跳转到task_func开始执行。对于非第一次切换，堆栈顶部保存的是该任务上次被切换出去时的返回地址，因此能正确恢复。

4.4 系统初始化与心跳时钟

我们需要初始化系统，并启动一个定时器作为系统心跳。

// minios.c (续) void os_init(void) { // 1. 初始化就绪列表和当前任务指针 ready_list = NULL; current_task = NULL; system_tick = 0; // 2. 配置系统时钟定时器 (以Timer1为例，产生100Hz中断) TCCR1A = 0; // 普通模式 TCCR1B = (1 << WGM12) | (1 << CS11) | (1 << CS10); // CTC模式，预分频64 OCR1A = (F_CPU / 64 / 100) - 1; // 100Hz 中断 TIMSK1 |= (1 << OCIE1A); // 使能输出比较A匹配中断 // 3. 使能全局中断 sei(); } // 系统时钟中断服务程序 ISR(TIMER1_COMPA_vect) { system_tick++; // 简化处理：检查所有阻塞的任务，如果延时到期则重新加入就绪列表 // 在实际中，这里应该遍历一个阻塞列表，而不是任务表。 // 这里为了演示，我们假设每个TCB有一个`delay_ticks`字段。 for (uint8_t i = 0; i < MAX_TASKS; i++) { if (task_table[i].state == TASK_BLOCKED && task_table[i].delay_ticks > 0) { task_table[i].delay_ticks--; if (task_table[i].delay_ticks == 0) { task_table[i].state = TASK_READY; // 将任务重新插入就绪列表 (此处省略链表操作代码) } } } // 设置一个调度请求标志，而不是在中断里直接切换 // os_sched_flag = 1; }

4.5 调度器与延时函数

最后，实现调度器主循环和延时函数。

// minios.c (续) static volatile uint8_t os_sched_flag = 0; // 核心调度函数 static void os_schedule(void) { cli(); // 关中断，进入临界区 if (ready_list != NULL && ready_list != current_task) { // 如果就绪列表的第一个任务不是当前任务，则进行切换 // 注意：这是一个非常简单的调度，总是运行就绪列表的第一个任务（优先级最高） // 更复杂的调度器会考虑时间片轮转等。 os_switch_context(); // 切换到 ready_list 指向的任务 } sei(); // 开中断 } // 启动调度器 void os_start_scheduler(void) { if (ready_list == NULL) return; // 没有任务，直接返回 current_task = ready_list; current_task->state = TASK_RUNNING; // 手动加载第一个任务的堆栈指针，并跳转 // 这需要一点汇编魔法，或者我们可以在os_init后创建一个空闲任务，然后通过一次普通的上下文切换来启动。 // 这里介绍一种常见技巧：将调度器本身也看作一个特殊任务，第一次切换时，从“调度器任务”切换到第一个用户任务。 // 我们先初始化调度器的“伪上下文”。 // 更简单的方法：直接使用汇编跳转到第一个任务。为了简化，我们假设调用 os_start_scheduler() 后不会返回。 // 以下代码仅为示意，实际启动需要精心设计。 __asm__ __volatile__ ( "cli \n\t" // 关中断 "lds r28, ready_list \n\t" // 加载第一个任务TCB地址到Y "lds r29, ready_list+1 \n\t" "ld r2, Y+0 \n\t" // 加载sp低字节 "ld r3, Y+1 \n\t" // 加载sp高字节 "out __SP_L__, r2 \n\t" // 恢复SP "out __SP_H__, r3 \n\t" "pop r29 \n\t" // 开始弹出寄存器，与初始化顺序相反 "pop r28 \n\t" ".irp reg, 17,16,15,14,13,12,11,10,9,8,7,6,5,4,3,2 \n\t" "pop r\\reg \n\t" ".endr \n\t" "sei \n\t" // 开中断 "ret \n\t" // 跳转到任务函数！ ::: "memory" ); } // 任务延时函数 void os_delay(uint32_t ticks) { cli(); current_task->state = TASK_BLOCKED; current_task->delay_ticks = ticks; // 将当前任务从就绪列表移除 (此处省略链表操作代码) os_schedule(); // 主动触发调度，切换到其他就绪任务 sei(); // 当任务再次被调度时，会从这里继续执行 }

5. 实战测试：让两个任务“同时”跑起来

现在，让我们用这个简陋的内核来创建两个简单的任务，验证它是否能工作。

// main.c #include “minios.h” #include <avr/io.h> #include <util/delay.h> // 定义两个LED引脚 (以Arduino Uno为例，Pin13为板载LED) #define LED1_PIN 5 // PD5 #define LED2_PIN 4 // PD4 void task1(void *arg) { DDRD |= (1 << LED1_PIN); // 设置LED1为输出 while (1) { PORTD ^= (1 << LED1_PIN); // 翻转LED1 os_delay(50); // 延时约500ms (假设Tick为10ms) } } void task2(void *arg) { DDRD |= (1 << LED2_PIN); // 设置LED2为输出 while (1) { PORTD ^= (1 << LED2_PIN); // 翻转LED2 os_delay(30); // 延时约300ms } } int main(void) { os_init(); // 创建两个任务，优先级相同（都为1） os_task_create(task1, NULL, 1); os_task_create(task2, NULL, 1); // 启动调度器，永不返回 os_start_scheduler(); while (1) { } // 永远不会执行到这里 return 0; }

将代码编译并烧录到ATmega328P开发板。如果一切顺利，你应该能看到两个LED以不同的频率闪烁（一个快，一个慢），并且互不影响。这说明调度器正在工作，两个任务在“并发”执行！

6. 进阶思考与优化方向

一个能跑通两个LED闪烁的Demo只是起点。要让它成为一个真正可用的学习框架，还有很多路要走：

1. 优先级调度与防止饥饿：目前的简单链表插入实现了静态优先级调度。但如果高优先级任务一直就绪，低优先级任务将永远得不到执行（饥饿）。需要引入时间片轮转或优先级继承/天花板等机制。
2. 任务间通信：实现真正的信号量、互斥锁和消息队列。这是多任务协作的基石。例如，实现一个二进制信号量需要维护一个等待该信号量的任务链表。
3. 系统服务：实现os_task_delete、os_task_suspend/resume、获取任务状态等API。
4. 资源与稳定性优化：
   • 堆栈溢出检测：在每个任务堆栈的底部和顶部设置魔数（如0xDEADBEEF），在Tick中断中定期检查，如果魔数被修改，则说明发生了堆栈溢出。
   • 临界区保护：目前的cli()/sei()太粗暴，会关闭所有中断。可以设计一个嵌套的临界区进入/退出计数器，只在必要时关中断。
   • 空闲任务：当所有用户任务都阻塞时，调度器应该运行一个低优先级的空闲任务，这个任务可以执行CPU休眠指令以省电。
5. 调试与可视化：利用串口输出各个任务的状态、堆栈使用情况、CPU利用率等信息，这对于学习和调试至关重要。

亲手实现这些功能的过程，会让你对RTOS的理解产生质的飞跃。你会明白为什么FreeRTOS的xQueueSend函数里会有那么多判断和循环，为什么互斥锁会有优先级继承的特性。这些知识，是只看API文档永远无法深刻领会的。

7. 从“裸机思维”到“RTOS思维”的转变

最后，我想分享几点在AVR上玩转RTOS后的心得体会，这可能比代码本身更有价值：

• 状态机是好朋友：即使在RTOS中，每个任务内部也经常是一个状态机。RTOS解决了宏观的并发问题，而状态机解决了任务内部逻辑的清晰性问题。两者结合，代码会非常优雅。
• 共享资源是万恶之源：只要有多于一个任务访问的变量或硬件外设，就必须考虑保护。“关中断”是最简单粗暴的互斥方法，但需慎用，因为它会影响系统实时性。在AVR小系统中，合理设计数据流，尽量减少共享资源，往往比复杂的同步机制更有效。
• 延时不是睡眠：os_delay()是主动让出CPU，而裸机的_delay_ms()是忙等待。这是思维转变的关键。在RTOS中，任何形式的忙等待（while(1)）都是对系统响应能力的犯罪。
• 理解开销：任务切换需要时间（几十到上百个时钟周期），每个任务需要独立的堆栈（消耗RAM）。在AVR上，你必须清楚这些开销，并据此决定系统的任务数量。不是所有功能都需要一个独立任务，有时一个状态机放在主循环里可能更合适。

这个自制的AVR RTOS项目，就像自己动手造了一辆自行车。它可能没有买来的山地车漂亮、快，但造车过程中你对链条、齿轮、刹车原理的理解，是任何骑行教程都无法给予的。当你以后再使用FreeRTOS、RT-Thread甚至Linux时，你会清楚地知道，屏幕背后那个调度器，大概就是像你今天写的这样工作的。这种透过现象看本质的能力，正是嵌入式工程师最宝贵的财富。