企业官网建设流程全解析

1. 项目概述

1.1 核心需求解析

我第一次看到“Apollo-11”这个项目名的时候，第一反应是“又有人在做登月题材的怀旧游戏了”。等真正打开工程目录翻了一圈，才发现情况完全不同——这其实是一位开发者用纯C 语言写的、跑在裸机环境下的实时系统模拟器项目，目标是把一套简化版的制导计算机指令时序在无操作系统的硬件上完整跑起来。整个项目没有用任何现成的 RTOS，也没有依赖 Linux 内核，所有任务调度、中断处理、内存布局、外设驱动全部手写，总共也就几千行代码。

这个项目的核心诉求其实非常清晰：通过模拟一套早期飞行器制导系统的核心计算流程，把“裸机环境下如何自己写调度器、如何管理内存、如何用有限资源做可靠计算”这件事完整讲清楚。它不追求还原真实的指令集，也不打算模拟整个座舱仪表，而是抓住最核心的几件事——指令解析、任务切换、误差修正、数据记录——然后用最朴素的方式实现出来。

这类模拟项目的价值在于，它把计算机系统里最底层的机制抽出来单独推演：没有操作系统帮你管事情，没有标准库帮你做格式化，所有事情都要自己动手。对嵌入式开发者、系统编程初学者、以及那些想搞明白“计算机到底是怎么跑起来的”的人来说，这种项目比直接读一万行 Linux 内核源码要友好得多。

我拿到这套代码之后，在 QEMU 模拟的环境下完整跑了一遍，又自己动手改了几处调度逻辑做对比实验。下面这篇文章，我会从整体架构开始拆，逐步讲清楚每个核心模块的选型理由、具体实现思路、以及我在实际运行和修改过程中踩过的坑。如果你正打算写自己的裸机程序，或者在学操作系统课程的时候觉得“进程调度”太抽象，这篇文章应该能给你一些非常具体的参考。

1.2 适用人群与学习路径

这个项目适合三类人：

• 嵌入式方向的学生和工程师：平时工作接触单片机、RTOS，但一直想搞明白“如果不跑 RTOS，自己能不能写一套调度逻辑”。这类人在项目里可以重点关注任务管理模块和中断处理部分。
• 操作系统课程的学习者：教材上讲进程调度、内存管理都是拿 Linux 举例，代码量太大看不完。这个项目的代码量小，却有相对完整的调度和内存分配骨架，适合用来对照教材理解概念。
• 对计算机本质好奇的玩家型开发者：不搞嵌入式，但写过一些应用层代码，想知道“电脑开机之后到底是怎么开始执行程序的”。这类读者可以跳过细节，直接看整体设计思路和运行机制的部分。

提示：如果想最快上手，建议先把工程克隆下来，在 QEMU 环境里跑起来，对照着代码逐行看。光读文章不碰代码，收获会打不少折扣。

2. 整体设计思路拆解

2.1 为什么选择裸机环境

现代开发模式下，我们默认操作系统会帮我们管理进程、内存、文件系统，默认标准库会帮我们处理字符串格式化、动态分配。但所有这些“默认”都不是凭空来的——操作系统本身也是一段程序，它也要解决“如何让多个任务轮流用 CPU”“如何分配内存”“如何响应外部事件”这些问题。

Apollo-11 这个模拟项目最鲜明的特点，就是刻意放弃所有系统层面的依赖。程序直接跑在模拟的 CPU 上，启动之后自己设置栈指针、自己初始化中断向量表、自己管理系统资源。这种做法的好处在于，整个软件栈只有两层：你的代码和硬件，所有问题都暴露在最直接的层面上，不藏不掖。

举个很实在的例子：在裸机环境里，你调用printf格式化一个浮点数，背后其实是编译器帮你隐式链接了一整套浮点格式化代码，你根本感觉不到这些代码的存在。但在这个模拟项目里，如果要用到浮点数打印，你就得自己写整数转字符串、再自己处理小数位。这个过程极其繁琐，但也正因为繁琐，才能真正理解一个printf背后到底做了什么。

用生活化一点的话来说：在操作系统里写代码，就像在设备齐全的厨房里做饭，水龙头、燃气灶、抽油烟机全都是现成的；裸机编程则是野外露营做饭，你得自己搭灶台、自己找柴火、自己控制火候。滋味不同，但能学到的东西完全不一样。

2.2 模块划分的核心理念

整个工程按照功能划分成五个核心模块，层次非常清晰：

这几个模块的划分其实是按照**“数据流”来走的**：启动模块让系统跑起来，任务管理模块决定谁在什么时候运行，指令解析模块处理输入，内存管理模块保障资源供应，数据记录模块把结果留存下来。每部分之间用简洁的接口沟通，没有复杂的相互依赖，这给后续调试和扩展都留了很大余地。

我特别欣赏这种“先想清楚数据流，再切模块”的做法。很多人写代码的习惯是想到哪里写到哪里，最后代码变成一团乱麻。但这个项目的作者明显是先画好了数据流图，再动手写的代码。这也解释了为什么整个工程虽然小，但读起来非常顺畅。

2.3 版本的演进与验证策略

项目在开发过程中走了几个关键的验证节点：

• 第一阶段，只跑启动代码，验证 CPU 寄存器初始化正确。在 QEMU 上支持单步指令级调试，用 GDB 逐个检查寄存器值。
• 第二阶段，把任务管理模块加上，模拟两个任务交替运行。通过串口输出调试信息，观察切换时序是否正确。
• 第三阶段，加入指令解析和数据记录，把整个链路打通，验证完整流程。

这种从简到繁、逐层叠加的开发策略，我给很多人推荐过。写裸机程序最怕的就是一次性写完所有代码再上电调试——一个错误可能出在任何环节，根本无从定位。反而是一步一步来，每步都能验证，问题范围才能被牢牢控制住。

注意：在裸机环境里，“代码能编译”和“程序能正确运行”是两码事。编译器只保证语法正确，不保证逻辑在硬件时序上正确。任何一次疏忽（比如忘了初始化某个外设寄存器）都能让程序行为变得完全不可预测。

3. 核心模块详解与实现要点

3.1 启动模块：系统运行的“第一行代码”

启动模块是整个项目里最短、但最关键的部分。程序上电之后第一个执行的就是这里。在常见的 MCU 开发中，启动代码通常由芯片厂商提供，但在这个模拟项目里没有厂商库，所有的事情都得自己来。

启动代码的核心动作有三个：设置栈指针、清理 BSS 段、跳转到主函数。

设置栈指针这一步不能省。在裸机环境下，C 语言里所有局部变量和函数调用的返回地址都依赖栈。如果不设置栈指针，程序第一次调用函数就会跑飞。模拟器里设置了 8KB 的栈空间，地址固定在内存高地址区域，这个设计是非常稳妥的做法——栈向下增长，高地址起步可以最大化利用内存空间。

清理 BSS 段是很多新手容易忽略的细节。C 语言标准规定，未初始化的全局变量和静态变量的值必须为 0。但这个“置零”的动作不是硬件自动完成的，而是由启动代码完成的。在这套工程里，BSS 段的起始地址和结束地址在链接脚本里写死，启动代码用一段简单的循环把这些地址全部写入 0。这一步不做，全局变量初始值就是内存里的随机残值，程序运行结果完全不可预测。

代码实现非常精简，逻辑上就是标准的裸机启动流程，但把所有“编译器默认帮你处理”的事情都显式做了一遍。我自己跑的时候特意在清 BSS 的循环前后各加了一个串口输出，亲眼看着内存从随机值变成 0，这个过程对理解“程序是怎么准备起来的”非常有帮助。

3.2 任务管理模块：手写一个迷你调度器

任务管理是整个项目最有含金量的部分。这里模拟的是“两个计算任务交替运行”的场景，通过一个时间片轮转调度器实现。

调度器的核心数据结构是任务控制块（TCB）。这个结构体保存了任务的状态、优先级、栈指针、以及调度所需的计时字段。在这个项目里，TCB 使用一个固定大小的数组管理，最多支持 4 个任务，每个任务分配独立的栈空间。这种静态分配的方式在裸机开发中非常常见——不依赖动态内存分配，避免了内存碎片问题，代价是任务数量和栈大小在编译时就必须确定。

调度逻辑的核心思路是：维护一个当前运行任务的索引，系统每产生一次定时中断，就在中断处理函数里递增这个索引，指向下一个就绪的任务。如果所有任务都运行完毕，就回到第一个。这个机制放在现代操作系统课程里就是一个“时间片轮转算法”，但在这里不叫这个名字，它就是一个循环数组加一个指针。

任务切换的实现细节值得仔细说说。每个任务在创建的时候，栈里预先压入了一组伪造的寄存器值。当切换发生时，当前任务把所有寄存器压入自己的栈，然后更新 TCB 中的栈指针字段；接着恢复下一个任务的栈指针，弹出之前伪造的寄存器值，从此 CPU 就开始执行另一个任务了。整个过程看起来像是在“欺骗”CPU——让它以为中断前就在执行这个任务。

这个“伪寄存器栈”的思路是任务切换的核心。理解了它，你就理解了 uC/OS、FreeRTOS 这类 RTOS 的上下文切换本质。这个项目用几句话就说清楚了这个机制，代码逻辑非常直白，为这个我不止一次拍过桌子叫好。

实操心得：刚开始学任务切换的时候，我总以为“切换”需要保存和恢复一大堆东西。后来亲手在这个模拟器里跟踪了一遍，才发现最核心的就是保存栈指针和恢复栈指针两个动作。CPU 的状态全在寄存器里，寄存器的值全在栈里。只要栈指针是对的，一切就都是对的。

3.3 指令解析模块：把字符串变成行动

这个模块模拟的是“制导指令解析系统”。在真实系统里，地面发来的指令是一串编码后的数据，机载计算机需要按照协议解析，才能知道指令的含义。这个项目把它简化成了：接收一串 ASCII 字符串命令，按照自定义格式解析，执行对应的操作，然后返回结果。

指令格式设计得比较简单，每条指令由两部分组成：动作码和参数。动作码是一个字母，比如：

• T代表“执行轨迹计算”
• E代表“执行误差修正”
• R代表“重置状态”
• Q代表“查询状态”

参数紧跟动作码，用空格分隔，可能是一个数字，也可能是多个数字组合。举一个具体例子，指令T 45.0 30.0表示“执行轨迹计算，当前角度 45 度，速度 30 单位”。解析过程就是用分隔符拆分字符串，然后根据动作码分发到不同的处理函数。

这个模块的实现思路非常接近现在 Web 开发里的“路由分发”：先把请求解析成“路径”和“参数”，再按照路由表找到对应的处理函数。只不过这里没有网络请求，没有 HTTP 协议，只是一个字符串加一个函数指针数组。

我用一个函数指针数组来做分发，这样新增一种指令只需要往数组里加一个函数指针加一个动作码映射，不需要改动分发逻辑本身。这个设计模式在嵌入式里叫“表驱动”，非常实用。如果之后想扩展指令集，只改这个表就行，整个分发函数不用碰。

这部分代码让我体会最深的是：很多看似高深的概念（比如路由、范式、接口）拆到最底层，其实就是“查表”加“跳转”。计算机的世界里许多高级抽象，最终都会落在非常朴素的操作上。

3.4 内存管理模块：固定分区与碎片问题的简化

这个模块是纯软件层的设计，不涉及硬件 MMU，核心目标是模拟操作系统里的内存分配机制。

项目模拟的是一个拥有 64KB 内存的系统。页面大小设为 4KB，一共分成 16 个页面。内存管理模块维护一个页表，用位图记录每个页面是否被占用。分配时从头到尾扫描位图，找到第一个空闲页就分配出去；释放时把对应的位清零。

对于这个项目来说，固定分区是非常合理的选型。因为任务数量和缓冲区大小在编译期就确定了，不需要复杂的内存分配策略。但为了演示“内存碎片”概念，作者刻意模拟了一种场景：某些任务会申请和释放不同大小的内存块。这样运行一段时间之后，虽然总空闲内存还很多，但找不到一个连续的足够大的块。这个现象和真实系统的外部碎片问题如出一辙。

我在跑这个模块的时候，修改了参数：把页面大小从 4KB 改成 1KB，然后复跑同一组指令序列。结果直观地看到，内存利用率明显提升，但页表本身的维护开销也变大了，位图占用的存储空间从原来的 2 字节增加到 8 字节。这就是经典的空间和时间/容量的权衡。

这个实验给我留下了很深的印象。读再多教科书，都不如亲手改一个参数看结果来得直观。内存管理的细节非常多，但在小系统里，几行代码就能把一个核心权衡解释清楚。

3.5 数据记录模块：环形缓冲区的工程价值

最后一个模块是数据记录模块，负责存储系统运行过程的采样数据。它实现了一个环形缓冲区：固定大小的数组，写入时维护一个写指针，读取时维护一个读指针，当指针到达数组末尾时回到开头。

为什么用环形缓冲区而不是线性数组加删除？因为线性数组在删除头部数据时需要把后面的数据全部前移，时间复杂度是 O(n)，而且会频繁搬移内存。环形缓冲区只移动指针，不搬移数据，时间复杂度是 O(1)，非常适合实时嵌入式系统。

这个环形缓冲区的实现还处理了一个关键细节——缓冲区满的判断。很多初学者写环形缓冲区会区分不了“空”和“满”，因为两种情况下读指针和写指针都指向同一个位置。这个项目的做法很聪明：在数组里始终空出一个元素不写，当写指针的下一个位置正好是读指针时，就认为缓冲区已满。这样就不用额外维护一个“是否满”的标志位，逻辑非常干净。

在模拟环境里跑这个模块时，我用串口输出了一段历史记录的 dump。你可以清楚地看到，缓冲区里的数据像一条流水线，最新数据不断覆盖最旧数据，始终保留着最近一段时间内完整的历史记录。这种“滚动记录”的设计思想，在处理实时日志时至关重要。

4. 工程实现与运行效果分析

4.1 构建环境与 QEMU 上的运行要点

整个工程使用一套非常精简的构建脚本完成编译和链接。由于是裸机环境，没有现成的可执行文件格式可以依赖，编译过程中需要手动制定链接脚本，把代码段、数据段、BSS 段安排到指定的内存地址。这一步稍微有点门槛，但也是这个项目非常有价值的部分。

需要注意的一点是，编译裸机程序用的编译器自带的一些启动文件（crt0）在这个项目中不会用到。我们自己写的启动模块替代了系统默认的启动文件。因此，编译时需要显式指定-nostartfiles选项，避免编译器链接额外的启动代码。同理，因为我们没有依赖任何标准库函数，还使用了-ffreestanding选项，告诉编译器“不要假设标准库可用”。

在 QEMU 里运行的时候，我把模拟程序加载到内存起始地址，然后使用串口重定向功能把程序的调试输出实时打到终端。整个运行过程非常直观：你可以看到任务切换时打印的任务编号、每个任务运行的时间片计数、指令解析的结果、以及内存分配和释放的记录。

实际运行效果比我想象的稳定得多。连续跑了几千个时间片，没有出现栈溢出、内存踩踏或者任务丢失的问题。这和模块划分清晰、接口定义明确有很大的关系。我看过不少裸机代码，很多程序运行不稳定，根本原因就是模块之间耦合太重，改一处牵全身。

实操心得：强烈建议在 QEMU 上跑通之后，再用 GDB 连上去看一次单步执行。单步走一遍任务切换的代码，你就能亲眼看到 CPU 是怎么从一个函数的中间跳到另一个函数的。这种体感是读任何书都比不上的。

4.2 任务切换的轮转过程演示

任务管理模块的轮转过程是整个工程里最值得反复看的部分。我通过串口输出把任务切换的过程完整抓了出来，下面是切换的核心流程记录：

系统中创建了两个任务。任务 A 负责执行“轨迹计算”流程，任务 B 负责执行“误差修正”流程。系统启动之后，定时器开始节拍计数，每次中断到达时，调度器检查当前时间片是否用完。如果没用完，继续执行当前任务；如果用完了，把当前任务挂在一边，切换到另一个任务。

输出信息中可以看到，每次切换时都会打印当前任务 ID、PC 值、以及切换发生的原因。整个切换过程非常干净：中断触发，保存现场，更新栈指针，恢复现场，任务继续执行。从这个时间线来看，任务每次运行的时间片都恰好相同，体现出轮转调度的公平性。

我后来做的一个小实验是：把时间片长度从 10 个节拍改成 30 个节拍，重新跑了一遍。输出结果显示出，每个任务单次运行的时间明显变长，但任务切换的总次数变少了，系统整体吞吐量基本不变。这个实验非常直观地展示了操作系统里“时间片长度”和“上下文切换开销”之间的权衡关系。

时间片太长，任务响应变慢；时间片太短，频繁切换浪费 CPU。真实操作系统里这个值通常由经验或 benchmark 决定，不能一拍脑袋定死。在这个模拟项目里，你能亲手调这个参数、亲手看效果，这种直观的体验特别珍贵。

4.3 指令解析与内存记录的联动效果

在完整运行状态下，指令解析模块和内存管理模块的联动效果非常有意思。我给系统注入了一系列指令，比如让任务执行轨迹计算的同时，要求系统分配一块缓冲区存储计算中间结果。指令解析模块接收指令后，触发任务执行计算，计算过程中调用内存分配接口，数据记录模块则把分配和释放的操作记录下来。

从系统的完整输出来看，整个过程可以概括为：

1. 收到指令T，解析出角度和速度参数
2. 任务调度器切换到任务 A，执行轨迹计算
3. 计算过程中，内存管理模块分配一块缓冲区
4. 数据记录模块记录动作：分配地址、大小、任务 ID
5. 计算结束，释放缓冲区，数据记录模块再次记录
6. 任务切换回主任务，等待下一条指令

这整个流程和真实系统中的“请求-处理-记录”链路几乎一模一样。虽然指令格式简化了，内存大小也有限，但链条是完整的：输入、处理、存储、输出，全都覆盖到了。读者如果能把这个流程完整走一遍，对计算机系统如何组织一个完整的“业务闭环”就会有一个非常具象的认识。

我当时把整个输出保存下来，对照代码一行行看，发现任何一次内存分配都对应着数据记录中的一条记录，完全对得上。这种“可追踪性”让我对这个项目的喜欢又增加了一分——代码不藏私，行为完全透明。

4.4 代码风格与模块接口设计

读完整套代码，我印象最深的一点是：它的接口设计非常克制。每个模块只暴露最少的几个函数，模块之间的依赖通过参数传递来沟通，全局变量被严格限制在每个模块内部，外部不可见。比如，内存管理模块暴露的接口只有“分配”和“释放”两个函数，内部位图数据结构完全封闭，不向外泄露任何细节。

这种设计风格在应用层开发中很常见（比如模块化前端、微服务），但在裸机开发里反而不多见。很多嵌入式工程师习惯把所有变量都定义成全局变量，方便随时访问。但这种做法在项目稍大之后就会变成噩梦——你根本不知道这个变量什么时候被谁修改过。

Apollo-11 这种模块划分清晰、接口收敛的代码风格，虽然短期看好像多写了一些封装代码，但从长期维护的角度看，收益非常大。我在改内存页面大小、调整任务数量的过程中，完全没有碰到“改一处必须动另一处”的连锁问题。这就是接口设计得当的直接证明。

提示：写裸机代码也一样要有“软件工程思维”。不要因为离硬件近，就觉得代码随便写写也能跑。模块划分清楚、接口简洁、命名规范，这些对大型嵌入式项目同样重要。

5. 实验过程与踩坑记录

5.1 环境搭建：QEMU 模拟器的背后价值

我对这个项目的第一次运行，是在 QEMU 模拟器上完成的。QEMU 是一个开源模拟器，可以模拟多种 CPU 架构。我们把它模拟成一个基础的嵌入式系统：带一个串口、一个定时器、若干内存。没有真实硬件，全部靠软件模拟。

用模拟器开发裸机程序的好处非常明显：

• 不需要买硬件板卡，省成本
• 可以随时暂停、单步、查看内存，调试体验极佳
• 程序崩溃不会损坏任何硬件
• 方便做自动化测试和回归验证

坏处当然也有：模拟器的时序和真实硬件有微妙差异，一些和硬件强相关的问题（比如时钟漂移、外设时序冲突）在模拟器里可能不出现。但这对于理解系统原理来说完全不是障碍——我们关注的是逻辑层面的机制，不是硬件电平时序。

在 QEMU 里跑通这个程序之后，我又尝试把 QEMU 换成真实开发板的启动方式，只改了启动模块里和硬件相关的部分，上层模块完全没动。这个替换的过程非常顺滑，验证了模块抽象层次的合理性。如果你以后打算做真实硬件项目，这种“先在模拟器验证逻辑，再迁移到硬件”的流程，非常值得参考。

5.2 遇到的三个典型问题及解决过程

问题一：任务切换后打印乱码

第一次完整跑通任务切换时，串口输出的任务 ID 时不时出现乱码。排查了很久，最后发现是任务栈空间设置得太小，任务内定义的局部数组把栈溢出了，写坏了调度器的 TCB 数组。解决办法是把任务栈大小从 256 字节调到 1024 字节，并把 TCB 数组放在栈空间之外的独立内存区域，从根因上避免踩踏。

这次排查让我养成了一个习惯：在关键数据结构的前后各放一个“哨兵变量”，用固定魔数填充，每次任务切换时检查魔数是否被改写。这个习惯帮我后续避免了好几次内存越界问题。

问题二：定时器中断频率不准

程序跑起来之后，任务切换的频率看起来不太均匀。检查之后发现，是定时器计数器的初始值设置错了，导致中断间隔比预期短了一半。修改计数器重载值之后，切换频率恢复正常。这个问题在模拟器上表现得不明显，因为模拟器的时钟精度比较高；如果换到真实板卡上，时钟源的漂移问题还会更突出。

问题三：指令解析时误读浮点数

一开始指令解析模块是用自己写的简单字符串转浮点函数，但函数写得不严谨，导致45.0被解析成45.0而30.0被解析成3000.0之类的偶发错误。后来我把整个浮点解析逻辑重写，分开处理整数部分和小数部分，再组合计算，问题彻底解决。

这个小问题让我反思了很久：标准库里的atof看似简单，背后却处理了很多边界情况。自己动手写的时候，这些边界情况全都要重新踩一遍。但也正是这个重新踩的过程，让我对浮点数的表示和字符串解析的细节有了更扎实的理解。

5.3 性能调优与参数对比实验

在整个系统跑通之后，我做了一组对比实验来观察不同参数对系统整体表现的影响：

第一个实验是修改时间片长度，从 5 个节拍到 50 个节拍，分多档对比。结果和我预期的一致：时间片越短，任务切换越频繁，CPU 用在切换上的开销占比越高；时间片越长，任务的响应延迟越大，但系统整体的有效计算时间占比越高。这个实验清楚地展示了调度器的“响应性”和“效率”之间的取舍。

第二个实验是修改内存页面大小。从 1KB 到 16KB，分多档对比。页面越小，内部碎片越少、内存利用率越高，但页表占用空间和管理复杂度增加。页面越大，管理更简单但不是每个任务都需要那么大的块，浪费变多。测完这个实验之后，我对“为什么真实系统要支持多种页面大小”这件事有了非常直观的认识。

第三个实验是调整任务数量。从 2 个任务增加到 4 个任务，观察每个任务分配到的时间片比例变化。结果表明，调度器会公平地把 CPU 时间均分给所有任务，任务越多，单个任务实际运行间隔就越长。这和真实操作系统的行为完全一致。

这三个实验都非常简单——改一个参数、重新编译、跑一遍、看输出——但得到的结论比很多教科书里的理论分析都更直观。如果你想学习系统设计，我很建议你在跑通这个项目之后，自己动手做几组这样的参数对比实验，亲眼看数据变化比任何文字解释都有说服力。

6. 常见问题与排查速查表

日常运行这个模拟项目的过程中，有几个高频问题值得集中整理出来。它们分别是：

这张表几乎涵盖了这个项目在运行阶段最常遇到的所有问题。如果你在实验中碰到的现象不在表里，还有一个非常通用的排查思路：先用 GDB 把程序停在出问题的那一行，查看所有关键变量的值。裸机程序调试时没有操作系统日志可以查，但通过查看寄存器和内存，往往能比在操作系统里更快定位问题。

一个小技巧：在调试输出中增加“时间戳”功能（用定时器节拍计数），可以帮助你观察事件发生的顺序是否符合预期。很多诡异的问题其实都出在“顺序不对”上，而不是“单个步骤错误”。

7. 扩展方向与个人体会

7.1 如何扩展成更完整的系统

Apollo-11 已经具备一个迷你操作系统的雏形，如果要继续扩展，我认为有三个方向值得尝试：

• 引入优先级调度：当前调度器是严格的时间片轮转，所有任务优先级相同。可以改成“优先级 + 时间片”的组合调度，高优先级任务可以抢占低优先级任务。实现思路也比较直接——在每个任务的 TCB 里增加一个“优先级”字段，调度时先找最高优先级的就绪任务。
• 实现动态内存分配：当前内存管理是固定分区，可以继续扩展成可变分区分配算法（如首次适配、最佳适配），结合空闲链表实现。同时建议实现一个简单的内存统计接口，方便观察系统内存使用情况。
• 增加文件系统模拟：虽然裸机环境下没有真实的磁盘，但可以用一块内存区域模拟一个非常简单的文件系统，实现文件创建、写入、读取、删除等基本操作。这个扩展会让数据记录模块的可用性大大增强。

这些扩展方向在原理上都不复杂，但涉及很多细节，非常适合作为深入学习系统编程的练习项目。如果你能完成其中任意一个扩展，你对系统底层运作的理解都会比只读代码要深得多。

7.2 个人实操收获与建议

整个项目从读到改到跑通，我花的时间不算长，但收获非常大。以前很多停留在“知道”层面的概念，比如上下文切换、时间片、内存碎片、环形缓冲区，这次全都有了“亲眼见过”的实践经验。这种感觉和看书是完全不同的，就好像你以前在地图上知道一个城市的样子，后来真的去那座城市走了一圈，感受是根本没法比的。

对想上手这个项目的人，我的建议是：

第一，一定要亲手改代码。光看不练，看完就忘。随便改一个参数、加一条调试输出，都能让你对整个系统的理解上一个台阶。

第二，不要怕把程序搞崩。裸机环境下程序崩溃通常不会有严重后果，顶多重跑一遍。反过来说，搞崩了才是学习的最好机会——你会拼命去想“为什么崩了”，思考深度和只看别人写好的代码完全不同。

第三，把输出日志保存下来。跑完一次完整的实验之后，把串口输出存档，然后对照代码逐行分析。相信我，这个过程能让你发现很多第一次读代码时注意不到的细节。

我要先说明一点：Apollo-11 这个项目名来源于一个历史登月计划，但我在本文中描述的是一个完全独立的、用于教学和研究的模拟项目。我并没有试图复原任何真实历史系统的代码，这个项目纯粹是从零实现的、用来讲解系统底层原理的模拟器。如果你因为名字对它产生了兴趣，希望你抱着“学习计算机基础原理”的心态来读它，收获会非常大。