简介这份PPT课件围绕UCOS II实时操作系统的任务管理与调度机制展开面向嵌入式软件开发初学者、高校电子信息类专业学生及准备嵌入式岗位面试的工程师帮助其系统理解RTOS内核的任务组织方式与调度原理。压缩包内为1个pptx文件约9.8MB共170页按章节递进编排便于课堂讲授或个人逐页研读。内容覆盖任务控制块TCB结构与任务五种状态就绪、运行、等待、休眠、僵死的转换关系重点讲解基于RMS与时间片轮转的任务调度算法、TDMA与固定优先级两种调度策略并延伸至中断处理、信号量、互斥锁、条件变量等同步与通信机制配合示例代码说明共享资源保护与任务间协作的实现思路。课件兼顾概念梳理与代码分析可作为课程配套讲义也适合作为开发中查阅任务优先级配置与调度策略选型的参考。目前已有153人学习下载。1. 从一份 170 页课件说起任务管理为什么是 uC/OS-II 的门槛很多人第一次接触 uC/OS-II卡住的地方不是汇编启动代码也不是移植时那几个寄存器保存宏而是任务管理这一层。原因很实际裸机程序里你写的是一个超级循环代码顺序就是执行顺序换成 uC/OS-II 之后函数什么时候被切走、栈被谁覆盖、共享变量为什么偶尔读到脏值全都变得不可见。这份 170 页的 PPT 课件把任务管理、调度机制、同步与中断处理串在一起讲正好覆盖了从「会用」到「知道为什么」之间那段最容易断档的路。课件的价值在于它同时给了概念图和示例代码两条线TCB 里存什么、五种任务状态怎么迁移、优先级怎么决定下一次切换、信号量和互斥锁分别解决哪类问题。对嵌入式方向的学生它是课设和答辩的底稿对已经写过 STM32 裸机、准备上 RTOS 的工程师它是把经验对齐到体系结构的一次补课。下面按「先立概念、再写代码、最后排错」的顺序拆开讲凡是能落到寄存器、堆栈和 API 参数上的都不停在名词解释。2. uC/OS-II 任务控制块与任务状态迁移的代码落点课件前半段花了大量篇幅讲 TCB 和状态机这部分如果只看图会觉得很虚落到源码上其实非常具体。2.1 任务控制块 TCB 里到底存了什么uC/OS-II 每个任务对应一个OS_TCB结构体它不在堆上动态分配而是随任务一起静态定义或者从OSMem分区里取。核心成员可以对照下面这张表看理解每一项为什么必须存在成员作用关键说明OSTCBStkPtr指向任务私有栈顶切换时保存/恢复现场的关键永远指向栈中保存的 CPU 寄存器区OSTCBPrio任务优先级0 最高OS_LOWEST_PRIO最低同时决定就绪表和 TCB 链表位置OSTCBStat任务当前状态位就绪/等待/挂起等按位组合不是单一枚举OSTCBDly延时或超时计数调用OSTimeDly后由时钟节拍递减减到 0 唤醒任务OSTCBEventPtr事件控制块指针等待信号量/消息时指向对应 ECB用于唤醒时定位OSTCBNext/PrevTCB 双向链表系统按优先级维护 TCB 链表便于快速查找操作理解 TCB 的意义在于uC/OS-II 的调度并不是遍历所有任务函数而是操作这些结构体。优先级抢占时内核只动就绪表和 TCB 指针任务函数体一行都不用改。这也是为什么任务栈大小设错会以「另一个任务变量被莫名其妙改写」的形式暴露出来——两个任务栈挨着溢出的那个把邻居踩了。2.2 五种任务状态的迁移路径课件的状态迁移图对应的是下面这条实际调用链把 API 和状态对上就不容易混/* 创建后进入就绪态等待调度器选中 */ OSTaskCreateExt( TaskLED, /* 任务入口函数 */ NULL, /* 传给任务的参数 */ TaskLEDStk[STK_SIZE-1], /* 栈顶地址注意是最高地址 */ TASK_LED_PRIO, /* 优先级0 最高 */ TASK_LED_PRIO, /* 任务 ID通常与优先级相同 */ TaskLEDStk[0], /* 栈底Ext 版本才需要 */ STK_SIZE, /* 栈深度单位是 OS_STK 个数 */ NULL, /* 扩展数据指针 */ OS_TASK_OPT_STK_CHK | OS_TASK_OPT_STK_CLR); /* 允许栈检查 */ /* 运行中主动延时 - 等待态节拍减到 0 后回就绪态 */ OSTimeDly( 100 ); /* 100 个时钟节拍节拍率由 OS_TICKS_PER_SEC 决定 */ /* 等待信号量超时 - 从等待态转回就绪并返回超时错误 */ OSSemPend( Sem, 50, err ); /* 50 拍内没等到就返回 OS_TIMEOUT */逻辑说明OSTaskCreateExt里的栈顶参数必须传最高地址这是新手最常见的翻车点传成栈底会导致第一次切换就崩。OSTimeDly的等待态是「可唤醒」的节拍中断会递减OSTCBDly而OSSemPend的等待态除了节拍还可能被其他任务OSSemPost提前唤醒所以它的唤醒源有两个。参数上err要判OS_ERR_NONE、OS_TIMEOUT、OS_ERR_PEND_ISR三种忽略返回值是现场偶发死锁的高频原因。提示栈深度的单位不是字节。STM32 上OS_STK是 32 位STK_SIZE取 128 就是 512 字节。用OSTaskStkChk看实际余量再决定砍不砍。2.3 TCB 初始化与就绪表的关系任务创建的最后一步是把 TCB 挂进就绪表uC/OS-II 用的是OSRdyTbl[]位图加OSRdyGrp一个字节。优先级prio对应OSRdyGrp | OSMapTbl[prio3]、OSRdyTbl[prio3] | OSMapTbl[prio0x07]。调度时用OSUnMapTbl反查最高优先级整个查找是常数时间不随任务数增长。这就是课件强调「uC/OS-II 调度开销确定」的来源——它的最坏执行时间可以算出来对实时系统至关重要。理解了位图你就能解释为什么任务数上限是 64、为什么优先级不能重复未开启OS_TASK_OPT优先级复用的情况下。3. 调度策略选型抢占式优先级、时间片与 RMS 的边界课件里出现了 RMS、RRS、TDMA、FPS 这些词容易让人以为它们是平级的可选菜单。实际在 uC/OS-II 里真正内建的是基于优先级的抢占调度时间片轮转是在同优先级任务之间叠加的其余属于理论背景。3.1 抢占式优先级调度的实现机制内核在每次节拍中断、每次OS_Sched()调用、每次事件唤醒后都会做一次判定找出就绪表里的最高优先级任务如果它不是当前任务就触发切换。切换动作是保存当前任务的 CPU 寄存器到它的栈、再从新任务栈恢复寄存器然后跳转。伪代码层面就是/* 简化的调度判定实际在 OS_Sched 中配合临界区完成 */ if ( highest_ready_prio ! OSTCBCur-OSTCBPrio ) { OSIntEnter(); /* 进入临界区关中断计数 */ OSTCBCur-OSTCBStkPtr SP; /* 保存当前栈指针到 TCB */ OSTCBCur OSTCBHighRdy; /* 切换当前 TCB 指针 */ SP OSTCBCur-OSTCBStkPtr; /* 取出新任务栈指针 */ OSIntExit(); /* 退出临界区可能触发切换 */ }逻辑说明OSIntEnter/OSIntExit成对出现是为了支持中断嵌套OSIntNesting计数不为 0 时不允许调度避免在中断里切任务导致现场混乱。参数层面真正需要你调的只有节拍率OS_TICKS_PER_SEC一般取 100 到 1000取太高 CPU 光跑节拍中断取太低则OSTimeDly精度不够电机控制这类场景通常 1000。3.2 时间片轮转的开启条件与参数同优先级轮转不是默认开的需要在OS_CFG.H里打开OS_SCHED_ROUND_ROBIN_EN再给任务设置时间片/* 只对同优先级任务有效值表示连续运行的节拍数 */ OSSchedRoundRobinCfg( OS_TRUE, 10, err ); /* 全局开启默认时间片 10 拍 */ OSTaskTimeQuantaSet( TASK_A_PRIO, 5, err ); /* 单独给任务 A 设 5 拍 */这里的关键约束是轮转只在同优先级任务之间发生跨优先级仍然是严格抢占。很多人以为开了轮转就变成公平调度这是误读。另外时间片是节拍整数倍设成 0 表示该任务不参与轮转。注意一旦用了同优先级轮转就得接受该优先级组的响应时间不再确定因为组内谁先跑取决于上次谁用完时间片。硬实时任务不要和别的任务共享优先级。3.3 RMS、FPS、TDMA 三种说法的实际归属课件的 PPT 把 RMS 和 FPS 并列从工程角度看需要澄清一下对应关系策略说法在 uC/OS-II 中的落地方式适用场景FPS固定优先级内建抢占调度优先级创建时固定绝大多数嵌入式任务事件驱动型RMS单调速率一种分配周期任务优先级的理论方法周期越短优先级越高周期性任务集需做可调度性分析TDMA时分多址靠时间片轮转近似或自己按节拍做时间窗调度通信类等长时段场景RMS 不是内核提供的 API而是一种离线定优先级的方法论。判断一组周期任务能否满足截止期常用判据是利用率求和Σ(Ci/Ti) ≤ n(2^(1/n) − 1)n 个任务时约等于 0.69。也就是说按 RMS 分配优先级后只要总 CPU 利用率不超过 69%理论上所有任务都能满足截止期。这个结论决定了你该不该把控制任务和数据采集任务排在同一个优先级区间里。3.4 调度相关配置的实操检查清单上手一个已有工程时我一般按这个顺序核对避免在调度层瞎猜确认OS_TASK_TMR_PRIO是否被事件超时功能占用避免和目标优先级冲突确认OS_LOWEST_PRIO与OS_MAX_TASKS是否留够空位系统会占用两个优先级统计任务和空闲任务检查是否所有任务的优先级都唯一轮转模式下同优先级数量也要和OS_MAX_TASKS容量匹配打开OS_TASK_STAT_EN用OSStatInit()看 CPU 利用率判断是不是该优化任务划分编译时把OS_DEBUG_EN打开让栈检查和参数检查在运行期生效。这些项都过一遍常见「任务偶尔不跑」「优先级反转后卡死」的问题基本能定位到是配置还是代码。4. 中断、信号量与互斥锁任务间协作的实测写法任务管理和调度解决的是「谁在跑」中断和同步解决的是「什么时候被打断」「共享数据怎么不出错」。课件把这三块并列实际写代码时它们是咬合的。4.1 中断服务程序里的正确调用姿势uC/OS-II 对 ISR 有明确约束不能调用会引起阻塞的 API退出时必须走OSIntExit()否则调度器不知道可以切任务。典型骨架如下void EXTI0_IRQHandler(void) { OSIntEnter(); /* 嵌套计数加一进入中断上下文 */ if ( EXTI_GetITStatus(EXTI_Line0) ! RESET ) { OSSemPost( SemKey ); /* 只做释放不做等待 */ EXTI_ClearITPendingBit(EXTI_Line0); } OSIntExit(); /* 计数减一为 0 时触发任务切换 */ }逻辑说明OSSemPost在 ISR 里调用是安全的因为它不阻塞而OSSemPend只能在线程里用在 ISR 里调用会返回OS_ERR_PEND_ISR。OSIntEnter/OSIntExit必须成对漏掉OSIntExit的后果是OSIntNesting永远不为 0调度器从此不再切任务表现为「中断正常、任务全停」。4.2 信号量、互斥锁、事件标志组的选择标准课件列出了信号量、互斥锁、条件变量但 uC/OS-II 实际提供的是信号量、互斥量、事件标志组、消息邮箱和消息队列。选型可以按这张表对照机制解决什么问题坑点二值信号量任务间事件通知、ISR 到任务的唤醒无优先级继承不能拿它当锁用计数信号量资源池计数、缓冲区槽位管理初始值和最大值要算准否则计数溢出互斥量保护共享资源支持优先级继承只能线程级使用ISR 里不能 Pend事件标志组多条件任一/全部满足才继续要选「与」「或」模式超时后标志被清消息队列任务间传数据避免全局变量队列深度不足会丢消息需配错误处理4.3 优先级反转与互斥量的优先级继承实测这是课件里「任务调度」部分最值得动手验证的一点。构造三个优先级高H、中M、低L。L 持有互斥量H 因等锁被挂起M 就绪后把 L 抢占结果是 H 被 M 间接拖住——这就是优先级反转。uC/OS-II 的OSMutexPend支持优先级继承会把 L 的优先级临时提到 H 的水平M 就抢不进去了。OS_EVENT *SharedMutex; INT8U err; /* 任务 L 中申请互斥量期间优先级被继承提升 */ OSMutexPend( SharedMutex, 0, err ); if ( err OS_ERR_NONE ) { /* 临界区操作共享外设或缓冲区 */ OSMutexPost( SharedMutex ); /* 释放优先级还原 */ }参数说明timeout传 0 表示无限等待硬实时任务里我一般传有限值防止死等把系统拖住。OSMutexPend与OSSemPend的差别就在优先级继承代价是多几个 TCB 字段的写入开销保护共享资源时值得。实测验证办法是让 M 任务里空转计数用示波器翻转 IO 看 H 的响应时间有没有被拉长换成二值信号量再看一次差异会很直观。5. 把课件落到工程栈深度测算、统计任务与调度异常定位课件最后一页通常停在概念层面但真正决定项目稳不稳的是几个可以量化验证的细节。5.1 用 OSTaskStkChk 反推栈深度栈给多大不该靠猜。先给一个偏大的值跑上一段时间再把余量打出来OS_STK_DATA stk; OSTaskStkChk( TASK_LED_PRIO, stk, err ); /* stk.OSFree 为剩余空闲 OS_STK 个数stk.OSUsed 为已用个数 */拿到OSFree后按最坏路径再留 30% 余量定最终值。注意这个 API 只对OSTaskCreateExt创建且带OS_TASK_OPT_STK_CHK选项的任务有效用OSTaskCreate创建的任务查不出来。余量长期低于 10% 基本等于埋雷中断嵌套深一点就溢出。5.2 统计任务给出的 CPU 利用率怎么读打开统计任务后OSCPUUsage是全局变量直接读即可它表示这段时间内 CPU 花在非空闲任务上的比例。判断标准我一般这样定低于 70% 比较安全70% 到 85% 要开始关注峰值持续超过 85% 说明任务划分或优先级分配有问题该把大任务拆成事件驱动或者降低轮询频率。它的更新依赖于统计任务的执行所以统计任务自身优先级要设得较低但不被饿死。5.3 调度异常的定位路径出现「任务不切」「偶发卡死」时按这条链排查效率最高先看OSIntNesting是否归零排除 ISR 漏调用再查是否有任务在临界区内长时间停留OS_ENTER_CRITICAL包住的代码不能调用任何可能引起调度的函数然后用调试器看就绪表OSRdyTbl[]是否符合预期判断是任务没就绪还是优先级算错最后确认节拍中断是否还活着OSTimeTick没被调用会让所有延时任务永久休眠。这套顺序覆盖了绝大多数现场问题比对着状态图空想快得多。本文还有配套的精品资源点击获取 uC/OS-II任务管理与调度实战：TCB、优先级反转与栈检查
简介这份PPT课件围绕UCOS II实时操作系统的任务管理与调度机制展开面向嵌入式软件开发初学者、高校电子信息类专业学生及准备嵌入式岗位面试的工程师帮助其系统理解RTOS内核的任务组织方式与调度原理。压缩包内为1个pptx文件约9.8MB共170页按章节递进编排便于课堂讲授或个人逐页研读。内容覆盖任务控制块TCB结构与任务五种状态就绪、运行、等待、休眠、僵死的转换关系重点讲解基于RMS与时间片轮转的任务调度算法、TDMA与固定优先级两种调度策略并延伸至中断处理、信号量、互斥锁、条件变量等同步与通信机制配合示例代码说明共享资源保护与任务间协作的实现思路。课件兼顾概念梳理与代码分析可作为课程配套讲义也适合作为开发中查阅任务优先级配置与调度策略选型的参考。目前已有153人学习下载。1. 从一份 170 页课件说起任务管理为什么是 uC/OS-II 的门槛很多人第一次接触 uC/OS-II卡住的地方不是汇编启动代码也不是移植时那几个寄存器保存宏而是任务管理这一层。原因很实际裸机程序里你写的是一个超级循环代码顺序就是执行顺序换成 uC/OS-II 之后函数什么时候被切走、栈被谁覆盖、共享变量为什么偶尔读到脏值全都变得不可见。这份 170 页的 PPT 课件把任务管理、调度机制、同步与中断处理串在一起讲正好覆盖了从「会用」到「知道为什么」之间那段最容易断档的路。课件的价值在于它同时给了概念图和示例代码两条线TCB 里存什么、五种任务状态怎么迁移、优先级怎么决定下一次切换、信号量和互斥锁分别解决哪类问题。对嵌入式方向的学生它是课设和答辩的底稿对已经写过 STM32 裸机、准备上 RTOS 的工程师它是把经验对齐到体系结构的一次补课。下面按「先立概念、再写代码、最后排错」的顺序拆开讲凡是能落到寄存器、堆栈和 API 参数上的都不停在名词解释。2. uC/OS-II 任务控制块与任务状态迁移的代码落点课件前半段花了大量篇幅讲 TCB 和状态机这部分如果只看图会觉得很虚落到源码上其实非常具体。2.1 任务控制块 TCB 里到底存了什么uC/OS-II 每个任务对应一个OS_TCB结构体它不在堆上动态分配而是随任务一起静态定义或者从OSMem分区里取。核心成员可以对照下面这张表看理解每一项为什么必须存在成员作用关键说明OSTCBStkPtr指向任务私有栈顶切换时保存/恢复现场的关键永远指向栈中保存的 CPU 寄存器区OSTCBPrio任务优先级0 最高OS_LOWEST_PRIO最低同时决定就绪表和 TCB 链表位置OSTCBStat任务当前状态位就绪/等待/挂起等按位组合不是单一枚举OSTCBDly延时或超时计数调用OSTimeDly后由时钟节拍递减减到 0 唤醒任务OSTCBEventPtr事件控制块指针等待信号量/消息时指向对应 ECB用于唤醒时定位OSTCBNext/PrevTCB 双向链表系统按优先级维护 TCB 链表便于快速查找操作理解 TCB 的意义在于uC/OS-II 的调度并不是遍历所有任务函数而是操作这些结构体。优先级抢占时内核只动就绪表和 TCB 指针任务函数体一行都不用改。这也是为什么任务栈大小设错会以「另一个任务变量被莫名其妙改写」的形式暴露出来——两个任务栈挨着溢出的那个把邻居踩了。2.2 五种任务状态的迁移路径课件的状态迁移图对应的是下面这条实际调用链把 API 和状态对上就不容易混/* 创建后进入就绪态等待调度器选中 */ OSTaskCreateExt( TaskLED, /* 任务入口函数 */ NULL, /* 传给任务的参数 */ TaskLEDStk[STK_SIZE-1], /* 栈顶地址注意是最高地址 */ TASK_LED_PRIO, /* 优先级0 最高 */ TASK_LED_PRIO, /* 任务 ID通常与优先级相同 */ TaskLEDStk[0], /* 栈底Ext 版本才需要 */ STK_SIZE, /* 栈深度单位是 OS_STK 个数 */ NULL, /* 扩展数据指针 */ OS_TASK_OPT_STK_CHK | OS_TASK_OPT_STK_CLR); /* 允许栈检查 */ /* 运行中主动延时 - 等待态节拍减到 0 后回就绪态 */ OSTimeDly( 100 ); /* 100 个时钟节拍节拍率由 OS_TICKS_PER_SEC 决定 */ /* 等待信号量超时 - 从等待态转回就绪并返回超时错误 */ OSSemPend( Sem, 50, err ); /* 50 拍内没等到就返回 OS_TIMEOUT */逻辑说明OSTaskCreateExt里的栈顶参数必须传最高地址这是新手最常见的翻车点传成栈底会导致第一次切换就崩。OSTimeDly的等待态是「可唤醒」的节拍中断会递减OSTCBDly而OSSemPend的等待态除了节拍还可能被其他任务OSSemPost提前唤醒所以它的唤醒源有两个。参数上err要判OS_ERR_NONE、OS_TIMEOUT、OS_ERR_PEND_ISR三种忽略返回值是现场偶发死锁的高频原因。提示栈深度的单位不是字节。STM32 上OS_STK是 32 位STK_SIZE取 128 就是 512 字节。用OSTaskStkChk看实际余量再决定砍不砍。2.3 TCB 初始化与就绪表的关系任务创建的最后一步是把 TCB 挂进就绪表uC/OS-II 用的是OSRdyTbl[]位图加OSRdyGrp一个字节。优先级prio对应OSRdyGrp | OSMapTbl[prio3]、OSRdyTbl[prio3] | OSMapTbl[prio0x07]。调度时用OSUnMapTbl反查最高优先级整个查找是常数时间不随任务数增长。这就是课件强调「uC/OS-II 调度开销确定」的来源——它的最坏执行时间可以算出来对实时系统至关重要。理解了位图你就能解释为什么任务数上限是 64、为什么优先级不能重复未开启OS_TASK_OPT优先级复用的情况下。3. 调度策略选型抢占式优先级、时间片与 RMS 的边界课件里出现了 RMS、RRS、TDMA、FPS 这些词容易让人以为它们是平级的可选菜单。实际在 uC/OS-II 里真正内建的是基于优先级的抢占调度时间片轮转是在同优先级任务之间叠加的其余属于理论背景。3.1 抢占式优先级调度的实现机制内核在每次节拍中断、每次OS_Sched()调用、每次事件唤醒后都会做一次判定找出就绪表里的最高优先级任务如果它不是当前任务就触发切换。切换动作是保存当前任务的 CPU 寄存器到它的栈、再从新任务栈恢复寄存器然后跳转。伪代码层面就是/* 简化的调度判定实际在 OS_Sched 中配合临界区完成 */ if ( highest_ready_prio ! OSTCBCur-OSTCBPrio ) { OSIntEnter(); /* 进入临界区关中断计数 */ OSTCBCur-OSTCBStkPtr SP; /* 保存当前栈指针到 TCB */ OSTCBCur OSTCBHighRdy; /* 切换当前 TCB 指针 */ SP OSTCBCur-OSTCBStkPtr; /* 取出新任务栈指针 */ OSIntExit(); /* 退出临界区可能触发切换 */ }逻辑说明OSIntEnter/OSIntExit成对出现是为了支持中断嵌套OSIntNesting计数不为 0 时不允许调度避免在中断里切任务导致现场混乱。参数层面真正需要你调的只有节拍率OS_TICKS_PER_SEC一般取 100 到 1000取太高 CPU 光跑节拍中断取太低则OSTimeDly精度不够电机控制这类场景通常 1000。3.2 时间片轮转的开启条件与参数同优先级轮转不是默认开的需要在OS_CFG.H里打开OS_SCHED_ROUND_ROBIN_EN再给任务设置时间片/* 只对同优先级任务有效值表示连续运行的节拍数 */ OSSchedRoundRobinCfg( OS_TRUE, 10, err ); /* 全局开启默认时间片 10 拍 */ OSTaskTimeQuantaSet( TASK_A_PRIO, 5, err ); /* 单独给任务 A 设 5 拍 */这里的关键约束是轮转只在同优先级任务之间发生跨优先级仍然是严格抢占。很多人以为开了轮转就变成公平调度这是误读。另外时间片是节拍整数倍设成 0 表示该任务不参与轮转。注意一旦用了同优先级轮转就得接受该优先级组的响应时间不再确定因为组内谁先跑取决于上次谁用完时间片。硬实时任务不要和别的任务共享优先级。3.3 RMS、FPS、TDMA 三种说法的实际归属课件的 PPT 把 RMS 和 FPS 并列从工程角度看需要澄清一下对应关系策略说法在 uC/OS-II 中的落地方式适用场景FPS固定优先级内建抢占调度优先级创建时固定绝大多数嵌入式任务事件驱动型RMS单调速率一种分配周期任务优先级的理论方法周期越短优先级越高周期性任务集需做可调度性分析TDMA时分多址靠时间片轮转近似或自己按节拍做时间窗调度通信类等长时段场景RMS 不是内核提供的 API而是一种离线定优先级的方法论。判断一组周期任务能否满足截止期常用判据是利用率求和Σ(Ci/Ti) ≤ n(2^(1/n) − 1)n 个任务时约等于 0.69。也就是说按 RMS 分配优先级后只要总 CPU 利用率不超过 69%理论上所有任务都能满足截止期。这个结论决定了你该不该把控制任务和数据采集任务排在同一个优先级区间里。3.4 调度相关配置的实操检查清单上手一个已有工程时我一般按这个顺序核对避免在调度层瞎猜确认OS_TASK_TMR_PRIO是否被事件超时功能占用避免和目标优先级冲突确认OS_LOWEST_PRIO与OS_MAX_TASKS是否留够空位系统会占用两个优先级统计任务和空闲任务检查是否所有任务的优先级都唯一轮转模式下同优先级数量也要和OS_MAX_TASKS容量匹配打开OS_TASK_STAT_EN用OSStatInit()看 CPU 利用率判断是不是该优化任务划分编译时把OS_DEBUG_EN打开让栈检查和参数检查在运行期生效。这些项都过一遍常见「任务偶尔不跑」「优先级反转后卡死」的问题基本能定位到是配置还是代码。4. 中断、信号量与互斥锁任务间协作的实测写法任务管理和调度解决的是「谁在跑」中断和同步解决的是「什么时候被打断」「共享数据怎么不出错」。课件把这三块并列实际写代码时它们是咬合的。4.1 中断服务程序里的正确调用姿势uC/OS-II 对 ISR 有明确约束不能调用会引起阻塞的 API退出时必须走OSIntExit()否则调度器不知道可以切任务。典型骨架如下void EXTI0_IRQHandler(void) { OSIntEnter(); /* 嵌套计数加一进入中断上下文 */ if ( EXTI_GetITStatus(EXTI_Line0) ! RESET ) { OSSemPost( SemKey ); /* 只做释放不做等待 */ EXTI_ClearITPendingBit(EXTI_Line0); } OSIntExit(); /* 计数减一为 0 时触发任务切换 */ }逻辑说明OSSemPost在 ISR 里调用是安全的因为它不阻塞而OSSemPend只能在线程里用在 ISR 里调用会返回OS_ERR_PEND_ISR。OSIntEnter/OSIntExit必须成对漏掉OSIntExit的后果是OSIntNesting永远不为 0调度器从此不再切任务表现为「中断正常、任务全停」。4.2 信号量、互斥锁、事件标志组的选择标准课件列出了信号量、互斥锁、条件变量但 uC/OS-II 实际提供的是信号量、互斥量、事件标志组、消息邮箱和消息队列。选型可以按这张表对照机制解决什么问题坑点二值信号量任务间事件通知、ISR 到任务的唤醒无优先级继承不能拿它当锁用计数信号量资源池计数、缓冲区槽位管理初始值和最大值要算准否则计数溢出互斥量保护共享资源支持优先级继承只能线程级使用ISR 里不能 Pend事件标志组多条件任一/全部满足才继续要选「与」「或」模式超时后标志被清消息队列任务间传数据避免全局变量队列深度不足会丢消息需配错误处理4.3 优先级反转与互斥量的优先级继承实测这是课件里「任务调度」部分最值得动手验证的一点。构造三个优先级高H、中M、低L。L 持有互斥量H 因等锁被挂起M 就绪后把 L 抢占结果是 H 被 M 间接拖住——这就是优先级反转。uC/OS-II 的OSMutexPend支持优先级继承会把 L 的优先级临时提到 H 的水平M 就抢不进去了。OS_EVENT *SharedMutex; INT8U err; /* 任务 L 中申请互斥量期间优先级被继承提升 */ OSMutexPend( SharedMutex, 0, err ); if ( err OS_ERR_NONE ) { /* 临界区操作共享外设或缓冲区 */ OSMutexPost( SharedMutex ); /* 释放优先级还原 */ }参数说明timeout传 0 表示无限等待硬实时任务里我一般传有限值防止死等把系统拖住。OSMutexPend与OSSemPend的差别就在优先级继承代价是多几个 TCB 字段的写入开销保护共享资源时值得。实测验证办法是让 M 任务里空转计数用示波器翻转 IO 看 H 的响应时间有没有被拉长换成二值信号量再看一次差异会很直观。5. 把课件落到工程栈深度测算、统计任务与调度异常定位课件最后一页通常停在概念层面但真正决定项目稳不稳的是几个可以量化验证的细节。5.1 用 OSTaskStkChk 反推栈深度栈给多大不该靠猜。先给一个偏大的值跑上一段时间再把余量打出来OS_STK_DATA stk; OSTaskStkChk( TASK_LED_PRIO, stk, err ); /* stk.OSFree 为剩余空闲 OS_STK 个数stk.OSUsed 为已用个数 */拿到OSFree后按最坏路径再留 30% 余量定最终值。注意这个 API 只对OSTaskCreateExt创建且带OS_TASK_OPT_STK_CHK选项的任务有效用OSTaskCreate创建的任务查不出来。余量长期低于 10% 基本等于埋雷中断嵌套深一点就溢出。5.2 统计任务给出的 CPU 利用率怎么读打开统计任务后OSCPUUsage是全局变量直接读即可它表示这段时间内 CPU 花在非空闲任务上的比例。判断标准我一般这样定低于 70% 比较安全70% 到 85% 要开始关注峰值持续超过 85% 说明任务划分或优先级分配有问题该把大任务拆成事件驱动或者降低轮询频率。它的更新依赖于统计任务的执行所以统计任务自身优先级要设得较低但不被饿死。5.3 调度异常的定位路径出现「任务不切」「偶发卡死」时按这条链排查效率最高先看OSIntNesting是否归零排除 ISR 漏调用再查是否有任务在临界区内长时间停留OS_ENTER_CRITICAL包住的代码不能调用任何可能引起调度的函数然后用调试器看就绪表OSRdyTbl[]是否符合预期判断是任务没就绪还是优先级算错最后确认节拍中断是否还活着OSTimeTick没被调用会让所有延时任务永久休眠。这套顺序覆盖了绝大多数现场问题比对着状态图空想快得多。本文还有配套的精品资源点击获取