嵌入式操作系统-2026sp-作业

嵌入式操作系统 2026 春季学期的日常作业。

本文连载于嵌入式操作系统-2026sp-作业 | HeZzz.

答案来源于 GPT-5.5 和 NotebookLM，并由我校对，可能不完全准确，仅供参考。

🙇‍♂️🙇‍♂️🙇‍♂️时间仓促，有不足之处烦请及时告知。邮箱hez2z@foxmail.com 或者在 速通之家 群里 @9¾。

第一章

请给出操作系统的定义、作用和分类？

计算机由硬件和软件两部分组成，操作系统是配置在计算机硬件上的第一层软件，在计算机系统中占据了特殊重要的地位；

作用：

• 补平硬件差异的界面或是说隐藏硬件，让应用程序可以在上面运行。
• 程序设计人员无须考虑到不同硬件所造成的差异，可专注于所擅长领域的开发。

请列举至少三种常见的嵌入式操作系统？

根据课件介绍，常见的嵌入式操作系统包括：

1. uC/OS-II / uC/OS-III（微控制器实时操作系统）
2. FreeRTOS（广泛应用的开源实时操作系统）
3. RT-Thread（国内主流的开源实时操作系统）
4. VxWorks（高可靠性的商用实时操作系统）
5. SylixOS（国内自主研发的大型实时操作系统）

思考题：结合当前人工智能发展的趋势，根据你的理解，阐述嵌入式系统的发展将会迎来哪些机遇和挑战？

• 机遇：
  • 边缘智能（Edge AI）的兴起：人工智能模型（TinyML）正从小微型化发展，允许在低功耗的嵌入式微控制器上直接运行轻量级神经网络，减少对云端带宽的依赖，极大降低了延迟，增强了隐私性。
  • 新应用场景的爆发：智能家居、自动驾驶、物联网穿戴设备、机器人等领域对实时、低功耗本地AI处理的需求激增，推动了嵌入式芯片与操作系统的硬件加速和软硬件协同设计。
• 挑战：
  • 极其受限的资源与高算力的矛盾：AI模型即使经过量化裁剪，其计算和存储开销对于RAM和闪存空间通常只有几百KB的嵌入式设备而言依然是沉重负担。
  • 实时性保证：AI推理计算（如卷积、矩阵乘法）往往耗时较长，如何在有限的主频下保证操作系统关键控制任务的硬实时响应是极大考验。
  • 功耗与散热限制：边缘设备多为电池供电或无风扇设计，如何在提升算力的同时控制功耗，对芯片设计和系统电源管理提出了更高要求。

第二章

uC/OS-II中的任务有哪 5 种状态？各状态之间是如何转换的？

• 5种状态：睡眠状态 (Dormant)、就绪状态 (Ready)、运行状态 (Running)、等待状态 (Waiting/Pending)、中断服务状态 (ISR)。
• 转换过程：
  1. 睡眠 $\rightarrow$ 就绪：任务被创建（调用 OSTaskCreate/OSTaskCreateExt）后进入就绪状态。
  2. 就绪 $\rightarrow$ 运行：当该任务是就绪表中优先级最高的任务时，经过调度器调度（OS_Sched / OSIntExit）获得CPU使用权，进入运行状态。
  3. 运行 $\rightarrow$ 就绪：运行中的任务被更高优先级的任务抢占，或调用了让出 CPU 的系统函数，返回就绪状态。
  4. 运行 $\rightarrow$ 等待：运行中的任务因为等待某个事件（如信号量、邮箱、队列）或主动调用延时函数（OSTimeDly）而挂起，进入等待状态。
  5. 等待 $\rightarrow$ 就绪：等待的事件发生、延时时间到、或被其他任务恢复（OSTaskResume），重新进入就绪状态。
  6. 运行 $\rightarrow$ 中断服务：运行任务被硬件中断打断，进入中断服务状态。
  7. 中断服务 $\rightarrow$ 运行：中断服务结束（调用 OSIntExit），若没有更高优先级任务就绪，则继续运行原任务。
  8. 中断服务 $\rightarrow$ 就绪：中断服务结束（调用 OSIntExit），若有更高优先级的任务就绪，原任务被剥夺CPU，进入就绪状态。
  9. 任意状态 $\rightarrow$ 睡眠：调用删除任务函数（OSTaskDel）销毁任务控制块与任务栈。

uC/OS-II V2.52最多可以管理多少个任务？为什么？

• 最多可以管理 64 个任务。
• 原因：uC/OS-II 的调度算法基于优先级，在 V2.52 版本中支持 0～63 共 64 个优先级。因为每个任务必须拥有唯一的优先级，所以总任务数不能超过 64 个。其中，系统保留了 8 个优先级（最低的若干个，如空闲任务占最低优先级，统计任务占次低），因此留给用户的用户任务最多有 56 个。

数组 OSTCBPrioTbl[] 有什么用途？

• 用途：该数组是一个以任务优先级为下标、保存指向该任务控制块（OS_TCB）指针的数组。
• 意义：有了它，系统在进行任务管理、状态更改或查找特定任务时，无须遍历 TCB 链表，仅需通过优先级作为数组下标就能在常数时间内（$O(1)$）直接获取对应任务的 TCB 指针，大幅提高了系统的运行效率。

变量OSRdyGrp有什么作用？

• 作用：OSRdyGrp 是一个 8 位的无符号整型变量，用于表示任务就绪表中哪些组（Row）有任务处于就绪状态。
• 原理解析：任务就绪表 OSRdyTbl[8] 是一个 8 字节的数组（共 64 位），被划分为 8 个任务组。OSRdyGrp 中的每一位对应就绪表数组 OSRdyTbl 的一个下标。如果 OSRdyGrp 的第 $i$ 位置为 1，则表示 OSRdyTbl[i] 所对应的组中至少有一个任务处于就绪状态。调度器通过它可快速定位就绪组，避免逐位扫描。

请给出辅助数组OSUnMapTbl[]的赋值过程

• 赋值原理：OSUnMapTbl[] 是一个大小为 256 的优先级判定只读查找表，其目的是为了快速找出某 8 位二进制数中“最低位的 1 在第几位”（因为优先级值越小，优先级越高）。其赋值过程逻辑如下：
  • 第 0 位为 1 的所有数（即所有奇数，如 1, 3, 5…），对应的查找表输出值均为 0。
  • 第 0 位为 0，第 1 位为 1 的所有数（如 2, 6, 10, 14…），其输出值均为 1。
  • 第 0、1 位均为 0，第 2 位为 1 的所有数（如 4, 12, 20…），其输出值均为 2。
  • 依此类推，直到所有高位。若 8 位全是 0（代表没有任务就绪），该索引对应的输出一般设为 0。
• 通过这样的数学规律对 256 个元素赋以 0~7 之间的值，保证了系统能通过查表在 $O(1)$ 时间内找出最高优先级的任务组号和组内偏移号。

第三章

简述uC/OS-II 的中断响应过程

• 接收到中断请求后，这时如果CPU处于中断允许状态（即中断是开放的），系统就会中止正在运行的当前任务，而按照中断向量的指向转而去运行中断服务子程序
• 当中断服务子程序的运行结束后，系统将会根据情况返回到被中止的任务继续运行或者转向运行另一个具有更高优先级别的就绪任务…
  • 注意：uC/OS-II是可剥夺型内核，因此中断服务子程序运行结束之后，系统将会根据情况进行一次调度去运行优先级别最高的就绪任务，而并不是一定要继续运行被中断的任务!

uC/OS-II 的系统时钟是如何实现的？在时钟节拍服务程序中做了什么工作？

• 系统时钟的实现： uC/OS-II 利用硬件定时器产生毫秒级的周期性硬件中断（即时钟节拍，Clock Tick），频率通常在 10Hz 至 100Hz 之间。该中断触发后会定时调用时钟节拍中断服务程序 OSTickISR()。
• 在时钟节拍服务程序（OSTickISR）中所做的工作：
  1. 保护现场：保存当前运行任务的 CPU 寄存器，调用 OSIntEnter()。
  2. 时钟节拍处理：调用系统的核心时钟节拍处理函数 OSTimeTick()。
  3. 退出中断并调度：调用 OSIntExit()，然后执行中断返回。
• OSTimeTick() 函数内部具体工作：
  1. 累加系统时间：将全局变量 OSTime（系统节拍计数器）加 1。
  2. 遍历 TCB 链表：遍历系统中所有任务的控制块。
  3. 延时递减：对每一个 OSTCBDly（任务等待时限）不为 0 的任务，将其减 1。
  4. 恢复就绪：若递减后 OSTCBDly 变为 0 且任务未被手工挂起，则清除其等待状态，将其状态修改为就绪，并在任务就绪表（OSRdyTbl）中进行登记，使该任务重新参与调度。

第四章

什么叫优先级反转？这种现象在什么情况下发生？如何防止这种现象的发生？

• 定义：
  • 在可剥夺型内核中，当某任务以独占方式共享资源时，会出现低优先级任务先于高优先级任务而被运行的现象，这叫做优先级反转
• 产生优先级反转的原因：
  • 一个低优先级的任务在获得了信号量使用共享资源时，被具有较高优先级的任务打断而不能释放信号量，从而使正在等待这个信号量的更高优先级的任务因得不到信号量而被迫处于等待状态。在这个等待期间，就让优先级别低于它而高于占据信号量的任务的任务先运行。
• 对系统的影响：
  • 优先级反转极大的恶化了高优先级任务的运行环境，是实时系统所无法容忍的
• 一种解决方法：
  • 使占有信号量的任务的优先级暂时提升到比现有最高优先级任务更高的一个级别上，在其释放信号量之后再恢复原来的优先级别

消息队列的结构包括哪些部分？各部分之间是如何关联的？

• 组成部分：
  1. 事件控制块（OS_EVENT）：其事件类型（OSEventType）设为 OS_EVENT_TYPE_Q。包含等待该队列的任务等待表 OSEventTbl[] 和组变量 OSEventGrp，其指针成员 OSEventPtr 指向队列控制块。
  2. 队列控制块（OS_Q）：用于管理消息指针数组的结构。包含 OSQStart（指向消息指针数组的首地址）、OSQEnd（指向数组结束的下一个单元）、OSQIn（指向下一个插入消息的位置）、OSQOut（指向下一个取出消息的位置）、OSQSize（数组容量）等。
  3. 消息队列（MsgTbl[]）：一个指针数组，数组内的每个元素存放的是具体消息（数据缓冲区）的内存指针。
  4. 消息：消息队列中存放的实际数据，通常是指向数据缓冲区的指针。**
• 关联方式：
  • 事件控制块通过其内部的 OSEventPtr 成员指向队列控制块（OS_Q）。
  • 队列控制块（OS_Q）通过其 OSQStart 成员指向消息指针数组（MsgTbl[]）的起点。
  • 任务需要请求或发送队列消息时，首先访问 OS_EVENT，通过其指针找到 OS_Q，再依据 OS_Q 的读写指针在消息指针数组中存取消息。

能否使用全局变量来实现任务间的通信？如果可以，有什么缺点？

• 是否可以：可以。任务之间确实可以通过读写共同的全局变量来传递数据。
• 缺点：
  1. 数据不一致与竞争风险（Race Conditions）：由于内核是可抢占的，一个任务在对全局变量进行多步骤写入时可能被高优先级任务抢占，导致读任务获取到“写了一半”的无意义或损坏的数据（即破坏了操作的原子性）。
  2. 无法实现真正的任务同步：读变量的任务由于无法得知写变量任务何时更新了数据，往往需要采用轮询（Busy-waiting）机制，这会白白浪费大量的 CPU 资源。
  3. 破坏可重入性（Non-reentrancy）：不加保护地使用全局变量会导致其相关函数变为不可重入函数，增加了程序的调试难度。
  4. 不支持任务阻塞挂起：使用全局变量时，当数据未就绪，任务无法像使用信号量或邮箱那样进入挂起等待状态让出 CPU，破坏了多任务的调度效率。