简介：这份资源是面向嵌入式专业学生与初学者的UCOS-II课程设计完整工程，围绕多任务调度与系统时钟展开，可用于课程实验、自学练手或作为RTOS入门的参考项目。压缩包共63个文件、约283KB，以35个h头文件、3个c源文件为核心代码，配合9个o目标文件、6个s汇编启动文件及工程配置与烧录相关文件，构成可直接在目标平台上编译调试的完整工程结构。目前已有455人学习下载，具备一定的参考基础。资源内容覆盖UCOS-II的移植与配置、任务创建与优先级管理、基于时钟滴答的延时与周期性任务、信号量与消息队列等同步通信机制，并涉及调试与资源优化思路，读者可据此理解抢占式调度与实时性设计的实现细节，为后续嵌入式开发积累可复用的工程经验。

1. 从一块跑不起来的开发板说起：这个课程设计到底在做什么

去年帮一个学弟看他的嵌入式课程设计，板子上电后串口只吐了一行乱码就没了下文，他跟我说“UCOS-II 移植好了，就是多任务跑不起来”。我拿过来一看，两个任务里各塞了一个delay_ms(500)死等，系统时钟节拍压根没配，任务调度器等于在空转。这个场景几乎每年毕业季都会重演一遍——嵌入式课程设计里选UCOS-II 多任务加系统时钟这个题，看着简单，真正把时钟节拍、任务切换、优先级调度串起来跑通的人并不多。

这份资源就是围绕这个题目做的一套完整工程：在 Cortex-M 内核的开发板上移植 UCOS-II，建立系统时钟节拍，跑起至少三个不同优先级的任务，用串口或 LED 把任务切换和时钟计数可视化出来。它适合两类人：一类是正在做嵌入式课程设计、需要一个能跑通的参考工程的学生；另一类是刚接触 RTOS、想把“多任务”和“系统时钟”这两个概念从纸面落到代码上的开发者。下面我按“这项目长什么样 → 怎么跑起来 → 核心代码怎么写的 → 怎么改”的顺序拆一遍。

2. 工程结构与移植层：UCOS-II 在一个 Cortex-M 板子上是怎么落地的

2.1 目录分层：哪些是内核，哪些是自己写的

UCOS-II 的源码包本身结构很固定，课程设计工程一般会在它外面再包一层板级支持。我见过的合格工程目录大致是这样分的：

project/ ├── ucosii/ # 内核源码，基本不动 │ ├── ucos_ii.c/h # 内核主体 │ ├── os_core.c # 任务调度、就绪表 │ ├── os_task.c # 任务创建/删除/挂起 │ ├── os_time.c # 延时与时钟节拍相关 │ ├── os_tmr.c # 软件定时器 │ └── os_cfg.h # 内核裁剪配置 ├── port/ # 移植层，和 CPU 架构绑定 │ ├── os_cpu.h # 数据类型、临界区宏 │ ├── os_cpu_a.asm/s # PendSV、SysTick 汇编入口 │ └── os_cpu_c.c # 任务栈初始化、钩子函数 ├── bsp/ # 板级驱动 │ ├── bsp_clock.c # 系统时钟与 SysTick 配置 │ ├── bsp_uart.c # 串口，用于打印任务状态 │ └── bsp_led.c ├── app/ # 应用任务 │ ├── app_task.c # 各任务函数体 │ └── app_main.c # main 与启动流程 └── config/ └── os_cfg.h # 任务数、节拍频率等宏

这个分层的关键在于：ucosii/是原封不动的内核，port/是唯一和芯片架构相关的地方，bsp/和app/才是这个课程设计真正“自己写”的部分。很多同学移植失败，就是把port/里的东西改乱了，或者把板级时钟配置塞进了内核文件里，后面想换板子就得推倒重来。

2.2 移植层三件套：os_cpu.h、os_cpu_a、os_cpu_c

UCOS-II 移植到任何一款 Cortex-M 芯片上，核心就三件事：定义数据类型和临界区、提供任务上下文切换的汇编入口、提供任务栈初始化函数。先看os_cpu.h里最关键的几个宏：

/* os_cpu.h —— 临界区与数据类型定义 */ typedef unsigned char BOOLEAN; typedef unsigned short INT16U; typedef unsigned int INT32U; typedef unsigned int OS_STK; /* 栈元素宽度，Cortex-M 是 32 位 */ /* 进入/退出临界区：关中断、开中断 */ #define OS_CRITICAL_METHOD 3 #if OS_CRITICAL_METHOD == 3 #define OS_ENTER_CRITICAL() { cpu_sr = OS_CPU_SR_Save(); } #define OS_EXIT_CRITICAL() { OS_CPU_SR_Restore(cpu_sr); } #endif /* 任务切换：触发 PendSV 异常 */ #define OS_TASK_SW() OSCtxSw()

OS_CPU_SR_Save()和OS_CPU_SR_Restore()一般用内联汇编读写 PRIMASK 寄存器实现，保存的是“进临界区之前的中断状态”，而不是无脑开中断——这一点是血泪经验，早期我直接写__enable_irq()，结果在嵌套临界区里把中断提前打开了，任务就绪表被改到一半被打断，跑着跑着就死机。

os_cpu_a.s里最关键的是PendSV_Handler，它负责保存当前任务上下文、切换栈指针、恢复下一个任务上下文。Cortex-M 有硬件自动压栈，所以汇编里只需要处理 R4-R11 和 PSP 的交换：

; os_cpu_a.s —— PendSV 上下文切换（节选） PendSV_Handler: MRS R0, PSP ; 取当前任务栈指针 CBZ R0, PendSV_NoSave ; 首次切换，无需保存 STMFD R0!, {R4-R11} ; 手动保存 R4-R11 LDR R1, =OSTCBCurPtr LDR R1, [R1] STR R0, [R1] ; 更新当前任务栈顶 PendSV_NoSave: BL OSSched ; 调用调度器选下一个任务 LDR R0, =OSTCBHighRdyPtr LDR R0, [R0] LDR R1, [R0] LDMFD R1!, {R4-R11} ; 恢复新任务 R4-R11 MSR PSP, R1 ; 更新 PSP ORR LR, LR, #0x04 ; 返回 Thread 模式并使用 PSP BX LR

这段汇编的逻辑是：先判断是不是第一次切换（PSP 为 0 说明还没跑过任务），不是的话把 R4-R11 压到当前任务栈；然后调OSSched()选出最高优先级就绪任务，从它的 TCB 里取出栈指针，恢复 R4-R11，最后把 PSP 指向新任务栈并返回。参数上要注意OSTCBCurPtr和OSTCBHighRdyPtr这两个全局指针必须和os_core.c里的定义完全一致，名字对不上链接能过但运行必崩。

os_cpu_c.c里则是OSTaskStkInit()，它负责伪造一个“刚被中断过”的栈帧，让第一次任务切换时能正常返回：

/* os_cpu_c.c —— 任务栈初始化 */ OS_STK *OSTaskStkInit(void (*task)(void *pd), void *p_arg, OS_STK *ptos, INT16U opt) { OS_STK *stk = ptos; *(--stk) = (OS_STK)0x01000000; /* xPSR，Thumb 位必须置 1 */ *(--stk) = (OS_STK)task; /* PC，任务入口 */ *(--stk) = (OS_STK)0xFFFFFFFD; /* LR，异常返回用 PSP */ *(--stk) = (OS_STK)0x12121212; /* R12，占位 */ *(--stk) = (OS_STK)0x03030303; /* R3 */ *(--stk) = (OS_STK)0x02020202; /* R2 */ *(--stk) = (OS_STK)0x01010101; /* R1 */ *(--stk) = (OS_STK)p_arg; /* R0，任务参数 */ /* 再压 R4-R11 占位，共 8 个 */ for (int i = 0; i < 8; i++) *(--stk) = 0; return stk; }

这里最容易翻车的是 xPSR 的 Thumb 位：Cortex-M 只支持 Thumb 指令集，PC 最低位必须是 1，否则第一次任务切换直接进 HardFault。我见过有人把0x01000000写成0x00000000，现象就是调度器一启动就卡死，串口一个字都不出。

2.3 系统时钟节拍：SysTick 是整个多任务的心跳

UCOS-II 的延时、超时、时间片轮转全靠一个周期性中断——系统时钟节拍。在 Cortex-M 上通常用 SysTick 产生，配置代码在bsp_clock.c：

/* bsp_clock.c —— SysTick 配置为 UCOS-II 节拍源 */ #define OS_TICKS_PER_SEC 1000u /* 每秒 1000 个节拍，即 1ms 一次 */ void BSP_ClockInit(void) { /* 假设系统主频 72MHz，重装载值 = 72M / 1000 - 1 */ SysTick->LOAD = (SystemCoreClock / OS_TICKS_PER_SEC) - 1; SysTick->VAL = 0; SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk /* 用内核时钟 */ | SysTick_CTRL_TICKINT_Msk /* 开中断 */ | SysTick_CTRL_ENABLE_Msk; /* 启动 */ } /* SysTick 中断服务：每 1ms 调一次内核节拍函数 */ void SysTick_Handler(void) { OSIntEnter(); OSTimeTick(); /* 内核节拍处理：任务延时递减、超时判断 */ OSIntExit(); /* 退出中断，必要时触发任务切换 */ }

OS_TICKS_PER_SEC这个宏要和os_cfg.h里的OS_TICKS_PER_SEC保持一致，两处不一致的后果很隐蔽：延时函数算出来的时间会整体偏移，比如你写OSTimeDly(100)以为是 100ms，实际跑了 200ms，调试时怎么都对不上。OSIntEnter()和OSIntExit()必须成对出现，前者给中断嵌套计数加一，后者减一并判断是否需要切换任务，漏掉任何一个都会让调度器在中断里做出错误决策。

3. 多任务跑起来：从 main 到三个任务并发的完整链路

3.1 启动流程：硬件初始化、内核初始化、创建任务、启动调度

一个能跑的多任务工程，main里的顺序是有讲究的，不能随便调换：

/* app_main.c —— 启动流程 */ int main(void) { BSP_Init(); /* 时钟、串口、LED 等板级初始化 */ BSP_ClockInit(); /* SysTick 节拍源，必须在 OSInit 前或后都行，但要在 OSStart 前 */ OSInit(); /* 内核初始化：就绪表、TCB 链表、空闲任务 */ /* 创建三个任务，优先级数值越小优先级越高 */ OSTaskCreate(TaskLed, (void *)0, &TaskLedStk[STK_SIZE-1], 5); OSTaskCreate(TaskClock, (void *)0, &TaskClockStk[STK_SIZE-1], 6); OSTaskCreate(TaskUart, (void *)0, &TaskUartStk[STK_SIZE-1], 7); OSStart(); /* 启动调度器，永不返回 */ return 0; }

OSInit()会创建空闲任务（优先级最低）和统计任务（如果开了OS_TASK_STAT_EN），所以用户任务的优先级不能占用最低那几档。OSTaskCreate的第四个参数是优先级，数值越小越高，这里 LED 任务给 5、时钟任务给 6、串口任务给 7，形成明确的优先级梯度，方便观察抢占行为。栈顶参数传的是&TaskLedStk[STK_SIZE-1]，因为 Cortex-M 栈是满递减，栈顶在高地址。

3.2 三个任务的分工：LED、时钟计数、串口上报

任务函数体本身不复杂，但每个都对应一个可观察的现象，这是课程设计能“演示”的关键：

/* app_task.c —— 三个任务 */ OS_STK TaskLedStk[STK_SIZE]; OS_STK TaskClockStk[STK_SIZE]; OS_STK TaskUartStk[STK_SIZE]; volatile INT32U g_tick_count = 0; /* 全局节拍计数，供串口任务读取 */ void TaskLed(void *p_arg) { (void)p_arg; while (1) { BSP_LedToggle(); OSTimeDly(500); /* 500 个节拍 = 500ms */ } } void TaskClock(void *p_arg) { (void)p_arg; while (1) { g_tick_count++; OSTimeDly(10); /* 每 10ms 累加一次 */ } } void TaskUart(void *p_arg) { (void)p_arg; while (1) { printf("tick=%lu, led period=500ms\r\n", g_tick_count); OSTimeDly(1000); /* 每秒上报一次 */ } }

TaskLed用OSTimeDly(500)而不是死循环延时，这样在它“睡”着的 500ms 里 CPU 会让给其他任务，这正是多任务相对裸机最大的区别。TaskClock每 10ms 累加一次全局计数，TaskUart每秒打印一次，如果打印出来的计数每秒增长约 100，说明节拍和任务调度都正常；如果增长明显偏离，就要回头查OS_TICKS_PER_SEC和 SysTick 重装载值。g_tick_count加了volatile，防止编译器把它优化进寄存器导致串口任务读到旧值。

3.3 优先级抢占与时间片：怎么验证调度真的在工作

光看 LED 闪和串口打印还不够，要证明“抢占式调度”确实生效，可以临时加一个高优先级任务做实验：

/* 验证抢占：优先级 4 高于 LED 任务的 5 */ void TaskHighPrio(void *p_arg) { (void)p_arg; while (1) { BSP_LedOn(); /* 高优先级任务点亮 LED */ OSTimeDly(100); BSP_LedOff(); OSTimeDly(100); } }

把这个任务用优先级 4 创建进去，如果 LED 的闪烁节奏被它“抢”走一部分，说明抢占生效。UCOS-II 默认不支持同优先级时间片轮转，除非在os_cfg.h里把OS_LOWEST_PRIO和OS_TASK_TMR_PRIO之外再打开OS_TIME_SLICE_EN（不同版本宏名略有差异），并给同优先级任务配置时间片。课程设计里一般不需要开，保持“优先级唯一”反而更容易讲清楚调度逻辑。

4. 避坑与排查：移植和跑通过程中最容易翻车的五件事

4.1 上电就进 HardFault，串口无输出

现象是板子上电后 LED 不闪、串口一个字都没有，调试器停下去看 PC 停在HardFault_Handler。原因八成在OSTaskStkInit()里 xPSR 的 Thumb 位没置 1，或者任务栈大小给得太小（STK_SIZE只给了 64），第一次压栈就溢出踩到了别的内存。解决办法是把 xPSR 写成0x01000000，并把每个任务的栈开到 128 以上，调试时可以在HardFault_Handler里打印 LR 和 PSP 定位。

4.2 任务能跑但延时时间整体翻倍或减半

现象是OSTimeDly(500)实际跑了 1 秒。原因是OS_TICKS_PER_SEC在os_cfg.h和bsp_clock.c里定义成了两个不同的值，或者 SysTick 重装载值算错（忘了减 1，或者用了错误的SystemCoreClock）。解决方法是把节拍频率统一成一个宏，只在一处定义，另一处引用；再用示波器或逻辑分析仪量 LED 翻转周期反推实际节拍。

4.3 串口打印乱码或只出第一个字符

现象是串口助手收到一堆乱码。原因通常是串口波特率配置和实际系统时钟不匹配——BSP_ClockInit()改了主频但串口初始化还按旧频率算分频。解决办法是先初始化时钟再初始化串口，串口分频用SystemCoreClock实时计算，别写死。另外printf重定向到串口时要注意别在中断里调用，UCOS-II 下多任务同时printf还会互相打断，简单做法是给串口输出加一个互斥信号量。

4.4 加了新任务后系统卡死或某个任务再也不执行

现象是原来三个任务好好的，加第四个任务后某个任务饿死。原因是新任务优先级设得比空闲任务还低，或者和已有任务优先级重复但没开时间片。UCOS-II 要求每个任务优先级唯一（除非显式配置），重复优先级会导致就绪表位图错乱。解决办法是创建任务前先列一张优先级表，确保 5、6、7、8 依次递增，最低不低于OS_LOWEST_PRIO - 2。

4.5 调试器单步正常、全速跑就死

现象是单步调试时任务切换都正常，一按全速运行几秒就挂。原因是临界区宏写错，OS_EXIT_CRITICAL()无条件开中断，把本该在临界区里保护的就绪表操作暴露给了 SysTick 中断。解决办法是用OS_CRITICAL_METHOD == 3保存和恢复 PRIMASK，保证嵌套临界区的中断状态正确还原。这个坑我在两个项目里各踩过一次，后来养成习惯：凡是改os_cpu.h，先用一个最小双任务工程验证临界区。

5. 二次开发：把课程设计改成能讲出东西的毕设或作品

5.1 从“能跑”到“能演示”：加一个任务状态监控

课程设计答辩最怕老师问“你怎么证明调度在工作”。最省事的改造是在串口任务里把每个任务的剩余栈空间和当前状态打出来：

/* 任务状态监控：放在 TaskUart 里 */ void TaskUart(void *p_arg) { (void)p_arg; OS_TCB *tcb; while (1) { /* 遍历 TCB 链表，打印任务名、优先级、剩余栈 */ for (tcb = OSTCBList; tcb != (OS_TCB *)0; tcb = tcb->OSTCBNext) { INT32U free_stk = OSTaskStkChk(tcb->OSTCBPrio, &stk_data); printf("prio=%d free=%lu\r\n", tcb->OSTCBPrio, free_stk); } OSTimeDly(1000); } }

OSTaskStkChk()需要os_cfg.h里打开OS_TASK_STAT_STK_CHK_EN，它会扫描栈里的填充值算出剩余空间。这个功能一加，答辩时就能指着串口说“你看每个任务栈用了多少、还剩多少”，比空口讲调度有说服力得多。

5.2 改造方向与验证方法

表格里每一项都能单独写进报告的一节，而且都有可量化的验证手段，不用靠“感觉跑通了”。

5.3 一个具体技巧：用节拍计数做时间基准校准

最后说一个我每次做 RTOS 小项目都会用的习惯——在TaskClock里维护一个 32 位节拍计数，所有需要“绝对时间”的地方都基于它算差值，而不是依赖OSTimeDly的累加：

/* 基于节拍计数的时间差计算，避免多次延时累积误差 */ INT32U elapsed_ms(INT32U start) { return (g_tick_count - start); /* 无符号减法，溢出也正确 */ }

无符号减法的好处是即使g_tick_count溢出回绕，差值依然正确，这是嵌入式里处理时间戳的常规操作。从那以后我每次做带时钟节拍的工程，都强制先把这个计数和elapsed_ms写进去，再写业务任务，省得后面为了“时间怎么对不上”反复返工。希望这套拆解能帮你把自己的板子先跑起来，再往上加东西。

本文还有配套的精品资源，点击获取